02-09-2010 02:55 AM
I come from an ASIC background and am fairly new to FPGAs. When doing timing analysis on ASICs we would generate at least Best Case (low temp, high voltage, fast process corner) and worst case (high temp, low voltage, slow process corner). For FPGAs the process corner isn't relevant, but I guess the temp and voltage are.
I'm using a Virtex-4 and the ISE 11.1 Web pack and as far as I can see, there's only one possibility to set the temp/voltage.
So my question is this: Is it necessary to run best case/worst case timing analysis for FPGAs, or is it somehow accounted for in the tool?
If it is necessary to run best case/worst case, then how is this set up?
02-09-2010 07:40 AM
Nope, all you have to do is meet the timing, with enough slack to take into account the worst peak jitter (1/2 peak to peak system jitter).
We did the hard work already, so you don't have to (when we designed the family, we already took into account the fastest process, voltage, temperature corners so any design will be "correct by construction").
02-09-2010 09:22 AM
Thanks. So in that case I should set my temp and voltage in ISE to worst case? - eg 85C, 1.14V?
When you say peak to peak system jitter, do you mean the jitter of the system clock? For example, in our system we have a VCXO providing the clock input to the FPGA, which then goes to a DCM. So we would take 1/2 of the VCXO's peak to peak jitter?
And finally, is there some way to set a value in ISE for "1/2 peak to peak system jitter", which is taken into account in the timing report? Then ISE can flag paths automatically and I don't have to go through the whole timing report looking for paths with slack < X?
02-09-2010 10:40 AM
The timing, place and route, is automatically done at the worst PVT. You do not need to do anything more (other than choose Commercial, Industrial, or Military grade components, so it knows which max Tj should be used, and which speedsfiles).
The worst case voltage is assumed from the specifications in the data sheet.
The system jitter includes the jitter from all the sources that the tools know and understand. It is up to you to add the peak system jitter.
Than can be done by editing the period constraint ion the .ucf file, or it can be added in our tools when you set up constraints that way.
I would add at least 300 ps to the overall 1/2 ssytem jitter number than the tools find they need (600 ps of total p-p system jitter additional).
This means that if a report omes back with 0 slack, you know it is still meeting timing (if only just barely),
09-19-2013 12:49 PM
09-19-2013 11:44 PM - edited 09-19-2013 11:55 PM
Actually best case analysis is needed and it is done. It is called fast path and only holds are analyzed. Just like ASIC, worst case corner is used for setup (or slow or late) and best case is used for hold (or fast or early) corners. If you guarantee that worst case setup passes, it is guaranteed that best case setup will also pass. The same goes for best case hold. If you can meet it, worst case hold will also pass.
Of course for really small process feature size and large die, on chip variation becomes an issue and one needs to do more interesting corners ala slow clock path and fast data path where different cells are characterized with different conditions and monte carlo simulations are run to simulate cell delays varying across the die. I think these are all taken care of by the extra margin Xilinx characterization adds to their timing analysis.
09-19-2013 11:49 PM - edited 09-19-2013 11:50 PM
I think there is a little confusion here. Worst case corner is enough for setup analysis but for hold analysis (or fast path) best case PVT corner is needed and Xilinx tools do a best case run for hold.
If one looks at a timing report from Vivado, the following cases can be found:
Max Delay Paths at Path Type: Setup (Max at Slow Process Corner)
Min Delay Paths Path Type: Hold (Min at Fast Process Corner)
So both slow process and fast process corners are used in timing analysis.
09-20-2013 09:26 AM
Thanks for chiming in. I'm not sure that the tool documentation supports your implication that fast path analysis is done at best case PVT. UG612 (v 13.2) July 6, 2011 makes the statement on page 50, "To report the hold paths for each constraint, use the -fastpaths switch in trce..." It seems that this tool switch only invokes hold path reporting, with no implication on the PVT corner this analysis is done. Certainly, nothing explicit is stated in the report concerning the PVT condition. So, confidence in knowing the condition is not very high.
Now, chapter 6 of the same document characterizes the STA as “Multi-Corner, Multi-Mode” and defines best and worst case PVT corners as one would expect. The trouble is that nothing is explicitely stated in the report when the mode changes from worst to best. For hi-reliability designs, this type of explicit documentation is necessary.
09-20-2013 09:39 AM
09-20-2013 09:46 AM
09-20-2013 06:20 PM
As people are figuring out, Vivado is different than ISE. The Vivado timing engine is a full multi-corner static timing analysis tool. By default (and it can be configured differently), it performs both setup and hold checks (which it calls max and min checks, respectively) at both the best PVT (fast process corner) and worst PVT (slow process corner). Furthermore, it even does "on chip variation" calculations; as an example the length of the destination clock path on a slow process corner setup check uses something a "little bit faster than slowest PVT".
This is one of the (many) advantages of Vivado - it has a sophisticated ASIC-class timing engine.
09-20-2013 09:34 PM - edited 09-20-2013 09:34 PM
the timing engine in TRCE and PAR might have its problems but nevertheless it is a true multi-corner STA tool. If you open up a twr file you can look at the delays in there for hold paths and setup paths and compare the values you get from speedprint., you will see that TRCE/PAR are doing analysis for best case corner and worst case corner for hold & setup respectively. Please don't fall into the trap of academics who don't know what they are talking about claiming that ISE family of tools don't do correct STA, they do. One just has to know where to look and do the correct analysis instead of blowing smoke.
02-04-2016 02:04 PM
I just tumbled into this post while my search for the method of doing fast corner and slow corner using ISE.
I am using ISE 14.7 and have a design fully place&routed with no error ar even warning. I used the Virtex-5 (XC5VLX50T) as my target device. I found in UG612 the following statement: !!
"This analysis is performed for Virtex®-6, Spartan®-6, and Xilinx 7 series device families only."
Does it mean it is impossible to do on Virtex-5??
Any help is cordially appreciated.