Hi
I put a timing constraint in the UCF File where i asked for a minimum frequency of 35 MHz (29 ns) but unfortuatenly XST tells me that the ratio was not met and the actual ratio is 38 ns. I have already optimized for speed, it there any way to tell the tool it should sythesis it for more than 35 MHz forgetting about any area constraints?
Thanks!
It sounds like synthesis has done its best. I would find the slow nets and pipeline them.
-- Mike Treseler
There are other things that can be done.
One of the first ones is to use the Timing Analyzer from ISE. This tool will give you some good ideas to try and make your design work. It will also let you see exactly how you're failing the timing on that clock.
Another option is to try multi-pass map/place-and-route. I say both because as of the 9.1 version of the tools, you have to perform MAP and PAR at the same cost-table value for it to work as expected. If you're solely using ISE, this can be enabled from one of the menu's, somewhere. I do most of my work in EDK and I have a script that I use to perform multi-pass place and route. If you're interested, I could post it.
Another option that was introduced in the 9.1 version of the ISE tools is called the xplorer script. This is a more advanced version of multi- pass place and route (aka mppr). Previously, mppr just changed the cost table value and as such the placing of the design was affected. Now with the new xplorer script, it not only performs cost table changes, but trying advanced options for different types of algorithms for specific problems.
Odds are using timing analyzer is all you need to do, and hopefully won't need to start worrying about mppr or xplorer yet. Those are usually used when trying to achieve higher frequencies than the one you mentioned (>100MHz fabric speeds).
-- Mike
?
Hi Mike, Possible to post the mppr and xplorer script? thanks in advance!
Chris
Sometimes a long path is not really a long path. For example the output of the combinational logic (between two registered) is not really used on the next clock cycle but perhaps two or more cycles later. In such a case it doesn't really matter if the output didn't stabilize the next clock cycle because it takes one or more cycles before it's actually used. Adding a multi-cycle path constraint fixes this issue and informs the tool that it needn't constraint that path delay within one cycle time. False paths also are another similar issue though I personally did not run into them before.
I th> >
The mppr script that I wrote and have used under EDK 9.1 and 9.2 is available here:
To use the script, run it from the root of your EDK project by
run_mppr
Once a PAR finishes successfully, it will stop iterating and print out that it finished. It also saves all the previous attempts, in case you want review them to see what the output was at each iteration.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.