( ESNUG 537 Item 9 ) -------------------------------------------- [03/14/14]
Subject: A user's first hands-on benchmark of EDI/PrimeTime vs. EDI/Tempus
> 1.) This year's #1 "MUST SEE" is the new Cadence Tempus STA tool that's
> taking a run at Aart's PrimeTime monopoly. I call it the Revenge of
> Rajeev; because instead of it being yet-another-CDNS-R&D-developed
> tool -- it was spearheaded by ex-Magma SPICE folk in CDNS who know
> the ugly crosstalk & SI side of STA. 50 M inst design in PrimeTime
> took 8.5 hours on 8 CPUs; Tempus did it in 58 min on 32 CPUs. The
> 20+ year old PT can't do multiple machines; Tempus written that way
> from the beginning. Tempus is NOT a repackaging of old Cadence ETS
> STA; it's NEW code. New path-based analysis (PBA) engine instead of
> old graph-based stuff. 100's M cell capacity. No SNPS-proprietary
> Parametric OCV (POCV), instead TSMC's open Statistical OCV (SOCV).
> Tempus does full flat, hierarchical, incremental timing analysis.
> Big question has/will TSMC certify Tempus for golden signoff STA?
> TI uses it. (booth 2214) Ask Ruben Molina. Freebie: Denali tix
>
> - "My Cheesy Must See List for DAC 2013"
> http://www.deepchip.com/gadfly/gad053013.html
From: [ Don't Shoot The Messenger ]
Hi John,
I would like to submit this anonymously.
We saw Tempus at DAC last year. We didn't have time to engage in any kind
of beta evaluation of the tool back then due to numerous tapeouts that we
had going during the summer. However, we were intrigued by the possiblity
of a viable alternative to PrimeTime inside our EDI flow plus the Cadence
claims of much faster STA runtime, distributed processing, and physically-
aware signoff timing closure. With some of our tapeouts out of the way, we
started to look at the Tempus in October 2013.
Because of TTM pressures in our industry, our chips have very tight design
cycle times -- we do TSMC LP 28 nm, 1 to 3 Ghz -- in 3 to 4 months. After
P&R, STA timing signoff closure takes us about 8 weeks with our EDI/PT flow.
(This is at the point in P&R were we've closed on 3 or 4 big MCMM corners
and then loop in PT<->EDI for the rest of the 42 corners.) This represents
50% to 65% of our overall design cycle and we expect this to get worse at
when we jump to either 20 or 16 nm.
In our eval we used a 13 M cell inst design. This represented a typical
size for us at 28 nm, but we expect designs to get ~3X to ~5X larger at the
next node. In our EDI/PT flow we typically use 4 CPUs to run our analyses.
To be a fair comparision, we only used 4 CPUs to evaluate Tempus -- even
though it claims it can run on any number of CPUs. We found:
- single scenario w/o SI 4 CPUs: runtime = 74 mins; memory = 15.36 GB
- single scenario w SI 4 CPUs: runtime = 89 mins; memory = 16.21 GB
The Cadence marketing guy claimed Tempus on a single machine gets throughput
of 15-20 M cells per hour using 8 CPUs. We found 10 M per hour with 4 CPUs.
Scaling to 8 CPUs makes the Cadence claim reasonable.
The most important thing for us was EDI/Tempus had cut down our analysis
runtimes in half versus our EDI/PT flow -- and this was with just 4 CPUs.
The best thing was Tempus physically-aware cut total ECO time from 8 weeks
down to 2 weeks and reduced our total loops from 27 to just 4. It appears
that EDI/Tempus does a bunch of simultaneous set-up/hold/leakage fixes that
PT doesn't -- hence PT needs more external loops -- since set-up & leakage
were OK, we primarily focused on hold fixes.
NOTE: This was based on an existing top level design with 8 major sub-
blocks and comparing the time it took to reach comparably clean states of
the design. To save eval time we felt we didn't need to bother doing a
full Mentor Calibre DRC clean signoff.
A few additional notes:
- Converting from our PrimeTime Tcl scripts to Tempus was NOT push
button. It took us 3 weeks to make that happen, but it was
ultimately well worth the effort. Making the transition easier
was the fact that we also use Cadence for place and route so we
were familiar with the commands.
- One thing we wanted in Tempus that was not there was PrimeTime's
Guided ECO where we could tell PT to focus on just 100 nets and
endpoints for an ECO. Tempus can do something like this with
workarounds but it should just add this functionality.
- At first we had some engineers who were worried about the new
reworked timing engine inside Tempus -- which is why we did a
detailed Spectre SPICE analysis of all of our nets. But when it
correlated within 2% to 4% they stopped worrying. Correlation
of EDI/PT to EDI/Tempus was ~3% for base delay with no SI, and
with SI it was ~4%,
There are other features within Tempus that we've just started scratching
the surface of -- that are not found in SNPS/MENT/ATOP. In particular,
distributed STA analysis over many CPUs in multiple compute servers, the
ability to run many timing scenarios in one timing session, multi-core and
distributed path-based analysis. We can not say if these claimed features
work or not (haven't tested them yet) but we'll be happy if they do.
Since our eval found Tempus is 100% viable as a replacement sign-off tool
to Primetime -- plus the fact TSMC is OK with Tempus-only analysis -- we've
now switched from EDI/PT to EDI/Tempus as our standard design flow.
- [ Don't Shoot The Messenger ]
Join
Index
Next->Item
|
|
