( DAC 03 Item 31 ) ----------------------------------------------- [ 01/20/04 ]
Subject: Apache RedHawk-SDL & NSPICE
RIGHT PLACE, RIGHT TIME (Part II): If you were an EDA company that focused
on signal integrity, this was your DAC. It's that going to 130 nm and lower
thing. Since Apache has two tools in that space, lots of people had lots to
say about them! Talking 8 pages here. (Be sure to check out the Sequence
section of this trip report, too!)
We are just really starting to make traction on our evaluation of
Apache's RedHawk-SDL. All I would say now is that it is a bit immature
which is of no surprise. One of the claims that we are attempting to
substantiate is inductance modeling. Please check back in a month or
two.
I should say that there are constraints on the AMD side which also
affect the pace of this evaluation.
- Kyle Landry of AMD
I've really just started digging into the Apache tool in the past couple
of weeks, but I can give you some of my early impressions.
One of the strengths that Redhawk has is the ability to do dynamic
voltage drop analysis at the full chip level. I have yet to run the tool
on our entire chip, but have run a ~100k instance block which took about
3 hours to complete on a 32-bit Linux box. So the runtime and memory
management is very good. In terms of accuracy, the results have been
believable when compared to some small scale SPICE simulations we did
early in the project. Also, their statisical (vectorless) approach is a
quick way to do dynamic simulation when a VCD isn't available. (I've
yet to do a comparison of vectorless vs. VCD.)
Another nice feature of the dynamic analysis is the ability to look at
decoupling cap density and the contribuition it has on the supply drop.
Redhawk will recognize supply decoupling from intended decoupling cap
cells, and also from the power supply and non-switching cells. For both
area savings and yeild/reliability we're hoping to use the tool to more
efficiently place (and remove) decap.
One major weakness in the tool is it's ability to handle custom hard
macros, especially for stand-alone analysis. Redhawk is a standard-cell
level analysis tool (not FET level). It has some data preparation tools
to convert GDS to DEF/LEF/lib, but it is very difficult to then go into
this model and enable/disable current sources to get a realistic
activity picture. The model isn't back anotated with instance names
from the original netlist.
The user interface is a bit unfriendly, and the reports that are
generated could be more detailed. In general all the information you
need is available if you're willing to dig around in the "un-documented"
output files. The documentation is somewhat incomplete, but their AE
support has been good.
- Andrew Tufano of Raza Microelectronics
Apache RedHawk-SDL
Apache RedHawk-SDL gets my award as the best new tool/technology at DAC
this year. RedHawk-SDL (static, dynamic, and inductance) is a
comprehensive tool for signal integrity analysis of simultaneously
switching I/O's (SSO), full chip power analysis (issues like sleep to
active mode voltage spikes), analysis and optimization of on-chip bypass
capacitors, and vectorless dynamic (probabilistic) IR-Drop and
electromigration analysis.
Apache's solution for simulating simultaneously switching I/O's is based
on their next generation Spice simulator called NSPICE. This simulator
has the ability to read in either the time or frequency domains
(S-parameters or RLC). This simulator boasts the ability to handle
3-5 M RLC elements, which is literally impossible to do with Hspice,
Hsim, Nanosim, etc. On a design from TI with 512 I/O's, RedHawk-SDL
extracted 2.5M RLC's (including mutual inductance), 48k transistors
(316 I/O buffers), and 965k simulation nodes. The entire process and
simulation took 9.5hrs on a 2G Linux box and confirmed the delay push-out
problem on the fabricated device. As a designer who performed SSO
simulations using Hspice with hand constructed RLC package models on a
simple 8-bit bus, this capability was simply amazing!
Many low power design implementations utilize sleep modes to effectively
gate off large portions of the design (clock gating). Although this
technique can significantly reduce power, it can also generate a huge
supply spike (surge of current) when the inactive circuitry is enabled.
Apache made the claim the existing IR-Drop and EM tools fail to detect
this situation, because they rely on static power analysis for the supply
mesh. The Apache solution is based on dynamic IR-Drop and EM analysis,
which utilizes a vectorless (probabilistic) approach (the secret sauce
of this technique, for obvious reasons, was not disclosed). In addition,
the standard cell library must be re-characterized with another Apache
tool for state dependent leakage in the nano-amp range. With dynamic
vectors, cell leakage information, and the NSPICE simulator, RedHawk-SDL
performs dynamic IR-Drop analysis and determines the impact of local
on-chip capacitors. These de-coupling capacitors are generally
implemented as "filler" cells to facilitate placement, since their
effectiveness drops off significantly with distance from the
noise source.
The next case to consider is the dynamic power glitch (sleep to active
mode) effect on propagation delay. In addition to the vectorless method
above, this analysis requires timing widow information from PrimeTime-SI
and another re-characterization of the cell library for timing.
RedHawk-SDL also provides the capability to dump out a Spice netlist of
the entire clock tree network. Deterministic analysis of the clock tree
on a 4M gate design with 16 embedded memories and RISC IP core, was 3hrs
with a standard Spice simulator v.s. 30 seconds for NSPICE. On this same
chip static IR-Drop/EM analysis took 6 minutes and dynamic analysis with
RLC's and de-coupling capacitor optimization took 2 hours.
- [ An Anon Engineer ]
Well, the pros of Apache's RedHawk-SDL are that you can run dynamic IR
drop analysis without VCD. It takes the output from a PrimeTime run to
stimulate the circuit. This is why we decided to look at it in the
first place. We have never done dynamic analysis and it is becoming
obvious that this is needed moving beyond .15um technology.
The results RedHawk-SDL showed compared nicely to Simplex (which is what
we use now) as far as static IR drop analysis. They only analyzed one
large block of a chip for us. Then when they went into their dynamic
analysis, the results looked much worse, 3x worse. Since the chip
operates very well, we either have enough margin on this chip or the
tool is too pessimistic. But the results were extremely interesting and
they did this analysis is a very short period of time.
The only problem I have is that it is not integrated into our point
tools. Neither is Simplex and it causes problems. I am currently using
Magma and their Blast Rail IR Drop analysis tool is very nice to use
because you can run it anytime the data has changed very easily. Red-
Hawk has the capability to do what-if scenarios but the changes would
still have to be rolled back in your point tool eventually.
So my opinion is this is that I think RedHawk-SDL has a lot of potential
and is a great tool to analyze chips that have been taped-out to better
understand the effect dynamic IR drop has on the type of chips we design
and for developing a set of guidelines for dealing with the issue. It
would be a great tool to use to gain knowledge of what the do's and
dont's of designing power grids for the types of chips we make. I would
need to get more hands on with the tool to comment on its usefulness as
a chip sign-off tool.
- Ed Mahr of Conexant
Overall, I found that RedHawk was pretty easy to install and use. I
particularly like the Linux version. The tool runs quite fast
compared to other solutions. I evaluated their dynamic power analysis
feature which I was particularly interested in. I found that their
approach is sound and realistic. Even though it is still a bit difficult
to get dynamic power analysis running smoothly in a short period of
time, but its capability is real and very useful. While we were
evaluating it, we could not find any other solution that was closely
compared to Apache's. Also, I liked the what-if feature while we used
it to quickly evaluate our ideas to solve potential problems. The EM map
is also helpful. Overall, the user interface is good. The learning curve
for using the tool is quite short. I do wish however the code can be
more stable since it does crash a bit more often than what I would
prefer. On the other hand, since tool runs pretty fast, it is not a
very painful thing to re-run the tool.
- Kewei Yang of Analogix Semiconductor
Apache's RedHawk and Sequence CoolTime are leaders in dynamic power noise
analysis. The main differentiations are the automatic "worst case" test
pattern generation and dynamic power noise impact accessment on circuit
timing. Apache is doing better in the first area, and Sequence better in
the later. Simplex needs to play catch up in dynamic noise analysis,
leveraging its success in static P/G signoff.
- Weikai Sun of Volterra
We have not finished the evaluation of RedHawk-SDL yet. That is, I can
draw no conclusions right now. I can share with you about what I have
seen so far. The most interesting features of RedHawk-SDL for us is the
dynamic power analysis capability (their vectorless feature) and SSN.
As I know, Astro-Rail and VoltageStorm are both on their way to
improving the dynamic power analysis and SSN is still on the roadmap.
- Rudy Cheng of Silicon Integrated Systems Corp.
Apache generated a buzz at DAC, although their technology was proprietary
so in my case it was a suspicious buzz. Their Redhawk tool does
vectorless dynamic power, as well as your normal static power estimation.
The big problem with dynamic power is the vectors. First you have to
figure out the situation under which you'll have maximum power. It's hard
enough to come up with vectors to exercise the longest path (that's why
we use static timing analysis). Most designers don't have enough of a gut
feel for power to realistically be able to come up with the worst case
power scenario(s). The second issue is initialization. Many power
simulators are pretty slow so getting to this worst case scenario can be
problematic. If you can do this without vectors like STA you've saved
yourself a ton of work, although just like STA I assume there will be
problems with unrealistic worst case scenarios. Anyway, their tool takes
LEF, DEF, GSII and a .lib and can work at a floorplan level if desired.
They use a .lib for static power information and generate their own
dynamic library via SPICE. Their tool allows for quick what-if analysis
and gives suggestions for where to insert decoupling caps. They emphasized
a three step process: 1. planning 2. avoidance and 3. verification. They
can do memories and have special flows for low power design (clock
gating, dual threshold, etc.). They've worked with SoC Encounter and
Floorplan Compiler as well as place and route software from Synopsys,
Cadence and Magma. TI has used their tool and they claim a 4 M gate
design takes 6 minutes for static analysis & 2 hrs for dynamic analysis.
- John Weiland of Intrinsix
Apache RedHawk performed very well with respect to extraction of full
chip, including power grid and decoupling caps. Certain types of decaps
may require special recognition, but the tool comprehends all types we
required.
RedHawk's vector dynamic analysis correlated very well with Spice
(within a few %) and was very fast at full chip analysis. A few hours
for a tens of millions of gates design. Quite fast.
Vectorless dynamic mode was very useful, as there were limited vectors
available to emulate worst case activity system-mode operation. The
vectorless dynamic results correlated well with benchtests in terms of
power. An indication that the computed activities were reasonable.
The tool provided an effective UI for ID of hot spots (like many tools)
as well as decap distribution (unlike other tools).
We still have more work to do, but overall the tool looks promising.
The biggest issue is closing the loop with static timing analysis. With
IR drop, you are dealing with time-varying signals. Picking the right
drop to annotate onto PrimeTime-SI instance specific rail voltages is
not easy, and is inadequate. Yet analyzing IR drop on it's own is an
important analysis step.
- [ An Anon Engineer ]
I did not use RedHawk myself. What happened was that in the heat of
working on a five million gate 0.13 um design, Apache's representative
in Singapore offers to carry out an evaluation of RedHawk on this live
project. The product's feature was really attractive and so we agreed
to do so. An engineer from this Singapore Rep traveled to the U.S. and
Apache trained him to carry out the static analysis for us.
Our evaluation was carried out on a preliminary layout with a lot of via
connections from the power mesh to memory power rings still missing. The
interface to the tool was straight forward. We provided the technology
informations, library LEF files and .lib, the chip DEF and soft macro
DEF, clocks and some toggle rate information.
In two days (if I remember correctly), Apache gave the first results
showing us power estimation, EM, and rail voltage drop. After a short
conference call to fine tune things, revised results were given to us
the next day. We were impressed with:
- the speedy setup
- the ability to connect all those missing power connections
- it fed back a power figure about 7% off our estimated value
- it pinpointed some EM issues and weakness of the power plan
- the fast run time (job was completed on a 2.1 GHz Linux machine
in 14 minutes as reported by Apache. I don't think they cheated
us on this.)
We evaluated Astro Rail on another project in the same technology. The
interface requirement is about the same and setup time is about the
same. Judging from the sizes of the projects, we believe RedHawk has
faster run time. However, Astro Rail's "what if" features is no where
near that offered by RedHawk. Both tools are able to provide early
feedback of power plan weakness.
We had given up using Voltage Storm (transistor based). It is simply
too slow and we are not getting meaningful results out of it.
However, there is a price to pay to use RedHawk. It is very costly
compared to Astro Rail. I would say that if you have that budget, and
if you are looking for a tool that can be upgraded to perform dynamic
analysis should you have a need, and if you use this tool frequent
enough (perhaps shared by many projects), go for RedHawk. Otherwise,
then perhaps Astro Rail will serve you well enough."
- Chee-Huang Chow of Infineon
Yes we do use NSPICE. It is much faster than Avanti HSPICE in terms of
runtime. The HSPICE netlist works directly in NSPICE. NSPICE's freq
domain analysis may be better than HSPICE. NSPICE also provides a free
encrypter for semiconductor houses to encrypt models. We have used it
on Linux and Solaris.
Bottom line, we like it.
- Syed Huq of Cisco Systems
Apache NSPICE Pros:
In term of speed, we found NSPICE to be a lot faster than HSPICE or
Spectre without sacrificing accuracy. We ran testcases in all different
areas: SRAM, PLLs, DSP, and the results look very positive. In all
areas, NSPICE has been superior in performance (and perhaps accuracy
when transistors are in the shutoff region). There have been rumors of
an improvement to HSPICE coming out soon but that remains to be seen.
In comparison to HSIM, while Nassda's HSIM can achieve the same speed,
we found the need to tweak the run file to achieve the accuracy that we
want is a hassle and presents a learning curve. Furthermore, Apache,
being a much smaller competitor seems to take on the support tasks a lot
quicker and we received almost immediate support for all of our issues.
Apache NSPICE Cons:
We ran into a lot of problems with compatibility with HSPICE during our
evaluation. While NSPICE claims and aims to be 100% compatible, we
encounter a lot of issues trying to qualify it (including the latest
BSIM4 model support. They did manage to fix it within a week though...)
Furthermore, DC Convergence on NSPICE does not seems to be a lot better
than HSPICE. Capacity is also an issue compared to HSIM. HSIM seems to
be able to handle RC in the post-layout extraction a little better than
NSPICE and runs faster than NSPICE (not too surprising since we expect
HSIM is still using the fast mos engine). We also found that HSIM does
a better job with power simulations more accurately and can handle IR
drop and power consumption on a block level basis.
Summary:
I do think that clearly HSPICE and Spectre are behind in both
performance and speed. For me, it is a tight race between HSIM and
NSPICE. Honestly, I like both of them.
BTW, have you had anyone ask about the free Linux "SPICE"?
- [ An Anon Engineer ]
Apache's NSPICE was pretty catchy.
- [ An Anon Engineer ]
I am impressed by Apache NSPICE's true SPICE accuracy yet much bigger
capacity than Avanti HSPICE. Of course I will believe it when I use it,
but if this is true, I can see serious trouble for HSPICE. Don't know
the story with Star-simXT, which worked well for us. Hopefully the
engine and algorithm responsible for accuracy was integrated into
NanoSim. No other major changes for fast SPICE simulation market.
- Weikai Sun of Volterra
We're really looking for a good mixed mode tool. Synopsys, Mentor and
Cadence now all claim that they have Verilog and fast SPICE solutions.
We're looking.
- Kevin Jones of Rambus
We did compare NSPICE against HSPICE/Spectre based on the simulation
results of our analog IPs, mainly PLLs. What we found out are:
- One of our PLLs did not go through either HSPICE or Spectre
simulation. However, it passed NSPICE simulation.
- NSPICE does run faster than HSPICE in most cases, one case (also
a PLL) runs about 3X faster.
- Another important reason that we decided to buy NSPICE is because
of its attractive pricing.
The weakness, however, is the lack of its integration with Cadence
Analog Artist, which has rich GUI features for post simulation
processing. But I was told Apache had been working on this issue.
- [ An Anon Engineer ]
|
|
