( ESNUG 445 Item 12 ) ------------------------------------------- [05/24/05]
From: [ Mr. Brightside ]
Subject: Magma Mojave Quartz DRC Pummels Calibre in User Benchmark (I)
Hi, John,
My boss says I must remain anonymous.
I thought your readers might be interested in seeing our results of the
Magma Mojave Quartz DRC tool eval. We've been engaged in some fashion
with Mojave for roughly a year, and have had their binaries in-house for
the past several months.
To start, in the beginning we didn't have a pressing need for a Calibre
replacement. Calibre is like PrimeTime or Star-RCXT. It works, it's
stable. Why change? When we heard the Mojave pitch, our first thought
was "makes sense... sounds like it could work".
The Mojave Quartz DRC tool runs using distributed processing while Calibre
is multi-threaded & machine bound. For example, if you have a network
of 5 machines each being 4-CPU Opterons, your Mojave run will run across
all 5 X 4 = 20 CPUs. In contrast, Calibre will run on only the 4 CPUs
of just 1 machine -- that's multi-threaded, machine bound. (Yes, Calibre
has an MTFlex version that does distributed, but when we tried it, MTFlex
couldn't give us good results.)
To be honest, we also were a bit skeptical about the practicality of these
Mojave massive CPU runs, and whether or not foundries would write rules to
take advantage of the Mojave engine properly. But still, it sounded
intriguing. The last week of the schedule our physical design team is
under a ton of pressure to "hurry up", and here's a tool that is promising
a large speedup that should relate directly to tapeout time.
#0 What we've done
Right now, the Mojave code we're testing is DRC-only. We have not run LVS
in-house yet (although it appears like it is coming soon), nor have we
run ERC. We also have not had access to an antenna rules deck. Testing
the DRC engine though should allow us to check the core-polygon engine,
and also test out the Mojave decks.
On the deck side, right now we are using Mojave-supplied decks, pretty
much verbatim. An engineer here has gone through and compared them to
our Calibre decks and foundry rules to make sure we are roughly checking
the same things. Due to their coding styles, there will be some
differences (some tools can do things like doing multiple checks at once,
etc). In addition our in-house rules won't be in the Mojave deck yet.
We went through run logs, and we don't expect the differences between the
decks to be material from a run point and stability test. Our feeling is,
these differences should only account for maybe +/- 10%. Going in, if
10% was all we saw as a difference, it probably wasn't going to merit us
looking much further to the tool. Calibre is stable and we trust it...
that's worth alot.
All of our initial runs are using 130 nm designs.
#1 Fab support
Fab support was considered a show stopper. Being able to leverage our
foundry's resources to bless a base deck is very important. We do have
a great staff internally to support our decks, but its important to
have a good starting point. I'm glad to say, it looks like Mojave realized
this early on, and was spending considerable effort to work with our
foundry. Given the amount of emails I've gotten from their R&D starting
with "Sorry, I was over in Taiwan at xxx", I think its safe to say this is
being addressed adequately. Our contacts at our major fab also confirm
this. We've been told by the Mojave team that their 90 nm deck is already
blessed by one of our fabs.
#2: Deck language
This was one of those surprises. For starters, the deck is in Tcl. While
this might seem minor, its actually pretty awesome. Anyone who has looked
at recent DRC decks can see they are HUGE. Certain checks can take many
lines to code. I know alot of companies resort to using some primitive form
of "functions" other tools might support, or using some sort of preprocessor
to generate their deck. Since Quartz DRC's deck language is procedural, you
can either use their provided Tcl procedures, or write your own. If a more
efficient way to code a check comes up, you change the procedure rather
than in-line code. It's a neat way to think of things, and as a user, makes
the deck very readable. Quartz DRC also provides some pre-defined primitive
calls for common checks. (This is done similar to how Fusion users get
"fix cell", "fix wire", etc, where they are provided as user-visible
commands... so you can modify them as you wish, but if you use the Magma-
provided primitives, you will get any enhancements they include with each
binary.)
A good example of this is an end of line check. They provide a primitive
function min_end_of_line_enclosure, so an end of line enclosure is simply:
min_end_of_line_enclosure $VIA1 $M2 $data(M2_E_1) \
$data(M2_E_2) -rule M2_E_1+2
In addition to procedures like this, rules can also be done using a "for"
loop. For example in many processes, the middle metal layers contain
similar design rules, so you could write one set of checks for these metal
layers, and do a "for" loop over them:
set numMetalLayers 6
for { set x 2; $x < $numMetalLayers; incr $numMetalLayers } {
... rules for Mx
}
One other nice thing about the Tcl deck is report generation. We all have
our preferences for reports and what we like. Report generation in
Quartz DRC is a provided Tcl macro, using database access. (BTW, Fusion
users will see a somewhat common programming style between Fusion and
Quartz DRC.) Meaning, I can very easily alter this command to write out
my own report format... it would also make things like waivers, etc. a very
simple add-on.
One caution, since the Quartz DRC language is a programming language, you
very easily get into the mode of thinking like most Tcl coders do... type
in a command, check the results, etc. Due to their distributed nature of
the deck commands, this isn't exactly how you do things. Even though you
have an interactive mode for their tool, for polygon engine commands you
have to write them, then tell them to run, then analyze the results. It's
understandable why this is done... (Also admitted, I'm still pretty new to
coding in their tool.)
A few things I've noticed missing in Mojave:
Currently, we have not been able to experiment with reading in multiple
databases (useful for mask XOR or possible data creation commands.)
We've been told some form of multi-GDS is in the current release, and will
be shown this feature this in the near future.
Another missing feature is arbitrary data creation commands... something
similar to "POLYGON_FEATURES" in Hercules, or similar to what you can
do with Calibre's C-API... where you can create arbitrary polygons. It
seems like a very natural thing to do in their Tcl language, its just not
been done yet.
There's alot of other things I can think of doing in a Tcl-based physical
verification engine. If Magma follows their "signoff in the loop"
strategy, and eventually merge Quartz DRC into Fusion, there's even more
interesting things you could do. One obvious thought would be a much
better "DRC glassbox" for hierarchical DRC/LVS.
#3 At First, our Stability Benchmarks
Okay, so now we'll get to some of the more concrete stuff. Obviously
stability is an extremely important issue. Its also a bit of a question
mark, since we were one of the first companies to engage... what can one
reasonably expect for stability on a tool which isn't even released yet?
A signoff tool must be stable. Calibre is stable. Its one of the few
EDA tools I know of which doesn't core dump once a week. If Mojave
crashes alot, people worry about if its signoff worthy. Our initial
engagement, we provided them with I believe 2 GDS files to push through,
so that before we got a binary, hopefully things would be somewhat stable.
Our group has alot of IP reuse (at the RTL level), so if we could cover
our base RTL cores, we probably have a good chance of pushing other chips
through pretty easily.
When I got my first binary, I arranged a suite of 17 full chips in 0.13 um
to throw at Quartz DRC. Due to IP reuse, we expected if there is an issue,
you would see it across multiple chips. To catch more corner cases, I also
asked around our company's other business units for a few other chips.
This would allow me to catch GDS from other tools, other design styles, etc.
When I got my first binary, I ran only projects from my group (10 chips),
and 5 passed "out of the block", the other 5 suffered what appeared to
be 2 distinct error signatures, which caused death. (As a side note,
my benchmark includes GDS files written from Fusion, Virtuoso, Apollo,
Astro, and Calibre DRV)
Response from Mojave has been great on stability. They made it very easy
to send test cases and responded back promptly. Within 2-3 binary releases,
they passed my qual suite for stability. After the 2nd binary, I increased
my suite to 17 chips and by the 4th binary, all 17 chips were running
without fatal errors. I also added 19 block-level runs, and they also were
passing.
They also had eliminated some "bad data points" where chips were taking an
excessive amount of runtime or memory. As of my last Mojave binary there
was only one questionable point that stuck out. (One thread took over
2 gigs of memory, which was crashing the job, as the machines I was using
were 3.5 gig dual CPU jobs that ran out of memory.) I have since pruned
down my qual suite significantly, as stability no longer seems to be a
major concern.
Is the tool stable? An easy way to confirm this, is many of our chips have
DRC waivers (due to process changing post-tapeout), and we also have some
internal rules, not listed by our foundry. These things should show up
in the report. So our initial filter of accuracy is "do the error logs
look somewhat as expected". We went through these and didn't see too many
issues to worry us. (We are currently in the process of starting a more
formal correctness check.)
#4 Rev and Version Numbers
After we felt Mojave was at least somewhat stable, we proceeded to more
detailed benchmarking. From here on in the report, Mojave refers to
Quartz DRC 2005.4beta.39. Calibre is Calibre 2004.4_8. The Opterons
are 2.2 Ghz, 64-bit, 4-CPU Opterons running Red Hat Enterprise Linux 3.
The Xeons are 3.0 Ghz, 32-bit, 2-CPU Xeons running Red Hat 7.3.
- [ Mr. Brightside ]
Editor's Note: This benchmark is continued in the next item. - John
---- ---- ---- ---- ---- ---- ----
Related Articles:
Magma Mojave Quartz DRC Pummels Calibre in User Benchmark (I)
Magma Mojave Quartz DRC Pummels Calibre in User Benchmark (II)
Magma Mojave Quartz DRC Pummels Calibre in User Benchmark (III)
Index
Next->Item
|
|
