( ESNUG 456 Item 7 ) -------------------------------------------- [07/17/06]
Subject: ( ESNUG 455 #1 ) 2 more hands-on users yarp about Apache RedHawk
> 2) EM -- Prior to the benchmark, we suffered through our previous tool's
> (VoltageStorm 3.2.1-k and VSPE 4.1) Achilles' heal of thousands of
> false EM violations. The top 3 tools came in with:
>
> ttl-em-vios real-vios* false-vios worst-vio**
> RedHawk 457 421 36 2.76x
> CoolTime 2829 2119 710 16x
> VSPE/DG 4001 3344 657 3.98x
> BlastRail 528 ** ** ~3x
> PrimeRail 1353 ** ** ~2.5x
>
> * -- Due to fracturing differences between tools, real errors may
> get tallied multiple times. The top 3 tools' results were
> reviewed and deemed to have caught all real EM errors
> ** -- Of the top 3 tools' reported worst violation, only Apache's
> was a real/valid violation.
>
> BlastRail and VSDG made significant improvement strides during the
> eval. PrimeRail on the surface appeared to have reasonable results
> but did not provide a user-preferred reporting format.
>
> At this point, we pared away PrimeRail and BlastRail due to their
> insufficient competitiveness (at the time of eval) coupled with our
> limited human resources.
>
> - from http://www.deepchip.com/items/0455-01.html
From: Lief Erickson <lief.erickson=user domain=vikingstartech spot calm>
Hi, John,
We used Apache's RedHawk on 150, 130 and 90 nm, high switching networking
ASIC chips in a Magma Blast Fusion layout environment. RedHawk was the
only tool that could run large (10 to 20 million logical instance) designs.
It uses Apache's NSPICE simulator to calculate the switching current
profiles for dynamic voltage drop (DvD) and its reports highlight the high
power cells that are causing issues. We then assess which cells should be
replaced with a lower power cell or placed in a different location to
minimize the voltage drop. RedHawk can model a scenario where the I/O has
a different voltage supply, yet shares the same ground with the core
voltage. This allows us to increase or decrease the I/O ground supplies
based on the noise on the ground, and prevent it from propagating into the
core, or to use more I/O bumps for signals.
The initial Apache RedHawk setup for our first design took about 2 to 4
weeks to produce valid results. It now takes us 2 weeks to setup RedHawk's
static IR drop for new designs, and 4 weeks to get dynamic analysis working
(2 weeks for Static and 2 more weeks for dynamic) on our large designs.
When our ASIC test chips came back from production, we compared the samples
to RedHawk's reports to see how well their power numbers correlated. As an
early user of RedHawk, we worked closely with Apache on many chips and
reviewed and adjusted many of our assumptions to improve the correlation
over time; RedHawk's power numbers are now consistently within 5% of
silicon.
We used RedHawk to plot the VDD and GND waveforms; this is very important
for validating and checking the worst violations. We used its "what-if"
analysis to test adding metal, changing the current profile, adding decap
and adding power/ground, until we found the most effective method to
correct our DvD issues. One important issue that the VDD and GND core cell
waveforms show is the resonance frequency -- this oscillation on the power
supply shows up if the package (RLC, s-parameter) is not constructed
correctly. The power supply voltage source, instance voltage, and ground
current profiles are also used to ensure the 1) package is set up correctly,
and 2) the simulation time is of the correct duration.
Each cell's output VDD-VSS can be captured and used as input for RC
extraction and SDF generation, to assess the impact on timing. This delay
due to DvD is very important for 90 nm and 65 nm technologies. Incorrect
package RLC values can cause the Vdd/Vss waveforms to be either overly
pessimistic or optimistic. Back annotating the DvD is a helpful feature;
though similar to other layout tools, you must be able to calibrate the
delay to physically measured values. The package inductance and on-chip
capacitance directly affects the Vdd and Vss overshoot/undershoot on a
per cell basis.
One of the largest power issues we had was that Magma's Blast Fusion clock
tree synthesis (CTS) loaded different frequency clock trees differently.
This clock buffer loading was an issue where the data crossed the clock
domains. Another issue is when all the clocks switch at the same time
(minimum clock skew) at certain cycles, they can negatively impact the DvD
drop. As we analyze the different domains, we can cover all clock freqs
by setting up the DvD simulation time as 2.5 times the longest clock cycle.
RedHawk was very good at identifying this type of CTS issue. Blast Fusion
also grouped cells into clusters which switched at the same time, impacting
the neighboring cells voltage. RedHawk helped us to identify such cell
grouping so we could split up these cells.
RedHawk also found weak power/ground structures. For example, it helped
find areas where there weren't enough metal vias, so insufficient power was
supplied to the macros or cells. Apache added a feature to seek out power
and ground weakness (i.e. low power/ground metal or via density) and switch
a large % of the cells in those areas, which enables the validation of the
power/ground structure early in the design cycle.
- Lief Erickson
VikingStarTech, Inc. Raleigh, NC
---- ---- ---- ---- ---- ---- ----
From: Ludovic Fievet <ludovic.fievet=user domain=st spot calm>
Hi, John,
We used Apache's RedHawk on our multi-million gate 90 nm chip, for which we
now have working silicon. To run dynamic voltage drop analysis we needed to
have an accurate format and detailed models. So for std cells, we ran a
RedHawk characterization using SPICE simulation. The memories and pads were
imported in GDS format, while the switches were simulated with PowerGate to
create a model for dynamic & ramp-up analysis.
It was important to describe the package properly as a SPICE sub-circuit to
RedHawk. We ran our final analysis using a VCD (from Cadence NC-Sim) for
sign-off accuracy. The VCD file showed all activities in the chip during
a simulation pattern.
For routability reasons, we wanted the memories to have the minimum number
of grid connections. So we started with a small number of connections, then
based on RedHawk's vectorless dynamic analysis results, we inserted
additional vias to remove any discrepancies in the grid. When we did the
static analysis after this approach, we did not have any hot-spots over the
memories.
RedHawk Runtime Data
We launched the RedHawk analysis on a Linux 64 bit machine with 12 GB of
memory and with a processor running at 2.2 GHz.
Runtime Memory
APL characterization 8 hrs (on 4 CPUs) Max 400 MB
RedHawk's Drawbacks
- Memory usage could be a little bit lower (for dynamic analysis, it goes
beyond 12 GB). However, the "caching mode" enables it to run on machines
with less memory by efficiently using the disk instead of the RAM.
- Some errors messages were not clear enough.
RedHawk's positive features
- Easy to exploit results. E.g. RedHawk provides a list of worst Vdd or GND
for instances and nets that we can directly zoom to.
- Provides list of worst Vdd/Gnd for instances and nets.
- No data conversion -- Reads LEF/DEF/DSPF/.lib/CDL/SPICE, so we can take
the files directly from our flow.
- Quick LVS debug capability to locate Vdd-Gnd shorts early in the flow.
- Runs dynamic without patterns (vectors). We did most of our corrections
thanks to the dynamic vectorless analysis.
- Creates realistic patterns based on timing windows
- Easy to implement and is used early in the flow. The best proof of this
is that when we did signoff analysis with the VCD, we had no further
correction needed on the grid.
- Provides consistent results that are close to SPICE.
- What-If capability. We use the what-if a lot as it's very convenient to
make changes and see their direct impact while staying in RedHawk
environment. It helped us to enhance the pad ring and memories grid.
In summary, static analysis only flagged gross issues. We spotted most of
our issues through vectorless dynamic analysis, and made corrections using
the what-if flow -- so we were able to tune our power grid perfectly while
staying within RedHawk environment.
- Ludovic Fievet
STmicroelectronics Grenoble, France
Index
Next->Item
|
|
