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

<ctaniguchi1@gmail.com> wrote in message 
news:1185995501.496399.287000@q3g2000prf.googlegroups.com...
> 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
>

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

Mike 

On Aug 1, 12:52 pm, "Mike Lewis" <some...@micrsoft.com> wrote:
> <ctaniguc...@gmail.com> wrote in message
>
> news:1185995501.496399.287000@q3g2000prf.googlegroups.com...
>
> > 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
>
> I don't think primetime supports the FPGAs .. does it?
>
> Mike

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

On 1 Aug, 20:11, ctaniguc...@gmail.com wrote:
> 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.

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

Cheers,
Jon

ctaniguchi1@gmail.com wrote:

> Has anyone recently done a comparision of the utility of Primetime vs.
> Xilinx or Altera timing analysis engines?

Don't know about Primetime, but
the latest spin from altera promotes
Synopsys Design Constraints (SDC) format:
http://www.fpgajournal.com/whitepapers_2007/q2_altera_1.htm

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

> Don't know about Primetime, but
> the latest spin from altera promotes
> Synopsys Design Constraints (SDC) format:http://www.fpgajournal.com/whitepapers_2007/q2_altera_1.htm
>
> 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.

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.

On Aug 1, 9:29 pm, Paul Leventis <paul.leven...@gmail.com> wrote:
> 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.

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

> 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?

Hi Tommy,

Take a look at the TimeQuest Analyzer Quick Start Tutorial (http://
www.altera.com/literature/hb/qts/ug_tq_tutorial.pdf).  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.

On 1 Aug, 13:10, ctaniguc...@gmail.com wrote:
> On Aug 1, 12:52 pm, "Mike Lewis" <some...@micrsoft.com> wrote:
>
>
>
>
>
> > <ctaniguc...@gmail.com> wrote in message
>
> >news:1185995501.496399.287000@q3g2000prf.googlegroups.com...
>
> > > 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
>
> > I don't think primetime supports the FPGAs .. does it?
>
> > Mike
>
> 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- Hide quoted text -
>
> - Show quoted text -

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

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!  ;)