Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17253 Discussions

Question about warning: "Port type is incompatible with connection (port 'clock')"

Altera_Forum
Honored Contributor II
4,953 Views

The warning was issued after simulating a module written by Verilog.  

# Region: /.../.../.../u1/lpm_mult_component# ** Warning: (vsim-3016) C:/.../.../.../multiplier.v(62): Port type is incompatible with connection (port 'clock'). 

 

The module has a clock input "clk" which is assigned directly to a multipier generated by the megafunction. The warning refers to the "clock" signal within the multiplier.  

 

I don't understand why this warning was issued since the "clk" signal is defined as "input" and the "clock" signal within the multiplier is defined as "input" by the megafunction. Port type should be compatible. 

 

 

Any suggestion please?
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
3,716 Views

I have seen similar warnings when using altsyncram. I traced it to the tri0 and tri1 signal types of the signals in the altera module.  

 

I had a wr_clock_en and a wr_en in the port list of the altera ram module. If I used the same signal (a wire) to drive both ports then  

further down in the hierarchy of the altera module wr_clock_en was defined as tri0 and wr_en was defined as a tri1. This is presumably to set these  

ports to a set value if nothing is connected to them. Since the driving signal is essentially connecting these two signals together  

and is a 'wire', it could potentially have a Z value. If the driving signal was Z then tri0 and tri1 are trying to drive the same  

line and competing against each other causing the modelsim warning. This is a just a simulation problem 

 

To workaround it you can split the driving signal in to two wires by using assign sig2 = sig1; This appears to fix. 

Although I haven't tried it, I also suspect if you are using systemverilog and you used the 'bit' data type to drive both port signals  

instead of a 'wire' then this should fix it as well. 

 

C
0 Kudos
Reply