01-15-2015 06:59 AM
I'm using Xilinx' fifo IP (in vivado 2014.1) and I'm unable to close the timing because of the fifo it self. I'm getting a warning for the following data path:
I'm not sure how I can solve timing issues within the fifo itself. The fifo is a dual clock fifo, both are 156.25Mhz clocks, just the phase is (could be) diffrent. I have 2 sync stages between clocks.
Any ideas what is going on and how I can fix it?
01-15-2015 07:16 PM
01-15-2015 07:48 PM
please make sure that you have not disabled any xdc file that is generated by tool when you synthesize the IP in OOC.
01-18-2015 12:12 AM
vijayak, What do you mean by a standalone IP?
I've created the fifo using Xilinx' IP wizard and just connected it to my system.
I've attached the timing report(I ran the "report_timing_summary" tcl command is that what you ment?)
aher, I'm not sure how I do that so I probably didn't do that. I have 2 xdc file I've created, one for timing and 1 for pinout. Those are the only 2 file that apear in the "constraints" folder in the "hierarvhy" in VIVADO.
01-22-2015 03:05 AM
01-22-2015 05:47 PM
The paths you are seeing are clearly the clock crossing paths within the FIFO (I recognize the names); to be sure you should give the detailed timing report of the top path, but I am pretty confident it will show that the path starts and ends on different clocks (one end on your read clock and one on the write clock).
These paths are proper clock crossing paths, and, as such, they need constraints to override the default timing analysis behavior of the tool.
One of the advantages to the IP mechanism in Vivado is that it doesn't only generate a netlist for you, it also generates all the constraints for the block. When the IP was generated, it also generated an .xdc file with the proper exceptions for these paths. You can see this by going into the IP pane in the sources window, and looking at all the files generated for the IP - there will be .xdc files there. These files become part of your project automatically when the IP block is created in your project or imported to your project.
Clearly, though, these files are not being used properly in your design. This means either
- you did something "odd" when you generated/imported the IP into your project or
- something went wrong when the IP constraints were applied to your design
Look through your messages to make sure that there weren't any warnings about a "set_max_delay" command - I think this might even show up as a critical warning. The constraint file for the core assumes your design is already constrained - specifically that both the read clock port and write clock port of the FIFO have a clock associated with them; that a create_clock or create_generated_clock, or an automatically generated clock is associated with the nets connected to the ports of the FIFO. If you don't have a clock defined for one of the ports, then the set_max_delay constraint in the FIFO's .xdc will fail (with a warning or critical warning). Even if you add the clock "later", the set_max_delay will still not be in place, which will cause these timing errors.
08-29-2016 09:01 AM
I have a similar issue with the FIFO IP. I am using the FIFO for interfacing two clock domains (write clock is at 560MHz and read clock is at 70MHz). But I get a lot of timing failing points inside the FIFO IP. The whole point of the project is to read a bunch of data from FMC connectors and connect them to an ila so that I can store the data. I have attached the timing report and would appreciate it if anyone could help with this.