FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

Problems with UniPHY IP not accepting commands on Cadence

Altera_Forum
Honored Contributor II
1,253 Views

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?
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
256 Views

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

0 Kudos
Reply