Author Topic: Quartus Simulation Error: Formal port ".." has OPEN or no actual associated with  (Read 4960 times)

0 Members and 1 Guest are viewing this topic.

Offline RedLionTopic starter

  • Regular Contributor
  • *
  • Posts: 65
  • Country: lu
  • Professional power dissipator
Hello all,

I'm trying to simulate a piece of a project in Intel Quartus Lite 19.1 using the University Program .vwf.
It's somewhat of a large project, so I only wanted to simulate the block that's causing issues right now.
However I'm getting the following error messages that I'm not sure how to interprete. I have no nets or pins in my project by these names, but some of them sound vaguely JTAGesque? Google didn't spit out anything helpful so far.

# ** Error: Lauflicht.vho(7513): (vcom-1035) Formal port "tdoutap" has OPEN or no actual associated with it.
# ** Error: Lauflicht.vho(7513): (vcom-1035) Formal port "tmscore" has OPEN or no actual associated with it.
# ** Error: Lauflicht.vho(7513): (vcom-1035) Formal port "tckcore" has OPEN or no actual associated with it.
# ** Error: Lauflicht.vho(7513): (vcom-1035) Formal port "tdicore" has OPEN or no actual associated with it.
# ** Error: Lauflicht.vho(7513): (vcom-1035) Formal port "corectl" has OPEN or no actual associated with it.
# ** Error: Lauflicht.vho(7513): (vcom-1035) Formal port "ntdopinena" has OPEN or no actual associated with it.

# ** Error: Lauflicht.vho(24545): VHDL Compiler exiting
# End time: 13:56:50 on Aug 26,2020, Elapsed time: 0:00:00
# Errors: 7, Warnings: 0
# ** Error: c:/intelfpga_lite/19.1/modelsim_ase/win32aloem/vcom failed.
# Executing ONERROR command at macro ./Lauflicht.do line 3

Error.

Also, is there a clever way to put code in a post that I haven't seen? Seems strange to just paste it in the post like that

Thanks
We burn money we don't have
From shareholders we don't like
To develop products we can't sell
 

Offline mfro

  • Regular Contributor
  • *
  • Posts: 221
  • Country: de
are you on a MAX 10 by chance?
Beethoven wrote his first symphony in C.
 

Offline RedLionTopic starter

  • Regular Contributor
  • *
  • Posts: 65
  • Country: lu
  • Professional power dissipator
are you on a MAX 10 by chance?
Dammit, forgot to specify that. :palm:  Yup, I am. 10M50DAF484C7G to be exact.
Good guess or something I should have known but didn't?
We burn money we don't have
From shareholders we don't like
To develop products we can't sell
 

Offline mfro

  • Regular Contributor
  • *
  • Posts: 221
  • Country: de
are you on a MAX 10 by chance?
Dammit, forgot to specify that. :palm:  Yup, I am. 10M50DAF484C7G to be exact.
Good guess or something I should have known but didn't?

Not really. Just remember struggling with something similar on my MAX10 as well (although I can't remember what I did to remedy).

The ports you appear to have problems with are part of the MAX10 secure mode feature (see https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/max-10/ug_m10_config.pdf  and https://www.intel.com/content/dam/altera-www/global/en_US/uploads/5/5f/MAX10_JTAG_Secure_Unlock_UG.pdf )

Did you, by any chance, enable "Verify protect" in the MAX 10 device options?
Beethoven wrote his first symphony in C.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
In general this error means that you've instantiated an entity but did not include all of the ports on that entity in your instance. A port declared as an output should throw a warning if not connected in the instance (you should use OPEN to indicate that the port has no connection) but all input ports must have something driving them.

Now if this is something automatically instantiated by Intel's tools ... I got nothin', other than to say you should still look at the instance.
 

Offline RedLionTopic starter

  • Regular Contributor
  • *
  • Posts: 65
  • Country: lu
  • Professional power dissipator
Update: I am a massive idiot.

The entire problem was that I had pins for a 7-Seg-Display, named 7segA, 7segB etc...
When programming, that is not an issue. But when those are in a testbench, they end up as signals in an HDL file.
And, signal names starting with a number is, as we all know, a Big No No. One could have known that.
Hence, massive idiot.

It took me deleting the .vwf file and retrying, then I got a different error message, something with "no separator between string" something something, pointing to a .vwf.vht file. Once I opened that, sure enough, all my pins were reinterpreted as integers.
Now was that the original fault? I don't know. Possibly.
Was it a fault? Sure as hell was.

What did we learn? "Turning it off and on again", not just for confusers! Oh and stick to the bloody coding conventions.
We burn money we don't have
From shareholders we don't like
To develop products we can't sell
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf