( ESNUG 446 Item 3 ) -------------------------------------------- [09/01/05]
Subject: ( ESNUG 445 #11 ) The Cadence Follow Up On The PT-SI/CeltIC Letter
> We then ran PT-SI and CeltIC on a real 0.13 um design with lots of
> coupling. Using more complex real design testcase, PT-SI had better
> SPICE correlation than CeltIC. It is especially true when a victim net
> is coupled with many small couplings.
>
> - Ying Gao
> Qualcomm San Diego, CA
From: Trisha Kristof <trisha=user domain=cadence pot calm>
Hi, John,
I am a Product Engineer on CeltIC at Cadence Design Systems. I recently
read ESNUG 445 #11 posting from Ying Gao at Qualcomm. I would like clarify
and respond to some of the points Ying made with respect to CeltIC.
Noise Library Characterization and Accuracy:
> CeltIC has an advantage here with its own cell noise characterization
> engine that takes in device models, SPICE netlists, and the Synopsys .libs
> to generate .cdb noise libraries. We were able to create our libraries in
> a few hours. CeltIC achieves this runtime by cutting some of the SPICE
> netlists, and according to one of our library engineers, this results in a
> loss of accuracy.
Ying is correct. CeltIC's library characterization (make_cdB) is indeed
much faster (minutes) than Liberty SI creation (weeks according to a recent
ISQED paper!) but there is no loss in accuracy. CeltIC's characterizer
(make_cdB) runs SPICE simulations to characterize the relevant cell
information needed by CeltIC. The reason it is much faster is that CeltIC
doesn't require anywhere near as much information upfront as PT-SI. This
is particularly relevant for glitch noise propagation. In Liberty SI you
need to pre-characterize propagation tables which is both timing consuming
and not very accurate. In contrast CeltIC performs on-the-fly-transistor
simulation when there is sufficient glitch noise. Digital logic will
attenuate most noise glitches and only a few truly significant glitches
will end up at register end-points potentially causing design failures.
Consequently accurate glitch propagation is vital in reducing false
positives and enabling efficient SI fixing. I would encourage Ying to look
not only at comparing the accuracy of victim net glitches but also at how
noise propagation reduces the number of failures. We typically see orders
of magnitude less failures when using propagation.
> CeltIC achieves this runtime by cutting some of the SPICE netlists, and
> according to one of our lib engineers, this results in a loss of accuracy.
There is also no "cutting of the SPICE netlists" for characterization of
standard cells in CeltIC. For SI characterization of memories we recommend
customers black-box the memory bit cell as CeltIC only needs the first two
levels of transistors from the boundary for proper characterization. This
is a well-accepted flow given the unique requirements of huge memory blocks.
Several customers have shared their CeltIC accuracy comparisons with SPICE
in earlier ESNUG postings:
http://www.deepchip.com/items/0420-01.html
http://www.deepchip.com/items/dac04-23.html
http://www.deepchip.com/items/dac03-25.html
Ease of integration in the flow:
> Ease of integration into our flow:
>
> PT-SI has advantage here, because PrimeTime is our golden sign-off timing
> engine. So, all we need is just adding several lines of commands to our
> existing PT script.
>
> CeltIC is a bolt-on flow that is dependent on PrimeTime for the initial
> static timing analysis. Because CeltIC requires moving data in and out of
> different tools, we consider it slightly more error prone than the PT-SI
> flow. CeltIC does have a CTE flow that allows it to use its own internal
> timing engine, but this was not the recommended flow from Cadence during
> our evaluation.
Customers have found that CeltIC plugs into their existing PrimeTime flow
with the use of a simple Tcl script "run_celtic".
http://www.deepchip.com/items/0416-05.html
And with increasing usage, customers have driven several enhancements to
this "PrimeTime/CeltIC" interface. The "run_celtic" script is now re-
entrant from a PrimeTime session. This allows customers to re-run CeltIC
in a given PrimeTime session after they have made modifications to
constraints or the netlist.
run_celtic -celtic_cmd_file <Tcl Command File>
-do_only_nets {List of nets} // NEW
-use_prev_sdf sdfFile // NEW
-change_file ecoFile // NEW
-do_only_nets {List of nets}
Do CeltIC SI analysis only on these nets. This enables to quickly
see the effect of SI on selected nets.
-use_prev_sdf sdfFile
Annotate the difference from the previously annotated incremental
SDF file. Use this option during the second and consecutive runs
of run_celtic.
-change_file ecoFile
Provide list of instances to be resized. CeltIC will perform SI
analysis with these modifications done logically on the netlist.
The PrimeTime/CeltIC combination enables smart failure filtering and reduces
the number of problems to be fixed in the SI closure cycle. This
turnaround time can be further improved by using the internal CTE timer
inside CeltIC to generate and iterate on the timing windows. The CTE
timing engine is production proven at several customers as detailed in
an earlier ESNUG posting: http://www.deepchip.com/items/0427-08.html
- Trisha Kristof
Cadence Design Systems San Jose, CA
Index
Next->Item
|
|
