Fast Corner estimation for older devices

[Altera_Forum]

I am mantaining a couple of old designs with devices from the FLEX families. 

 Being familiar with newer families only, I wasn't expecting all the Quartus limitations when targetting these old devices. One of the limitations is that Fast Corner timing analysis is not implemented, and of course TimeQuest is not supported.  My specific problem is how to constrain a minimum tPD. I can specificy a minimum tPD, but without Fast Corner, the best and fastest case PVT is not considered.  The design I/O is rather simple and I probably can make the analysis manually, the question is what would be the rule of thumb to estimate the fastest PVT from the slowest tPD reported by the Timing Analyser.

[Altera_Forum]

Yep, Quartus and hardware has come a long way... 

The addage I remember from around that time was, "compile for the fastest speed grade, then divide that number by 4". That's probably really pessimistic, but should cover all conditions. (Be careful though. If you're doing Tpds and there's a lot of logic between pins, you might have multiple paths between those pins. This is an estimate on only one of those paths, most likely the longest, but if you have a shorter path, that's the one that should be used.)

[Altera_Forum]

Many thanks, Rysc. 

   --- Quote Start ---  The addage I remember from around that time was, "compile for the fastest speed grade, then divide that number by 4". That's probably really pessimistic, but should cover all conditions.  --- Quote End ---    Dividing by 4 from the fastest speed grade sounds indeed a lot. This would mean that if I'm using the slowest speed grade, I would need to consider the best case being something in the order of, possibly 10 times shorter than the worst case ???

[Altera_Forum]

I would be surprised if it's that much, but yes it's a lot. You might also try compiling a an APEX design(closer in process) and look at two paths for the min and max models, just to see what the spread is. Probably half is more realistic. But it's certainly possible that you can get shipped something faster than your slowest speed grade, so that's going to cut into your margins quite a bit right there.

[Altera_Forum]

--- Quote Start ---  You might also try compiling a an APEX design(closer in process) and look at two paths for the min and max models, just to see what the spread is.  --- Quote End ---    Yep. That's probably a very good idea.  Thanks a lot once again.

[Altera_Forum]

I made some tests with Apex families. Using the fastest speed grade I get approximately a relation of 2.5 between Slow and Fast model. 

 That was measuring tPD with a simple test design, combining a handful of inputs pins through a couple of LEs, to an output pin.  Assuming the Flex families are not that different, it seems that I can safely consider a rule of thumb of dividing by 4.5 from the Slow Model results on the slowest speed grade. In others words, I should constrain minimum tPD to be 4.5 times the value I really need.  Thanks again.

[Altera_Forum]

--- Quote Start ---  I can specificy a minimum tPD, but without Fast Corner, the best and fastest case PVT is not considered.  --- Quote End ---      --- Quote Start ---  If you're doing Tpds and there's a lot of logic between pins, you might have multiple paths between those pins. This is an estimate on only one of those paths, most likely the longest, but if you have a shorter path, that's the one that should be used.  --- Quote End ---    "Minimum" in Quartus timing constraints and reporting does not mean fast PVT. Any number labeled as "minimum" applies to whatever PVT timing model is currently selected, whether a slow model or fast model.  For any single timing model (which means each model separately for a device family that has a fast model), what you are seeing reported for minimum tpd is the fastest path at that single model of potentially more than one path, not the fastest of min and max numbers for a single path. When there is more than one possible path between the specified endpoints as Rysc mentioned, the min and max tpd values will likely be different for any single timing model. If reported min and max are the same, that's usually because there is only one path between the specified endpoints.  This also applies in other places where Quartus timing reporting uses "minimum" and "maximum" for numbers shown for a single timing model, not just for tpd.       --- Quote Start ---  Dividing by 4 from the fastest speed grade sounds indeed a lot. This would mean that if I'm using the slowest speed grade, I would need to consider the best case being something in the order of, possibly 10 times shorter than the worst case ???  --- Quote End ---      --- Quote Start ---  ... it's certainly possible that you can get shipped something faster than your slowest speed grade, so that's going to cut into your margins quite a bit right there.  --- Quote End ---    For newer device families that have a fast timing model, Quartus uses the same fast model for all speed grades. (You can easily see this in TimeQuest, where the slow operating conditions have the speed grade in the name but the fast operating conditions do not.) This allows for the possibility of an actually fast device being marked with a slow speed grade. The device meets its specs, so this is OK, but it means that a slower speed grade has more potential min-to-max variation over process.  In case the same thing applies to the old FLEX families, I suggest that you base your fast-model estimate on slow-model reported timing of the fastest speed grade regardless of which speed grade you are actually using. Use your fast-speed-grade APEX results to estimate your FLEX fast-versus-slow-model derating factor, then run timing analysis on the fastest speed grade in FLEX to estimate your actual fast-PVT results.  Compile with the speed grade you are actually using selected in Quartus. You can run timing analysis on the fastest speed grade without recompiling. Unless for some reason this capability isn't supported for FLEX, you can change the speed grade and rerun the Classic Timing Analyzer in the GUI or run quartus_tan at the command line with the --speed argument.