( ESNUG 545 Item 6 ) -------------------------------------------- [12/12/14]
Subject: User finds Tempus-TSO fixes PrimeTime/Encounter timing ECO churn
> - The new Tempus-ECO gives predictability. Using it has been positive.
> Previously, we used both internally developed and PrimeTime-ECO. With
> both old flows ECO predictability was iffy in highly dense regions.
> We were forced to limit what types of optimization tricks that could
> be deployed and both old ECO flows often put us into "ECO churn".
>
> Because Tempus-ECO is physically aware, it gives us predictability.
> It's more than just reading LEF. From what we've seen, it does full
> placement legalization and checking. It does aggressive optimization
> tricks -- more than just sizing and buffer insertion. While the full
> suite of ECO tricks are not yet there (e.g., wire/layer assignment,
> complex remapping, etc.), what is there is a leap forward vs. what we
> could do in the past with either our custom tooling or PT-ECO.
>
> - from http://www.deepchip.com/items/0545-01.html
From: [ Asterix, the Gaul ]
Hi, John,
Please keep me anon.
Last December we taped out a TSMC 28 nm 9 million instance chip which had
20 signoff scenarios/views. Althought our PNR was in EDI, for signoff, we
used to use PrimeTime with CDNS CeltIC incremental delay back annotation
and glitch check.
OUR CHURN NIGHTMARE:
Because of timing modeling mismatches between PrimeTime and EDI, we also saw
the exact same ECO churn that this user mentioned in ESNUG 545 #1. This
churn was extremely frustrating for our management because we couldn't tell
them if or when timing was going to close. "Is it today? Next week? Next
month?" -- management hates that!
Also, ECO's for 20 signoff scenarios/views was just a mess. They're all
being applied at the same time. One ECO can cancel another ECO. Or make
the chip unclosable.
Also (part II), our PrimeTime ECOs weren't physically aware, so parasitics
could unpredictably vary based on wherever EDI placed the new PT ECO cells.
We used Tempus only experimentally at first. But then we switched fully
to Tempus after Cadence announced their new fast delay calculation engine
inside Tempus.
CORRELATION STUDY:
At first, while their new delay calc sped up Encounter and STA runtimes, we
had serious doubts as to whether Tempus really could do signoff quality SI.
Our local CDNS FAE came over to our office and helped us perform correlation
checks with us.
Here's our TimeEX Tempus vs EDI correlation plots:
(click pic to enlarge)
Abs Diff 3-Sigma Worst Neg Diff Worst Pos Diff
1.5 psec 6.0 psec 2.0 psec 8.0 psec
The difference of both clock arrival and data arrival were all within CDNS'
claimed 4% including SI. The slack difference was also small, e.g. on our
CPU block the average difference was only 1 psec, with the worst negative
difference -2 psec and worst positive difference 8 psec.
We were happy with the correlation plus the faster Tempus runtimes. Before
it was nearly 10 hours to run our whole chip plus SI analysis. Now it's
only 1 hour over 16 CPUs. That's close to their 10 M instance-per-hour
claim plus a 10x speed up.
TEMPUS-TSO VS. PRIMETIME-ECO:
Since power is a major concern for us, physically-aware timing ECO's are
something we focus on a lot. We used Tempus-TSO for both leakage and hold
on all of our blocks for post-layout power recovery. Two blocks:
initial final
size and node HVT+UHVT ratio HVT+UHVT ratio
Block 1: 0.9 M inst, 28nm 54% 74%
Block 2: 1.9 M inst, 28nm 67% 95%
Tempus-TSO kept timing in both (actually all) of our blocks.
Tempus-TSO's hold opt also had good runtimes compared to EDI's post-route
hold opt. For some blocks, it closed all the hold violations without any
detours back into routing.
There is a unique command, which only Tempus has, which we used a lot:
report_timing -point_to_point
It is able to trace the worst delay path between a pair of from-to pins.
We found it was very useful during our DDR PHY to IO skew checks.
PESSIMISM:
Come to our final timing signoff, we ran PrimeTime-SI. It generated more
pessimistic timing results than Tempus did. We felt that PT-SI's added
pessimism is bad because it lowers the frequency of our chip's clock.
We found it a little hard to close those PT-SI timing violations. So to
meet our schedule we decided to tapeout directly using only the Tempus
timing signoff results.
The chip came back in February. With many testings performed, it passed.
GOTCHAS:
At the time of the tapeout:
- Tempus optimization was limited to simple buffer insertion/removal
and sizing. More complex techniques like clock skewing or logic
restructuring could improve setup violations. We hear that these
are in the works.
- We also didn't like that we couldn't force ECO changes when vacant
space wasn't available. Thankfully this has been fixed since the
design was taped out. We know results won't be as predictable if
cells overlap but expert users need the flexibility when tools
run out of gas.
- Tempus doesn't do noise-glitch repair. It can analyze for glitches,
but it should also automatically repair them.
- Tempus-TSO didn't run inside Encounter. Odd for a Cadence tool.
- We like that Tempus-TSO does an auto-check to see that all the ECO's
don't conflict with each other. Don't change this!
After all this, our management is now confident with Tempus for signoff
in our EDI flow. Cadence got around around the PrimeTime/EDI mismatch
with Tempus.
- [ Asterix, the Gaul ]
---- ---- ---- ---- ---- ---- ----
Related Articles
User goes full CDNS EDI/Tempus/GigaOpt/GigaPlace/CCopt/ECO/synth
A user's first hands-on benchmark of EDI/PrimeTime vs. EDI/Tempus
Join
Index
Next->Item
|
|
