( ESNUG 413 Item 4 ) -------------------------------------------- [05/29/03]
Subject: ( DAC 02 #21 ) Choosing Apache RedHawk Over VoltageStorm IR Drop
> Just started using VoltageStorm. Looks good but I don't believe the
> quantative results. Showed a 0.5 V drop in one section of my chip and
> 0 everywhere else. Didn't really make sense. I see clock tree
> synthesis being a major problem going forward (or deeper sub-micron).
> Capacitance (i.e. cross-cap) has a big effect on cell delay, so can't
> predict clock tree delays without doing a detail route. So Celestry
> isn't as useful as it seems, because we won't get those delays in
> reality and still have to go back and fix holds.
>
> - John Webster of Intel
> from http://www.deepchip.com/items/dac02-21.html
From: Arjun Rajagopal <arjun=user domain=ti spot calm>
Hi, John,
We used Simplex VoltageStorm before Apache. We moved away from Simplex for
extraction to Avanti Star-XT to align with the rest of our company and were
also looking for a better solution for IR drop in terms of capacity and
speed, both of which are satisfied by the Apache IR drop analysis tool,
RedHawk. Actually Redhawk is a new static and dynamic IR analysis tool from
Apache. Redhawk was fairly easy to setup and use and was fast and efficient
in memory usage.
The initial design we used for our eval was .13 micron, 3.5M gates, 600 Mhz.
The full-chip static IR drop analysis for both VDD and GND ran in ~30 min on
a Solaris machine with peak memory usage of 3.8 Gigs. Its static results
correlated well with previous runs using Simplex Voltagestorm. The dynamic
RedHawk IR analysis run took 8 hours on a Solaris machine with peak memory
usage of 3.8 Gigs.
Apache claimed a 3x speedup for the same design using a faster Linux
workstation with a hacked kernel to support upto 3.8 Gig memory. We have
not been able to duplicate the run, since our currently supported Linux
kernels do not go above 2 Gigs.
The setup for static analysis is simple. The inputs are .lib, DEF's for all
blocks, LEF's for cells and SPEF's for all signal nets & clock definitions.
RedHawk calculates the power and does the static IR analysis.
Redhawk also has good "what-if" analysis which let us explore fixes to power
grid. For example, we found a section in our grid where the metal1 VDD
rails without a metal4 connection caused a large drop. With the tool we can
manually add the metal 4 strap to the metal1 rails and the stacked vias to
the metal4 strap are automatically added. Re-extraction of power grid and
analysis takes another 10 minutes. RedHawk's fast-turnaround time enabled
us to explore different fixes to the grid.
We were able to use RedHawk at the early stages of the design, prior to
detailed route stage and before all blocks were completed.
The tool also has the ability to use mixed cell based and custom blocks.
For our chip we used a custom DSP core, memory blocks in GDSII, flip-chip
power bumps in GDSII and standard cell LEF/DEF for rest of the design.
We are also an early-adopter of Apache's full-chip vectorless dynamic
IR tool for our 90 nm DSP. RedHawk-SDL does full-chip dynamic analysis
including simultaneous-switching, on-chip inductance, package RLC, and
decoupling capacitance analysis. It lets us optimize decoupling
capacitance placement.
Issues we've seen with both the static & dynamic tools:
- The internal SPEF merge for signal SPEFs had some issues which
were resolved.
- We had to hack DEF's which were obtained from different flows
of blocks in different stages of the flow. Robustness of the LEF/DEF
parser for handling variations in formats can be improved.
- Library characterization of cells for dynamic IR is "design specific"
and needs to be run for entire design with SPEFs instead of a
one time run.
- Need more early power grid planning capabilities ( which is in the
works.)
- Need better plotting capabilities to plot ir maps from the tool
instead of having to capture using xv/gimp and running into color
map issues.
- Error messages are not descriptive enough.
- Documentation is not complete.
RedHawk's setup for dynamic IR is more complex than static. For greater
accuracy, it requires a detailed library characterization which captures
the typical loading and current profile for all cells in the design.
A full-chip PrimeTime run which captures the timing windows, slews and
clock information is also needed. RedHawk extracts intrinsic decoupling
capacitance. The user has to supply the information on explicit de-
coupling capacitance cells. One of the outputs of the dynamic IR analysis
is a decap density map which shows which areas of our chip need additional
de-cap and can be examined with its dynamic IR map. Our 8 hour run time
for RedHawk's dynamic IR analysis did not include the lib characterization
and PrimeTime timing runs which are part of its setup.
We are currently evaluating the results of the dynamic RedHawk IR analysis
on our design to see how it impacts timing, clock skew and insertion delay.
We're currently trying to verify the violations reported by the tool.
- Arjun Rajagopal
Texas Instruments DSP Dallas, TX
|
|
