Static Timing Analysis Using Primetime for FPGAs

Hi,

Has anyone recently done a comparision of the utility of Primetime vs. Xilinx or Altera timing analysis engines? Anyone have an data to support if Primetime actually catches more static timing errors then the FPGA vendor tools. What are the pros / cons of using Primetime for FPGA timing analysis.

Thanks,

Craig

Reply to
ctaniguchi1
Loading thread data ...

I don't think primetime supports the FPGAs .. does it?

Mike

Reply to
Mike Lewis

Hi Mike, Both Altera and Xilinx tools have to option to output a netlist for primetime and some appnotes. Just not sure if it really will buy me anything to invest in the tool. I use primetime on the ASIC side but have not used it for FPGAs.

Thanks,

Craig

Reply to
ctaniguchi1

Con: Your bank account will be $30k down.

Cheers, Jon

Reply to
Jon Beniston

Don't know about Primetime, but the latest spin from altera promotes Synopsys Design Constraints (SDC) format:

formatting link

Quartus now supports this and their simpler "classic" STA. I've tried both, and they work, but I don't know enough to have a preference yet.

-- Mike Treseler

Reply to
Mike Treseler

format:

formatting link

Hi Mike,

We recommend that users switch to using TimeQuest. There are a number of benefits to doing so. In general, TimeQuest is better at handling complex timing assignments and analysis (multi cycles, related clocks, recovery/removal analysis, multi-corner timing analysis, etc). It also has a powerful, standard language (SDC) for specifying constraints, and is fully Tcl driven. It is really quite powerful.

An addtiional benefit is you will get a few % faster design performance using TimeQuest as your analysis engine, especially on the latest Altera FPGA families. Because of some of the more advanced analysis capabilities in TimeQuest, complex timing phenomena that we needed to "guardband" in the classic Timing Analyzer can now be analyzed less conservatively (but still correctly).

In short, you get more robust timing analysis and better design performance by moving to TimeQuest. There is a learning curve, but once you are over it I'm sure you will appreciate the added power that this tool gives you.

Regards,

Paul Leventis Altera Corp.

Reply to
Paul Leventis

I'm not a EE and have always been a bit daunted by the more obscure timing analysis. Assuming that I use only synchronous logic and the only timing constrain I used in the "classic tool" was on the clock, is there any benefit for me switching to TimeQuest and what to I need to do for such a trivial constraint?

Thanks, Tommy

Reply to
Tommy Thorn

Hi Tommy,

Take a look at the TimeQuest Analyzer Quick Start Tutorial

formatting link
One advantage from using TimeQuest will be a small (few %) increase in achieved performance in recent FPGA families. Another is that recovery & removal analysis and optimization will be performed by default, which can identify timing and fix problems on asynchronous signals in your design. You also get a much more powerful GUI/interface that allows you to see more information on your failing paths.

And don't forget that if you learn TimeQuest you'll be one step closer to correctly analyzing more complex timing relationships in the future!

Regards,

Paul Leventis Altera Corp.

Reply to
Paul Leventis

Craig,

At least for Altera, Quartus II definitely has an option to output a PrimeTime netlist with the associated SDC constraints. It also outputs a Tcl script to help you load the libraries. But the timing models are generated to match the timing models used by Quartus, so you don't get any more or less accurate timing results using PrimeTime. When compared to Xilinx tools or the Quartus Classic Timing Analyzer, you probably do get a more advance analysis. Like a good ASIC timing analyzer, PrimeTime is more conservative. For example, in PrimeTime, all clocks are assumed to be related to each other, and the user needs to explicitly enter set_clock_groups or set_false_paths to avoid this. But my experience is that Altera customers who used PrimeTime usually do so because they already have a PrimeTime license (for their ASIC work) and they have a number of scripts that they have written over the years for PrimeTime. Some customers that work with the Department of Defense also use PrimeTime as a secondary verification tool (as I believe they need to show independent verification tools).

Note that one reason few use PrimeTime is that the FPGA timing analyzers are consider good enough and you still need to give the place and route tool timing constraints so for both the Xilinx and Quartus flows, you need to enter the timing constraints in the FPGA tools first, and then either have them automatically convert to an SDC or enter them again in an SDC file. For both the Xilinx Timing Analyzer and the Quartus Classic Timing Analyzer, converting the constraints from the respective proprietary format to SDC is extremely difficult (you could even argue impossible). This is because the way the timing engines deal with timing constraints is completely different from one another and when converting to an SDC, the tool needs to make several assumptions. Quartus II makes a very good attempt and can convert most assignments successfully. Last I checked (a few years ago), the Xilinx tool had some limitations in the conversion.

Since we introduced the new TimeQuest Timing Analyzer (in V6.0), it is very easy for customers to use PrimeTime. The reason is that the user enters the SDC directly into Quartus II, and the required conversion is mostly about mapping node names (i.e. SDC collections) to match the PrimeTime Netlist Quartus II generates. But the constraint syntax itself is left as is. No assumptions are required.

