( ESNUG 427 Item 8 ) -------------------------------------------- [04/14/04]
From: Sampath Oks <okss=user domain=taec.toshiba spot calm>
Subject: CeltIC 4.2 Benchmarks 2x Faster Plus Its PrimeTime Correlation
Hi, John,
We have been doing a CeltIC 4.2 evaluation at Toshiba America (TAEC),
San Jose, California. We use CeltIC at the post route stage for cross
talk analysis and repair to fix glitch/delay violations due to cross
talk.
Cross talk prevention is done here by:
a) Using tight design rule constraints during optimization
b) Enabling cross talk aware routing in Nanoroute or Warp Route. We
found that just enabling cross talk aware routing avoids most of
the noise problems before any fix is required.
After post route design optimization when timing is met, we run
CeltIC for cross talk analysis.
CeltIC 4.2 can generate repair file for fixing noise violations in
a number of formats including SE, PKS, FE, Nanoroute. We can also
specify the type of fix such as buffer insertion, resizing, spacing,
shielding, etc.
I found some improvements in CeltIC 4.2 when compared to CeltIC 4.0:
1) CeltIC 4.2 has much better TAT. I ran CeltIC 4.2 and found that
it is at least 2x faster than 4.0. Cadence claims about 2x-5x
improvement in speed, but I have seen only about 2-3x faster run
times. This is valuable on 1 M inst designs.
Benchmark results on a 234 k instance design, 0.18 um
Run times on Solaris:
CeltIC 4.2 : 13 hrs 5 mins
CeltIC 4.0 : 25 hrs 45 mins
Speed improvement: ~2X
Of course when the same design is run on Linux, the run time is much
faster, only about 48 mins using CeltIC 4.2.
2) Default Latchmode capability and ability to generate repair commands:
Latchmode analysis in CeltIC is basically propagating the noise on the
victim to a number of stages until you reach a register device
(flip-flop/latches etc) and check for functional failure in the
register. In CeltIC 4.0 one can turn on latchmode as a separate
analysis but would not generate a repair file for fixing noise due
to latch failure. In 4.1/4.2 latchmode is default and this can also
generate repair file. Since latchmode will supposedly show the real
errors that cause functional failure and suppress many false noise
violations, it can pinpoint the net to be fixed which caused the
latch failure. So you will see a great reduction in number of
violations with latchmode.
3) CeltIC CTE timing window generation capability:
The CeltIC 4.2 had a new capability to generate TWF (timing window
file) through internal iteration using its common timing engine (CTE).
Previously with CeltIC 4.0 we used to run CeltIC for cross talk
analysis and PrimeTime to generate TWF and iterate between CeltIC/PT
until we get a convergent TWF. But now we can run TW based cross talk
analysis within CeltIC itself without the need of running PrimeTime
for TW generation making the flow simpler and quicker runtimes.
The use of a Timing Window File (TWF) helps in reducing the number of
cross talk violations by filtering the glitches which are harmless based
on the signal arrival times and peak noise alignment.
We did a correlation study of TW generated using PrimeTime vs CeltIC CTE.
Average differences between PrimeTime and CeltIC CTE calculated "arrival"
times for 715 k nets. These differences expressed as % of PrimeTime values
CeltIC CTE min rise arrival time = +6% off of PrimeTime's results
CeltIC CTE max rise arrival time = -4% off of PrimeTime's results
CeltIC CTE min fall arrival time = +6% off of PrimeTime's results
CeltIC CTE max fall arrival time = -4% off of PrimeTime's results
Average differences between PT and CeltIC CTE calculated "slew" times
for 715 k nets. Differences expressed as % of PT values.
CeltIC CTE min rise slew time = +9% off of PrimeTime's results
CeltIC CTE max rise slew time = -3% off of PrimeTime's results
CeltIC CTE min fall slew time = +6% off of PrimeTime's results
CeltIC CTE max fall slew time = -8% off of PrimeTime's results
The correlation is quite good, but Cadence is fixing some large differences
on certain nets. With this new flow we need just one run of CeltIC with
internal iteration, instead of two runs of CeltIC (w/ and w/o TW) and one
run of PrimeTime for TW generation previously, thus improving TAT and
simplifying the flow.
One known bug:
CeltIC SDF annotation: CeltIC 4.2 fails to back-annotate SDF file for
certain type of connections in the design when only SPEF data is read in.
This problem was seen when running CeltIC using TW capability
Reading a Verilog along with SPEF fixes this problem.
- Sampath Oks
Toshiba San Jose, CA
|
|
