Problems with UniPHY IP not accepting commands on Cadence

[Altera_Forum]

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?

[Altera_Forum]

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 ---