( ELSE 06 Item 21 ) -------------------------------------------- [ 06/23/06 ]
Subject: Sierra Pinnacle
THEY'RE LEGIT NOW -- In last year's report, quite a few users voiced cautious
skepticism about Sierra in DAC 04 #17. Actually they weren't actual hands-on
users of Sierra, but instead they were tire-kicking potential users. It was
that iffy. Pinnacle's since had its first tapeout and looks like it might
be a viable placer now. Their MCMM stuff competes directly with the "new"
Synopsys IC Compiler; but no surprizes there. Most of the Sierra founders
worked in the exact same Synopsys R&D group that IC Compiler comes from.
Sierra Pinnacle is apparently some ex-Synopsys folks who have created a
physical synthesis tool. It goes from gates to placed gates. The tool
optimizes concurrently over multiple modes and corners and can do up to
10 million gates flat overnight. They claim 2X to 3X better memory
utilization and speed than competitors but their key selling point is
design for variability.
- John Weiland of Intrinsix Corp.
We've been using Sierra's Pinnacle tool recently to handle multi-corner,
multi-mode (MCMM) optimizations, having worked with Sierra for a couple
of years now. In terms of supporting variability, I think Sierra is
ahead of the pack in terms of features and underlying architecture.
PTV variations are generally modelled through the use of multiple cell
libs and multiple RC extraction decks. Derating to achieve the same
effect can be pretty complicated, as the derating is not the same across
all cells in a library. Nor is the derating the same across layers in
the extraction deck. Derating is also not always linear, so corner
libraries are usually characterized from SPICE decks representing
min/typ/max corners (e.g 2 or 3 sigma process variation, -40/25/125
degrees C, 1.1V/1.2V/1.3V, etc.) Extraction decks can be made for max
or min RC and combinations thereof.
The Sierra tool supports concurrent optimization and analysis across a
number of extraction corners, operational modes, and libs -- without the
exponential increase in memory for each combination -- a real plus.
Pinnacle sets up with "n" extraction corners, (not just 2) such as
minR/maxC, maxR/maxC, minR/minC, maxR/maxC. These extraction corners
can then be applied to any number of operational modes and/or library
combinations. Also, all the optimization and analysis can be done
with OCV and CRPR (which can be enabled on a per-corner basis). The
overhead associated with OCV and CRPR is minimal so far. In our case
we worked 4 MCMM corners: 2 extraction corners and 2 operational modes.
Cell Library Extraction Mode Check
--------------------------------------------------------
worst maxR/maxC func setup & hold
best minR/minC func hold
worst maxR/maxC test hold
best minR/minC test hold
worst = Slow Process, Low Voltage, High Temperature
best = Fast Process, High Voltage, Low Temperature
To do this inside Pinnacle, we used following commands:
# set all the .libs read in with "_s_.*" in the name to the
# slowSetup corner
set_analysis_corner -enable true -crpr setup \
-setup true -hold false \
-corner slowSetup \
-process_technology CS101_10_wee \
-corner_max_library "[getDotLibPattern {_s_.+max}]" \
-corner_min_library "[getDotLibPattern {_s_.+min}]"
# set all the .libs read in with "_s_.*" in the name to the
# slowHold corner
set_analysis_corner -enable true -crpr hold \
-setup false -hold true \
-corner slowHold \
-process_technology CS101_10_wee \
-corner_max_library "[getDotLibPattern {_s_.+max}]" \
-corner_min_library "[getDotLibPattern {_s_.+min}]"
# set all the .libs read in with "_f_.*min" in the name to
# the fast corner
set_analysis_corner -enable true -crpr hold \
-setup false -hold true \
-corner fast \
-process_technology CS101_10_wee_min \
-corner_max_library "[getDotLibPattern {_f_.+max}]" \
-corner_min_library "[getDotLibPattern {_f_.+min}]"
# create functional and test modes
define_design_mode -design_mode functional define_design_mode
-design_mode test
# enable functional mode, for setup and hold corners
set_design_mode -design_mode functional \
-enable true \
-corner [get_corner -filter "@enable && (@setup || @hold)"]
# enable test mode hold analysis only
set_design_mode -design_mode test \
-enable true \
-corner [get_corner -filter "@enable && @hold"]
read_constraints -mode functional $sdcDir/functional.sdc
read_constraints -mode test $sdcDir/testMode.sdc
Obviously if our design had multiple functional modes we would have added
these into the mix, but it didn't. Then again, a functional mode isn't
really a variability issue.
- Paul Little of Fujitsu Microelectronics America, Inc.
We used Pinnacle's MCMM to tapeout one of our designs recently when we
were in serious trouble with our existing flow.
Design Specs: ~800 K instances, 2 modes (TBI & CDR), 4 corners
(slow corner for max condition, fast corner for min
condition, hold best & hold worst corners for hold
with OCV in min and max conditions), 6% OCV
Our old flow was:
Design Compiler (RTL synthesis)
FE (floorplanning, placement, CTS)
NanoRoute (detail routing)
Simplex (RC extraction)
PrimeTime (timing and IPO)
Voltage Storm (SI / noise check)
PrimeTime (signoff)
Some of the problems with this flow:
1. non-convergence -- FE could take only one timing constraint
file at a time, setup/hold time is fixed sequence, a lot of
manual work to adjust cell placement, useful skew manually, and
many unnecessary iterations. Even if we did fix hold in some
corner, it made the setup worse in some other corner. Flow was
not converging.
2. large clock skews -- which created large hold time problems.
Moreover, hold buffers were added in high utilization area
causing congestion, de-tour routing and new setup problems.
3. correlation Issues -- there were large differences between FE
and PrimeTime timing. Big capacitance / long nets causing
large differences resulting in new setup/hold time problems
and more iterations.
4. noise on clock nets -- large amount of noise observed on the
clock nets created by FE. 1) Some clock nets created be FE CTS
were large in span and had large fanout, therefore they picked
up mode noise. 2) roots of CTS are defined after clock MUX
logic; long wire/big cap net were left unbuffered between real
clock source and root of CTS and caused noise problem later.
Our new flow:
Design Compiler (RTL synthesis)
FE (floorplanning)
Pinnacle (CTS, post-route optimization) <-- added Sierra here
NanoRoute (detail routing)
Simplex (RC extraction)
PrimeTime (timing and IPO)
Voltage Storm (SI / noise check)
PrimeTime (signoff)
What it got us:
1. MCMM -- (TBI and CDR) and corners (slow corner for max
condition, fast corner for min condition, hold best & hold
worst corners for OCV). Pinnacle reduced the 500 psec
setup violation in FE to less than 90 psec in the first run.
2. Pinnacle CTS reduced the skew by reducing the number of hold
buffers added in high utilization areas. Correlation was
much better since the number of long detour nets was
drastically minimized.
3. Pinnacle correlated very well to our signoff tool PrimeTime,
and it minimized timing violations post-route. We used a
margin of 100 psec on setup and 20 psec on hold.
The final results were -100 psec setup violation with 300 psec clock
jitter and -60 psec hold violations in IO with margin. All hold was
closed inside the core. Our old flow was stuck at -500 psec for setup
and the hold fixing was not possible because of bad correlation. The
results were achieved in days instead of months with the old flow.
After our tapeout was done, we re-ran the same design in Pinnacle from
the beginning. This included placement + pre-CTS + CTS + post-CTS
optimization. The results were better than our tapeout database.
Old Flow Pinnacle flow
-------------- ----------------
final Si utilization 79.0 % 76.4 %
congestion 0.08 % 0.03 %
worst setup slack -90 psec +183 psec
total setup slack -2500 psec 0 psec
worst hold slack -110 psec +44 psec
total hold slack -320 psec 0 psec
runtime - - - - 12.5 hrs
Here was the final MCMM variability report from Pinnacle. This timing is
with additional margins (500 psec for setup and 50 psec for hold).
---------------------------------------------------------------
| | WNS | TNS | #Viol | WHS | THS | #Viol |
|-----------------+------+--------+-------+-----+-----+-------|
| TBI(slow) | -317 | -17983 | 196 | 85 | 0 | 0 |
|-----------------+------+--------+-------+-----+-----+-------|
| TBI(fast) | -ne- | -ne- | -ne- | 1 | 0 | 0 |
|-----------------+------+--------+-------+-----+-----+-------|
| TBI(hold_worst) | -ne- | -ne- | -ne- | 0 | 0 | 0 |
|-----------------+------+--------+-------+-----+-----+-------|
| TBI(hold_best) | -ne- | -ne- | -ne- | -6 | -23 | 7 |
|-----------------+------+--------+-------+-----+-----+-------|
| CDR(slow) | -317 | -17983 | 196 | 85 | 0 | 0 |
|-----------------+------+--------+-------+-----+-----+-------|
| CDR(fast) | -ne- | -ne- | -ne- | 1 | 0 | 0 |
|-----------------+------+--------+-------+-----+-----+-------|
| CDR(hold_worst) | -ne- | -ne- | -ne- | 0 | 0 | 0 |
|-----------------+------+--------+-------+-----+-----+-------|
| CDR(hold_best) | -ne- | -ne- | -ne- | -6 | -23 | 7 |
---------------------------------------------------------------
"-ne-" : Not Enabled
We want to try the latest Candence Encounter in multi-mode optimization
capability and compare the results in the future. As far as IC Compiler
is concerned since it can handle only 2 scenarios it won't work for us;
we typically have 3-5 modes and 3-5 corners in our designs. Since we
have variability issues from multiple corners/modes, Pinnacle is the
only way to go (for now.)
- [ An Anon Engineer ]
Index
Next->Item
|
|
