( ESNUG 417 Item 7 ) -------------------------------------------- [09/08/03]
From: Bill Griesbach <griesbach=user domain=agere lot palm>
Subject: Synopsys PrimeTime-SI vs. Cadence CeltIC + Standard PrimeTime
Hi, John,
Here's a dump of my experiences with CeltIC (and PrimeTime-SI).
We've been using CeltIC (and before it, PacifIC) for about 5 years. During
that time our design style has evolved from a near-full-custom approach to a
synthesis based std cell approach. CeltIC was adopted because it was the
only practical SIV solution we could find.
At the time, the only known alternative was Assura-SI, which had major
capacity problems and the only output it provided was a report of glitch
voltages -- it was left to the user to decide how much noise was too much.
The sensitivity report generated by CeltIC provided the filtering needed
to correctly prioritize repair work. In versions of CeltIC prior to 4.0,
the default method calculated sensitivity as a sort of AC voltage gain for
a given gate. A sensitivity whose magnitude approached or exceeded 1
indicated that the noise at the gate's input had reached the high gain
portion of the gate's transfer curve and the noise would be propagated
and possibly amplified.
CeltIC also provided incremental SDF to feed delay variations due to noise
into PrimeTime. Initially, no slope variations were generated to feed to
PrimeTime, and so the impact on cell delays was missing. Along the way,
the ability to generate slope annotation was added to CeltIC (not sure
what version).
After Cadence bought CadMOS, it appears that most of the development
work on the tool has focused on integrating it into their Nanoroute/SoC
Encounter flow at the expense of CeltIC the point tool. Many of the
default behaviors of the tool have changed in versions 4.0 and 4.2,
leaving us to scramble to get CeltIC to replicate results from earlier
versions.
About 4 months ago we began benchmarking Primetime-SI against CeltIC
with PrimeTime for timing. We initially found large differences in
predicted path delays, with Primetime-SI typically being much more
pessimistic. The differences were due to missing slope annotation
in our CeltIC/PrimeTime flow. When the noise impact on slopes is
accounted for (with the associated changes in cell delays), the
CeltIC/PrimeTime combo and PrimeTime-SI agreed relatively closely,
and matched HSPICE results to within a few percent.
Adding the SI analysis (2 iterations seemed sufficient for convergence) to
a PrimeTime run seemed to roughly double the analysis time. The CeltIC run
to get comparable delay/slope annotations required adding a "-all" option to
the analyze_noise command; without this option set, small incremental delay
annotations are lost due to filtering. This option appears to have little
if any impact on CeltIC run time.
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, though
Cadence is testing the incorporation of a timing engine which will enable
CeltIC to complete the timing closure task.
At present, the total run time results can't be compared since PrimeTime-SI
is not checking "functional" noise issues; glitches that can disturb flops,
and invalidate static timing by introducing transitions not predicted by
STA. This capability is being tested in PTSI by Synopsys, but requires
additional library characterization.
It appears that Synopsys is not going to provide the tools for performing
the necessary characterization. CeltIC has this base covered, and has been
enhanced recently to cover gnarly problems like multiple transitions on
clock nets (ripples on transitions that can end up amplified into extra
clock pulses). Sensitivity analysis, which is currently formulated as a
measure of the disturbance voltage on the output of a gate receiving a noisy
signal, is by far the best way to prioritize nets for repair, since it
accounts for the noise rejection properties of individual library cells.
CeltIC comes with make_cdb, a characterization program executed on SPICE
extractions of cells to create the noise library used by CeltIC.
Characterization of a full standard cell library over multiple PVT corners
can be completed in a few hours, or at worst overnight. The characterized
library contains tabular data for fast noise analysis and also SPICE
connectivity which allows CeltIC to engage a SPICE engine for nets with
significant noise.
It is yet to be seen how well Synopsys will do in adding glitch analysis to
PrimeTime-SI and how well Cadence will do in adding full timing capability
to CeltIC. At this point, a clean CeltIC stability report is a requirement
to validate the noise impact on timing analyzed by either a PrimeTime-SI or
a CeltIC-PrimeTime flow.
- Bill Griesbach
Agere Systems Allentown, PA
|
|
