( ESNUG 420 Item 5 ) -------------------------------------------- [10/22/03]
Subject: ( ESNUG 417 #7 ) Speeding Up CeltIC Runtimes In A PrimeTime Flow
> In one example, for a module of ~400K nodes, the basic PrimeTime timing
> run took approx 2 hours, which went to 4 hours when SI analysis was
> added. The CeltIC run to generate SI delay and slope annotations, along
> with sensitivity analysis took 3.5 hours. A 2 hour PrimeTime run using
> the delay and slope annotations from CeltIC is required to close timing.
>
> - Bill Griesbach
> Agere Systems Allentown, PA
From: Doug Roston <doug=user domain=cadence spot calm>
Hi, John,
We've been working w/ Bill Griesbach to optimize CeltIC runtime performance
within his PrimeTime-based timing flow. I would like to discuss a few of
the key highlights since I think these observations will apply to many other
CeltIC and PrimeTime users.
We made a number of modifications to CeltIC, starting with version 4.1
(December 2002), in order to speed the tool up without compromising its
accuracy. We added a number of improvements that in general sped up our
existing code by 2-3X Vs version 4.0, without changes in parameter settings.
However we also developed a new and much faster analysis mode called "low
effort mode" which does require modifying some input Tcl parameters.
To understand how "low effort mode" helps improve run-time performance, let
me describe briefly how CeltIC typically works. CeltIC uses a two pass
approach for "noise-on-delay" analysis. First it uses a fast but pessimistic
noise calculation to decide which nets need to be analyzed in full gory
detail. Second, the nets that qualify -- those with noise levels greater
than the user-specified "noise_thresh" -- are then analyzed using
on-the-fly transistor level simulation (CeltIC has a built in SPICE engine).
In "low effort mode" the transistor level simulation (now tagged "high
effort mode") is replaced by a much faster cell based approach where the
victim driver is modeled using a pre-characterized non-linear current model
driving a reduced interconnect model, as opposed to simulating the driver
transistors along with the detailed interconnect parasitics.
The "low effort mode" can be enabled in two ways. The first is to use the
command
"set_run_mode -effort low"
at the top of your CeltIC Tcl script. This forces CeltIC to use the cell
based approach for all noise-on-delay calculations. In general "low effort
mode" will improve performance 2-5X over "high effort mode". The runtime
reduction will be even more significant if you are using a lower than
default "noise_thresh". The cell based model ("low effort mode") gives
similar accuracy to our transistor model ("high effort mode") except where
there is severe non-linear behavior (large noise events) that can generate
very bumpy signals on the victim net.
The second, and generally recommended way to use "low effort mode" is to
restore the default "noise_thresh" and use
"set_run_mode -effort high" (default)
and add
"-all" to the "analyze_noise" command
as Bill describes in his article. This will cause noise-on-delay
calculations to be performed using transistor level simulation for nets
above "noise_thresh" and cell level modeling ("low effort mode") for all
other noisy nets. This combination gives the best of both worlds, best
accuracy for the very noisiest nets and best performance for the rest.
Using the right combination of "-all" and "noise_thresh" can really improve
your overall performance without compromising overall accuracy.
One caveat for using "low effort mode" is that it requires re-running
'make_cdb' (version 4.1 or higher) to re-characterize your noise libraries.
This should be fairly painless as it should take less than 1 hour per
library corner.
One other thing that you should be aware of is that using the "-all" option
is that it will generate a lot more entries in the incremental SDF file
created by CeltIC and consequently a more pessimistic timing result when
back-annotated to PrimeTime. This may be a good/bad thing depending on your
sensitivity to risk, time-to-market pressure etc. For example many of our
customers prefer only to back-annotate the significant delay changes from
crosstalk analysis rather than all the changes as they believe this is more
realistic. Of course back-annotation of all noise-on-delay changes is safer
but puts additional stress on timing closure.
Other changes we put in place since 4.0 include recommended run modes with
associated parameter settings for given process technologies (90nm, 130nm
and 180nm). This can be enabled using for example
"set_run_mode -process 130nm"
The different settings for different process technologies were designed to
optimize the trade off between run time and accuracy with the more advanced
technologies using less aggressive filtering of small cross capacitances and
faster default slews. We recommend most users adopt one of these run modes
rather than setting individual parameter settings.
Other tips for improving CeltIC's performance include using a local "/tmp"
and using timing windows and slews from either CeltIC's internal timing
engine or an external timer like PrimeTime (see ESNUG 416 Item 5
http://www.deepchip.com/items/0416-05.html).
To enable CeltIC's internal timing engine use
"set_parm timing 1"
before "load_netlist".
You will also need to read in timing libraries and timing constraints.
"read_dotlibs {stdcell.lib ....}"
before "load_netlist"
"read_dc_script timing_constraints.sdc"
after "process_netlist"
Finally one other major change we made in CeltIC 4.1 was to make noise
glitch propagation ("latch mode") the default. To turn this off use
"set_run_mode -noprop"
Noise propagation has been available for some time in CeltIC but we made it
default as we observed the number of glitch violations found by our users
went up significantly as they moved from 150 nm to 130 nm. This change has
little or no impact on CeltIC run time but will greatly decreases the time
taken to achieve signal integrity closure by significantly reducing the
number of false noise glitch failures.
- Doug Roston
Cadence Design Systems San Jose, CA
|
|
