Problems with UniPHY IP not accepting commands on Cadence

Quartus 13.0.1 I still see the same problem. How were you able to pin point to which file?

--- Quote Start ---

Hi,

I have been working on a Cyclone V DDR3 UniPHY IP design using Quartus 11.1sp2 and simulating with Cadence Incisive. I generated the files ok and tried running the simulation. After clearing some issues I noticed that none of the read requests were getting taken by the IP.

I sorted through the log and wound up tracing through the verilog files generated and noticed a problem. Some of the select signals inside the controller are high-Z or X and some of them come from generated code like below:

always @(*)

something = SOMEPARAMETER

or perhaps

always @(*)

something = somewire; // that is set via a assign statement from a parameter.

These generate warnings on Cadence because the parameters do not trigger the always blocks (warning below). Not all cases generate warnings, but many do.

ncelab: *W,STARMT (.../altera_avalon_sc_fifo.v,639|17): This @* expands to empty list, will never wake up.

Has anyone else seen this? Perhaps it is just Cadence, but the LRM seems to state that always @(*) will always wait for an event, only always_comb (in SysV) will wake up for sure at time 0. Perhaps Mentor has a different interpretation of this rule. The solution seems to just replace the block types with initial or maybe always_comb. Perhaps it is a bug in Quartus 11.1sp2.

Has anyone else seen this?

--- Quote End ---