( ESNUG 455 Item 1 ) -------------------------------------------- [06/29/06]
Subject: Apache RedHawk vs. Simplex VoltageStorm vs. Sequence CoolTime
THE NUMBERS SAY ALL -- I knew when I asked about Apache, I'd be flooded
with letters from users barking about RedHawk, the main Apache product.
But what caught my eye was a *detailed* user benchmark comparing RedHawk
vs. Cadence VoltageStorm-DG vs. Sequence CoolTime vs. Magma BlastRail vs.
Synopsys PrimeRail. Pay dirt! I'm OK with user opinion pieces where they
rank one tool vs. another, but as an engineer I'd *prefer* actual hard
data, runtimes, error rates, violation counts, mem useage, CPU time, etc.
and the detailed methodology used to get these numbers! Pay dirt!
"In your opinion, how does RedHawk stack up against VoltageStorm,
PrimeRail, CoolTime, and BlastRail? Better/equal/worst? Have you
benchmarked RedHawk? How did it fare in the benchmark?"
After our mid-2005 benchmark involving all 5 of your above-mentioned
tools, and using multiple 130 nm (chosen for their maturity) testcases,
we ultimately chose RedHawk as our signoff tool-of-choice.
Although we initially stipulated that only beta-or-full-production code
could be used for the eval, it became evident that all the tools needed
some level of hotfixes for this benchmark, and so, code mods were
allowed -- but the quantity/severity of hotfixes would be a measure of
the product's robustness.
1) IR (static) -- For IR analysis on a full-chip testcase, we wrongly
assumed this would be a routine effort for all vendors. We treated
this as a baseline check against our pre-existing production
Cadence VSPE flow.
Although all 5 vendors ultimately presented quantitative results
which we deemed acceptable, only RedHawk and Cadence VSPE arrived
at their results quickly and decisively.
CoolTime, BlastRail and PrimeRail all required 3+ iterations due to
either setup adjustments, re-modeling, or tool hotfixes.
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.
3) DVD (Dynamic Voltage Drop) accuracy -- We exercised the tools on as
big a block as possible for which we could create HSIM results in
high accuracy mode using a StarRCXT extraction of both signals and
power-grid. RedHawk came out-of-the-chute with good DVD accuracy.
The next 2 runner-up tools required patches (multiple patches for
Cadence VoltageStorm-DG) before becoming competitive:
Case1:RMS-error (mV) Case2:RMS-error (mV)
CoolTime 0.382 0.401
RedHawk 0.446 0.418
VoltageStorm-DG 0.473 n/a
Ultimately both Apache's RedHawk and Sequence's CoolTime showed
acceptable accuracy results. Although CoolTime had better numbers,
our nod went to RedHawk for its robustness out-of-the-box.
4) DVD Capacity -- measuring runtime and memory/disk usage for a full
chip testcase (applicable job steps normalized for #-of-timesteps
for an apples-to-apples comparison) was a crushing win for Apache.
Once again, RedHawk's results were essentially out-of-the-box, while
the two runners-up required hotfixes to achieve the following marks:
cpuTime wallTime Memory Disk
RedHawk 8:48 10:36 14.6 GB 34.5 GB
CoolTime 16:10 24:19 21.1 GB 132.0 GB
VoltageStorm-DG 66:45 94:57 69.6 GB 148.0 GB
The time units of hrs:min. The jobs were all run on a 32 GB Opteron
w/4GB swap (largest server we had available to us in-house), with
RedHawk setup for smart caching because it has that extra feature.
CoolTime made significant performance strides during the eval, but
didn't unseat RedHawk. For VoltageStorm-DG, even the non-normalized
mem numbers show that this tool was IO-constrained and exhibited
significant swapping for this testcase. If swap space was increased,
Cadence showed it could handle the full job (without the need for
normalization) but still could not generate competitive benchmarks.
5) Static Capacity -- For a single-pass IR+EM job, runtime and memory
usage on a 16 GB Opteron for a full-chip testcase (hierarchic design
run as flat):
cpuTime wallTime Memory
VoltageStorm-DG n/a 1:20 3.2 GB
RedHawk 2:22 3:12 14.5 GB
CoolTime n/a 3:38 14.5 GB
This showed that Cadence's engine could still meet the challenge.
Although RedHawk won or was competitive in all the categories of our
eval, the most notable subjective category was "ease of use". RedHawk
was the quickest and easiest to setup, not only for full-chip analysis
of a hierarchic design, but also for library cell characterization
(NSPICE) and memory modeling.
- [ An Anon Engineer ]
So far, we have not quite been able to match our BlastRail and RedHawk
results, at least in static IR drop analysis. Maps differ, values
differ, but also environment differ, measuring conditions differ, ...
- [ An Anon Engineer ]
We have been using RedHawk-SDL for about one year. There were about
13 designs we ran through it.
Design: 1.2 M instances, @ 33MHz ~ 533MHz
Capacity: 7.9 G memory usage in a 64-bit Linux machine to do
static and dynamic IR analysis
Speed: 39 mins (static analysis)
6 Hrs 5 mins (dynamic analysis)
Advantage:
- static and dynamic IR drop analysis in one environment.
- accuracy to feedback timing effect in MSDF (Modify SDF) file.
- extract RLC to analysis dynamic IR.
- true SPICE engine to simulate IR
Drawback :
- need to be improved the user friendly of GUI and text-mode.
- data input needs other tool's output, such as SPEF (Star-RCXT),
timing windows file (PrimeTime or Incenita), memory use is huge.
When we do RedHawk-SDL after the P&R done, it is too late to do analysis
IR. RedHawk-SDL need the updated input data to analysis IR based on
newest P&R, so the data preparation need to re-process again, such as
SPEF and timing windows file. Sometimes, we got some issues of IR,
there are no people and time to deal it.
Therefore, we need to do RedHawk in the early stage of P&R to get a
rough result. This result can feedback to P&R. If so, we don't get any
surprise in the tapeout stage.
- Alan Liaw of Via Technologies
Sequence has SI tools as well -- and we have many many more tapeouts
than Apache does for SI. We have both SI analysis and optimization.
Some of the biggest chips in the valley use the Sequence CoolTime-SI
solution. Nvidia is doing chips with 800 Million, yes nearly a
BILLION transistors, and is using our solution because of our
capacity and accuracy.
Where do we go to whine our way onto your lists?? :-)
- Margaret Valliant of Sequence Design
I've not used Apache but have talked to them about their product and am
familiar with their capability. At their inception they were the only
provider of dynamic power analysis, however, this is no longer true.
Therefore, my main question is, 'why use them?'. Magma and Synopsys
provide similar capabilities so why exit your implementation flow for
an analysis tool and deal with even more correlation issues?
- [ An Anon Engineer ]
In comparison to VoltageStorm, RedHawk is much easier to use and user
friendly. As well dynamic vectorless is Apache's bread and butter and
it seems that Vstorm is still trying to catch up. Have no experience
with the others. I like the vectorless since I have done some testing
wrt to VCD runs and RedHawk was able to catch the worst case voltage
drops.
- [ An Anon Engineer ]
We have been RedHawk user since 2nd half of 2004. RedHawk static and
dynamic IR tool is now in our production sign-off flow. Synopsys
PrimeRail and Cadence VoltageStorm DG are still struggling to catch up.
- [ An Anon Engineer ]
We used VoltageStorm before and Apache is definitely ahead in the game.
Their database structure is small and run times are fast. On dynamic
IR analysis, Apache fared pretty well against VoltageStorm-DG. We spent
several weeks with VStorm-DG (no results) and then moved to RedHawk.
- [ An Anon Engineer ]
I can only compare RedHawk with AstroRail and VoltageStorm (old
versions) and I see 3 major advantages:
1) you can build a db very quiclky. On a 70 M transistors chip in
90 nm we were able to run a first analysis in 2 days (whereas it
took weeks with the other tools). RedHawk does not complain
about def version or syntax problem in your input files.
2) "what if" analysis is quite powerfull.
3) you can perform dynamic analysis using TA scenarios or VCD files
- [ An Anon Engineer ]
We just recently complete a benchmark of RedHawk versus all 4 other
competitors. RedHawk won hands down. Better runtime, capacity, QOR,
ease of use, stability, etc.
- [ An Anon Engineer ]
RedHawk is much ahead of Cadence VoltageStorm-DG and Synopsys PrimeRail.
We ran benchmarks on 1+ million logic and also custom designs. RedHawk
is much better in accuracy and features. It analyzes both power and
ground rails together which is important for dynamic analysis. Both
VoltageStorm and Primerail do one network at a time (carry over of
static code). Ease-of-use is also a major plus factor for RedHawk.
We have been able to correlate RedHawk results within 10% of Silicon.
VoltageStorm was 30% to 40% pessimistic and PrimeRail was 50% to 60%
more pessimistic. RedHawk also found several valid issues in the
design - like inefficient clock buffers placement, grid not optimal,
higher static drop than planned.
CoolTime from Sequence seems to be close competitor though I saw only
demos of CoolTime.
- [ An Anon Engineer ]
I can only compare to AstroRail (which we used). The best comment will
be that we stopped using AstroRail to use RedHawk. The reasons were:
- modelisation of switches
- low-power solution
- results easy to exploit
- time to refresh data in environment
We checked internally RedHawk accuracy vs large SPICE simulators and
the results were within 10% on a large block.
- [ An Anon Engineer ]
RedHawk comes first, then VoltageStorm. CoolTime comes last. We run
dvd analysis on an identical database. Results are similar. Same hot
spots shows up. But we could run RedHawk by ourselves. CoolTime
needed to be run by CoolTime people. Never used PrimRail/BlastRail.
- [ An Anon Engineer ]
We just starting to evaluate Apache. I did survey all tools, including
Cadence VoltageStorm-DG, Sequence, Synopsys, Magma, Sigrity, etc. I
also brought Apache and few of the vendors for presentations (including
Cadence). I think RedHawk is by far the most mature and comprehensive.
- [ An Anon Engineer ]
We use RedHawk for dynamic power analysis. RedHawk's big advantage for
memory modeling is that it allows several methodologies. These include
a cell-based characterization that understands the design down to m1 or
m2. RedHawk can provide results for full memory characterization. I
believe it can also read in SPICE characterization of a memory if you
have performed it in a tool such as HSPICE.
RedHawk can also use .lib or even PDF type documentation about the macro
to come up with a basic current triangle vs. only offering a full SPICE-
like characterization of the memory. This gives us more flexibility for
"middle of the road" accuracy.
One MAJOR benefit of RedHawk is that the tool is essentially shipped
with a flow built-in rather than requiring a database in a particular
format. This means that if you are creating a database with Magma,
you don't have write a huge flow to read in .lib files, DEF files, etc.
RedHawk allows you to bring in data with a single control file. For a
large company like TI that has their own custom flow for their entire
design process (Pyramid), this may not matter, but for smaller design
houses like us who don't have the resources to create involved flows
for all the tools, this is a big plus for RedHawk.
Library Issues:
One potential disadvantage for RedHawk would be if the library vendors
ever make a decision to actually start providing either ECSM or CCSM
data. Currently, we have yet to receive a library with either of these
but are told repeatedly that it is "around the corner." Until then,
users must build their detailed current models: CCSM for Synopsys,
ECSM for Cadence, and APL for RedHawk. If there is ever unification
behind CCSM or ECSM, Apache will have to follow along or lose business.
Also, if HPUX is the user's platform of choice, they may be out of luck
with Apache as they do not support it.
- [ An Anon Engineer ]
RedHawk is better in terms of time-to-result & what-if scenario.
Dynamic analysis, using Timing Aware mode is very useful, and you
realise what your are missing by performing only static analysis:
the maximum drop can be where you didn't expect it at all.
Very friendly in terms of compatibility with all the formats needed
(LEF, DEF, GDS, .lib), which make a big difference with other tools
I used to run in the past (VoltageStorm , AstroRail) for which you
had to fight to get the correct version of each format.
Very easy also to start the analysis even on incomplete database: you
will get a first result, less accurate, but you can then see and locate
what is missing in your design (it is also reported in log files, of
course), and which hard macros must be modelised, using gdsmem or
gds2def tools if you don't have LEF/DEF/lib data.
- [ An Anon Engineer ]
We find that dynamic analysis is necessary for pointing out real design
issues. For example, RedHawk helped us identify a couple of big drivers
that didn't have enough vias.
- [ An Anon Engineer ]
We currently use RedHawk in our design to do IR drop analysis and
plan to use the other strengths of the tool in the coming months.
- Nani Subramanian of Palo Alto Semiconductors
Apache is the only tool we know that can take in our designs and do
flat full-chip dynamic IR-drop analysis now. Others always have to
do it hierarchically with more complex flow and less accuracy.
Our group's need for Apache was for a DDR interface that had too much
power supply noise. CeltIC coupling analysis indicated that the noise
was not due to coupling to adjacent wires so noise and jitter had to
be coming through power supply connections.
RedHawk identified areas where the power grid was weak to some cells.
We had low cell utilization and had instantiated filler cap cells
wherever possible. The only changes that we could make were to move
some cells away from other high power cells or to beef up the power
grid. Mostly we did the latter.
Runtimes and capacity were very important because we needed to run
dynamic IR drop on all of our nets at the top level of the tool to
account for the current draw of the DDR macros.
- [ An Anon Engineer ]
Very nice interface and reports compared to VoltageStorm.
- [ An Anon Engineer ]
Static analysis results are comparable to VoltageStorm.
- [ An Anon Engineer ]
Index
Next->Item
|
|
