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.
5877 Discussions

Constraints for mem_reset_n in DDR3 IP

Altera_Forum
Honored Contributor I
745 Views

Anyone tried to constraint the mem_reset_n signal? 

 

We were having some odd issues with timing and so I was going through clearing up warnings. It sometimes fixes problems, and unfortunately the memory IP and the PCIE IP can produce quite a bit of them, and some look scary too. I guess they must be false as the IPs are in use in industry, but it could have been cleaner, so real warnings do not get overlooked. 

 

Anyways I came accross the unconstrained paths in Timequest. There were several in the code I am working on and I checked the example and saw the same thing. After specifying all reset synchronizers as false paths (there are several scattered around the IPs), and defining constraints given in the Altera documentation for the tck related signals I got the unconstrained paths down to just mem_reset_n. The tool still says it has no input/output max delays specified. Anyone got any ideas?
0 Kudos
1 Reply
Altera_Forum
Honored Contributor I
69 Views

 

--- Quote Start ---  

Anyone tried to constraint the mem_reset_n signal? 

 

We were having some odd issues with timing and so I was going through clearing up warnings. It sometimes fixes problems, and unfortunately the memory IP and the PCIE IP can produce quite a bit of them, and some look scary too. I guess they must be false as the IPs are in use in industry, but it could have been cleaner, so real warnings do not get overlooked. 

 

Anyways I came accross the unconstrained paths in Timequest. There were several in the code I am working on and I checked the example and saw the same thing. After specifying all reset synchronizers as false paths (there are several scattered around the IPs), and defining constraints given in the Altera documentation for the tck related signals I got the unconstrained paths down to just mem_reset_n. The tool still says it has no input/output max delays specified. Anyone got any ideas? 

--- Quote End ---  

 

 

You can constrain a reset just like any other input. 

If you decide to resynchronise it then you can set false path: 

set_false_path -from [get_ports {mem_reset_n}]
Reply