But once you try TimeQuest, you will be surprised by how good the analysis is, and how good the usability is, and finally, how similar it is to PrimeTime. You will likely see no need to re-analyze with PrimeTime. TimeQuest SDC support is basically a perfect match to PrimeTime implementation, and it supports all the advanced constraints that you can think of. FYI, it is critical that we have a perfect match to allow us to support our HardCopy II Structure ASIC design flow where the customer needs to sign-off with TimeQuest, and then a netlist and SDC is generated for the HardCopy Design Center to run the final place and route followed with final sign-off with PrimeTime. The fact that TimeQuest and PrimeTime implementation of SDC match is a big part of our seamless migration. I personally believe TimeQuest has the power of PrimeTime with the usability that Altera is so famous for.

-David Karchmer Altera Corp

Reply to
dkarchmer

TimeQuest is not quite PrimeTime, but a very impressive STA tool especially as part of a low-cost suite. Coming from a Design Compiler / PrimeTime background, I managed to find many of the kinks and shortcomings in early versions of TimeQuest, and Altera worked through them quickly and diligently.

I could probably still find a few SDC constraints it doesn't support (or support exactly like PT), but it's been good enough for a HardCopyII tapeout.

As far as accuracy goes, when Quartus/TimeQuest generates a netlist for PrimeTime, it also generates the SDF timing data, which is coincidentally the exact same numbers TQ computed. PT reads the SDF and obviously reports the same numbers as TQ, so PT adds no value there. If you don't use the SDF, then PT's calculations are garbage, because PT is optimized to do deep submicron timing calculations based on SPF/SPEF and other detailed physical information that it just doesn't get from Altera's libraries or placement files.

However, if you're fluent in Tcl scripting and familiar with PrimeTime, PT offers a lot more powerful netlist navigation commands for finding and reporting on certain nodes, collections of nodes, and so on. Since those are really API commands instead of SDC constraints, Altera does not have to support them to be SDC compliant. As a result, some of my fancy PrimeTime scripts won't run in TimeQuest.

I also found that some of the naming conventions were not the same in the TQ netlist/database and PT netlist/database, and areas like clock pins on a source-synchronous DDR output were not handled correctly a few revisions ago (I haven't revisited them lately).

Another oddity is that TQ makes some kind of modifications to the database when operating on it (and I really disapprove of that). I typically open 4 STA windows (HardCopy fast, HardCopy slow, Stratix fast, Stratix slow) and analyze them all as one big interactive session. PrimeTime has no problem with this, but since the Quartus max and min data for a Stratix run winds up in the same directory, you can't (couldn't a few revs ago) analyze max and min simultaneously in TimeQuest. However, I could compare Stratix fast and HardCopy fast side-by-side (ditto for slow corner), but never all 4 at the same time in TQ.

As far as performance goes, TQ (standalone) is fast. As the integrated timing engine used during quartus_fit, it seems to run faster and produce faster designs (on my limited testcases).

As far as whether PT catches more violation than TQ, I don't really think that's quite the issue. Both only report timing on paths that are constrained (be default), so if you've missed some constraints, neither tool can report a timing violation. In both tools you can check for unconstrained paths, and both tools do a good job of catching them. For unconstrained paths, you can set a variable that allows PT to report them with the report_timing -from -through -to commands. I think TQ requires a report_path command or something slightly different in that case (another minor annoyance).

Summary: PT = no major advantage for FPGAs, except in netlist navigation and scripting (and vendor independence) TQ = very good imho, but not in the same ballpark as PT. (The $50K+ price difference and maturity of the tool might have something to do with that! ;)

Reply to
jjohnson

I had a quick look at the 'SDC and TimeQuest API Reference Manual' this morning. It looks pretty good at first sight, but some of the omissions look like they might be a problem. It's got the basic all_clocks/inputs/outputs/registers, for example, but doesn't support any options on all_inputs/outputs/registers. how do you do something simple like

report_timing -from [get_ports {CLK}] -to [all_registers -clock CLK - clock_pins]

?

The filter option on the get_ commands is much more limited than the PT filter option. Collections also look very limited; no add_to_collection, remove_from_collection, filter_collection, etc. Still, it looks pretty good for an FPGA tool.

I have to admit that I don't understand what the big deal in FPGA timing is. All the hard work has already been done by the big-$ tools, before the customer even starts a design. The FPGA tool then just summarises what PT/whatever has already told it. So, if you're an end-user, what's the point of using PT *again* to get back the same numbers?

Evan

Reply to
Evan Lavelle

For a conservative designer with a rational synchronization plan, I agree. Certainly I can't move devices around, and I find it difficult to beat the vendor tools at floorplanning.

I find that my time is better spent at the code and device selection level. Maybe I have to add some latency. Maybe I have to spec a faster part.

-- Mike Treseler

Reply to
Mike Treseler

I'm not sure that I made myself clear - my point was that (a) it must surely be a lot easier for an FPGA vendor to write an FPGA timing analyser, than for an EDA vendor to write a 'real' analyser, and (b) that, at first sight, it seems pointless to additionally run PT as well as the FPGA vendor tools.

The only thing that PT can bring to the party is, I think, an ability to effectively query the timing database. It can't give you any new numbers, since it only uses the information that the FPGA vendor gave it in the first place, and the FPGA vendor probably got that information from PT anyway.

I'm not suggesting that you don't run STA, as well as a timing sim for anything that's not trivial.

Evan

Reply to
Evan Lavelle

That was clear. I was on a tangent about eliminating the need for complex timing constraints in the first place by better structuring the design.

-- Mike Treseler

Reply to
Mike Treseler

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.