FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5988 Discussions

Problems with UniPHY IP not accepting commands on Cadence

Altera_Forum
Honored Contributor II
1,100 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
103 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 ---  

Reply