( SNUG 03 Item 18 ) ---------------------------------------------- [05/14/03]
Subject: Avanti Apollo vs. Astro, Magma, Sequence Physical Studio
SIMBA, THE LION KING: Judging from the user comments, Astro appears to be
going through the classic growing pains for a leading EDA tool. First off,
Astro users are bitching up a storm about all the bugs they're running into,
especially if it has to do with Astro's CTS abilities. Yet these very same
users stick with Astro because they're getting 3x to 6x better performance.
(In my survey of best/worst Synopsys tools, there were 7 users that listed
Astro as *simultaneously* the best *and* the worst Synopsys product this
year.) It's the typical I-hate-the-bugs-but-love-the-results user reactions
to a green code EDA tool that they want ungreen. "Ah... the EDA tool cycle
of life renews itself once again... I am your father, Simba..."
Dataquest FY 2001 ASIC P&R Market (in $ Millions)
Synopsys/Avanti ############ $93.9 (36%)
Cadence ##################### $167.0 (64%)
"Astro is much better than Apollo. Of course, the first releases were
buggy as usual. The strengths of Astro are clock tree synthesis and
post-route optimisation. Compared to the Cadence Warp route, Astro is
4 times faster. There is no post-route optimisation integrated in
the Cadence flow: you need to go out of the P&R database into PKS."
- Philippe Duquennois of Philips
"We're so past using Apollo that nobody here would to waste the time to
compare any more. We get considerably more agressive optimizations in
Astro than were ever possible in Apollo. We expect our Astro run
times to be a tad bit longer because of that. But nowhere have we
experienced performance hits big enough that have sent anyone running
back to Apollo -- particularly after they see the results you can make
in Astro. We tend to tune our block sizes to around ~24 hour PrimeTime
runs, which usually winds up as sub-24 hour runs of our blocks in
Astro. It all fits together well. One recent flipchip design had over
11 M gates, 400 kb memory and several hundred clocks. Another flipchip
had over 10 M gates, 27 Mb memory at 266 Mhz, mixed voltage. These are
just snapshots. Astro has been in production use here over a year now,
and is our primary P&R tool.
For our Astro GUI users, the migration has been easy. The UI is
essentially the same, and what is new or changed is fairly self-evident
in the UI itself.
For our Scheme scripters, I wouldn't say the change-over to Astro was
trivial, but early on, our internal support organization here at Agere
gave us a full set of templates for common operations that many users
just took as new starting points.
Bottom line, while Astro is far from perfect, it's still a damned sight
better than Apollo (or anything else we've looked at.)"
- Clay Schneider of Agere Systems
"I have seen performance of 3x to 6x between Apollo global route and
Astro global route on designs with 1 M and 2.5 M instances. The switch
to Astro is pretty straightforward. But at this time the global route
GRC do not quite correlate with detailed route. Apollo's prediction
correlate better with detailed route."
- Benjamin Mbouombouo of LSI Logic
"I inherited the responsibility for introducing a COT flow into our
company. I also inherited Apollo/Saturn tools as our P&R tools. We
had all sorts of problems getting the Apollo flow running smoothly.
Mainly due to our inexperience coupled with extremely poor Avanti
documentation, technical support and quality control. After much
effort we managed to tapeout our first Apollo design in 3.5 months
and have subsequently developed methodology to turn the designs
around in about a month.
Our designs are around a million gates. As a result of our less than
ideal experience with Apollo, we were dying to get our hands on Astro
since their technical support kept saying, "well Astro can do that",
when we had problems with Apollo.
Evaluated Astro and found a nice performance increase in placement on
Solaris and additional increase in performance on Linux pretty much
as advertised.
We ran Apollo on a SunFire 280 with 2 x 750 Mhz processors, 4 Gb mem,
Solaris 2.8. (We were not using multi-threading.)
We ran Astro on Linux RedHat 7.2 with the big mem patch. It has 4 Gigs
of memory, and the processor speed was ~1.1 GHz.
The design was ~200 k instances.
Astro version 2001.2.3.5.0.3
Apollo II version 2000.2.3.4.0.9
My run time numbers are rounded to the nearest 5 min or so.
Apollo/Saturn Astro Linux Speed Up
------------- ----------- --------
Read Netlist 12 min 4 min 3x
Load SDC 25 1 25x
Quick place, HFN,
Transition Fix 155 30 5x
IPO 360 90 4x
CTS/CTO 60 30 2x
-----------------------------------------------------------
Total 612 155 4x
Much of the speed increase resulted from the fact Astro runs in
memory rather than on disk. In our flow we tend to drop in and out of
the tool after each seperate action and we still saw benefits of
running in memory. For instance, you no longer have to re-run the
Astro timing engine just to generate a timing report. Going forward
we could merge more commands. We saw further speed ups since you
can change your timing constraints on the command line in seconds.
With Apollo it was taking us anywhere between 30 minutes and hour to
load a new SDC file due to the hierachial ports command. Another
useful Astro feature added was the quick place command allowing very
quick evaluation of the floorplan.
Astro IPO fixes repeater insertion much better than Apollo/Saturn. In
Apollo we were seeing up to 8 buffers being used to fix transitions
to/from pads even with soft blockages (allow repeater placement only)
all around the core and between large memories. Astro did it with
a max of 3 buffers in a chain.
In Astro you can generate a netlist cleanly in a few seconds. This
is now possible since their IPO engine no longer walks across the
hierachy. (You do have to fix the hierachy to do this though, which
means that you cannot use delete clocks function any more.) In
Apollo it was taking us up to 30 minutes to generate a netlist with
varying quality.
We were able to port our methodology in the form of Scheme scripts
and makefiles over from Apollo to Astro in 1 to 2 days. Their
documentation is still not great. Synopsys is trying and released a
primer outlining a flow. Their flow was conceptually similar to the
flow we had developed for Apollo (after much heart ache).
All went well until we started Astro clock tree synthesis (CTS). At
this point we discovered a number of bugs. We eventually managed to
create a clock tree smaller than Apollo with similar skew, but it took
a long while to find the magic sequence of buttons. The skew reporting
in Astro is not good as Apollo's either.
CTS was not ready. This does raise the quality control questions we
always had with Avanti. To be fair Synopsys support has been great.
A far cry from the Avanti days where we were paying for the Avanti
AE's to come and witness the bugs and walk away and do very little
about them."
- Craig Farnsworth of Cogency Semiconductors
"We use PhysOpt/Apollo/Astro for our P&R implementation. The biggest
set of problems affecting our adoption of Astro is centered around
the hierarchical Verilog netlist generation command. We would
encounter layout (parasitics file) vs. Verilog netlist mismatches
during post-layout timing analysis. This forced us to use an Apollo
netlist generation strategy within Astro in order to bypass these
issues. Astro also had some runtime issues in completing CTS on large
designs. A design was taped out with 3 different versions of Astro;
one being a "trusted" baseline release, another version to combat long
CTS runtimes, and another to generate timing views of completed P&R
blocks to drive top-level P&R.
Our overall transition to Astro has been OK, and for the projects that
used Astro, the feedback is that Astro performed a much better job
than Apollo/Saturn. Many algorithms were introduced or improved in
Astro that make the tool run much faster and perform much better
than Apollo.
In one design, Apollo spent about 48 hours on a well endowed machine
to perform metal density fill, whereas Astro, on the same design and
same machine, completed the job in 10 hours. The Linux version of
Astro can complete the task in 1/5th the time."
- [ An Anon Engineer ]
"Our Apollo to Astro transition was full of gotchas.
Serious problems with dual-port RAM's. The Artisan DPRAM compilers
generate memories that have two separate clocks (one for each port) and
places a constraint between the two clocks to guarantee you will not
try to write to one port and read the same location from the other port
within X amount of time. They do this by placing a hold time
constraint on each clock with respect to the other clock. This forces
the timer to look at each clock port as both a data port and a clock
port. While Apollo had no trouble with this concept, Astro choked.
Patch issued.
The timer is VERY flakey. Astro got confused when it saw the clock
signal going through an inverter to create clkn (the timer would stop
propagating the clock once it get to the inverter.)
Patch issued.
We also saw instances on the clock tree reporting propagation times
with 10-20 digits, NaN's, etc.
Patch issued.
Clock skew reports give outrageously large (~10 nsec) skew numbers.
You run the timer again, then another skew report, and the problem
goes away. Synopsys has observed this behavior on other designs.
Patch pending.
Makes me wonder:
1) Are we the first ones to use Artisan's dual port RAM's (or
any other RAM that forces these constraints)?
2) Are we the first ones to see problems with the clock tree?
Our clock distribution is as simple as it gets: no gated clocks,
just one inverter that goes to one instance.
3) Has anyone else taped out with Astro?
You ask: Is Astro better or worse than Apollo?
Astro gives better QoR and it is definitely faster (2x) executing."
- Roberto Landrau of Mitre
"Astro does 0.18 well. Very much a step up from Apollo. Hassles at
0.11. Cadence and Magma, too. Who gets to 0.11 first will own the
backend for the next 18 months."
- [ An Anon Engineer ]
"Our vendor uses a DC-to-netlist and Astro (re-buffer only) flow. Astro
seems to do a reasonable job although to date has been very Beta-like.
Hopefully we've found the kinks and our next layout will go smoother.
We still have to margin the synthesis to death since we rely on (yuk)
wire-load models, but Astro does clean up the buffering quite well."
- Lance Flake of Maxtor
"We use Synopsys DC and Astro. Might move to PhysOpt on our next
design. We here have not really looked at the others, the layout
group has but I don't know the results except that they are using
Astro."
- Bob Lawrence of Agere Systems
"Apollo -> Astro is quite easy but still a little painful because
the release SW quality is as worse. Astro routing is a lot faster
than Apollo, plus Astro runs at Linux. But be aware that exchanging
between Apollo and Astro database is not as smooth as they said.
There're some minor while critical bugs in the interface."
- [ An Anon Engineer ]
"The transition from Apollo to Astro seem to be painfree for us. A
little suprise in the way they treat the high fanout net synthesis as
clock net which Apollo works better. It is hard to compare apple to
apple among Astro/PhysOpt and Magma/Monterey but Magma seems to be able
to handle some hard to finish blocks better than Astro/Apollo to meet
both timing and routability."
- John Zhang of Broadcom
"Session 3 - Physical Design Methodologies
1:45 - 2:30 - PhysOpt vs. Astro: How far can we push
Comparison on placement between PhysOpt and Astro. Compares placement
area and timing closure.
Unfortunately, it became clear that their comparison was Apples to
Oranges because they did very different things when running both
tools, and they did not compare final timing (so are results were
useless).
Q. Did you use area recovery in any of the runs?
A. No
Q. Did you compare routed timing?
A. No"
- Santiago Fernandez-Gomez of Pixim, Inc.
"Astro is very smooth, took me 1 day to finish. In the terms of timing,
it's the best, but its turn around time is much longer than Cadence.
We adopt SoC Encounter instead of Astro/PhysOpt."
- Tie Li of Applause Technolgy
"Have not done Apollo to Avanti switch. We are currently using Apollo
and Sequence's Physical Studio. Yes, Synopsys has been pushing us for
upgrades. But it costs arm and a leg. Our current DC/Apollo flow
works great. We really don't see any compelling reason for paying
them more money for Astro."
- [ An Anon Engineer ]
"OK. I expected more. We use Astro. In comparison to Jupiter-XT,
Sequence's Physical Studio is pretty good for large designs, at least
their data says so. Celestry is more comprehensive."
- [ An Anon Engineer ]
"Magma's toolset is much better integrated, whereas Synopsys has a ways
to go before they can claim seamless integration. We've had tons of
problems getting a Synopsys binary format (.db) out of PhysOpt into
Floorplan Compiler, for instance."
- Neel Das of Corrent Corp.
"I've not worked on a project that is willing to transition to Astro
yet, and thus have little to no valuable information to give here.
Do I think the transition has gone smooth? NO. Simply said, they are
asking for more $ for Astro. In the current economy, if you are
getting it done with Apollo, why pay more? There's no injunction here
to force a migration like from Aquarius or ArcCell.
Is Astro better? Without having used it, I would guarentee it's
better. It's a silly question to ask, as I see it. You might as well
ask, "Have loads of Avanti R&D spent the recent years doing nothing?".
I haven't used Cadence/Magma/Monterey's equivalent toolsets."
- [ An Anon Engineer ]
"Using Cadence Silicon Ensemble and moving towards Avanti Astro. But
prefer Magma environment with one single timing engine!! SE is easy to
use but a pain to do manual routing! SoC Encounter same problems. In
Astro it's almost impossible to do manual routing. Remember we're doing
mixed-signal designs. For simple digital chips both routers work. A
good router should handle manual routing of sensitive nets, pin movement
and re-shaping of blocks the easy way not using work-arounds. Let's
express it this way: SE with Virtuoso-XL capabilities would be a killer,
or so would Astro with Cosmos capabilities."
- Bengt-Erik Embretsen of Zarlink Semiconductor
"I don't know how Astro behaves because some gods in our company decided
to dump Avanti and go for the Cadence backend flow. OK. Cadence First
Encounter is a NIGHTMARE."
- [ An Anon Engineer ]
"PKS was dead on arrival the day Cadence bought it. Too many bugs.
Astro is the same shit, different day."
- [ An Anon Engineer ]
"The Apollo-to-Astro transition was smooth for us, largely because Astro
itself is not very buggy. The main change with Astro is that it has
many more hammers with which to hit the problem of timing closure.
Astro stipulates that for every command in the process (placement,
clock tree synthesis, routing, crosstalk fixing) it will not perform
optimally, so it provides "Post-" stage timing clean-up commands (Post
Placement Optimization 1, PostCTS Optimization, Post-Global Route
Optimization, etc).
At first you wonder why they don't just put these into the original
command, but as you start working on specific blocks, you find out that
you have to specially configure the commands on a block by block basis
in order to close timing. The setup- and hold- fixing options tend to
fight with one another -- set one too strong and you break timing. Set
the options too weak and you don't make timing.... There is one
command (pdsCROptimization) that tells Astro to work on every path that
has negative slack. This is helpful for blocks where there are a few
paths that Astro will never be able to fix timing on for pathological
reasons. In the past, Apollo/Astro would not work on all the paths
that were negative but not as bad as the worst path. This just short-
hands the process of fixing timing by hand at the end of the day. We
ended up with several mini-flows on a chip.
There is no "one-size-fits-all" Astro set-up, but the overall approach
by Astro is pragmatic enough that you can finish a chip with only a
minimum amount of intervention as compared with the Apollo days.
We also found that for the lower technologies (0.13 and below) Astro's
congestion maps are not always very accurate. For blocks that have
lots of flops, Astro's placement map and global routing map can be
radically different. But it gets worse: Astro's global route map can
be absolutely clean and you can still get thousands of route violations
in hot-spots that were never previously predicted in either map. This
seems to be due to clock nets that have special widths and spacing
associated with them. For blocks that have large amounts of feedthrus,
again the Astro congestion maps are not very helpful at the routing
stages -- antenna cleanup can be ruined by 'river-routing' that occurs
when a large bus goes across the block. The extra vias needed to fix
the antennas cause hotspots to appear in a previously clean block.
Similar problems occur with crosstalk fixing."
- Margaret Valliant of ReShape, Inc.
"The Astro product is better than Apollo from both a capacity and timing
closure point of view. As for gotchas, he pain threshold required for
operators of the Astro environment is high. (It's the only tool flow
that requires a more experienced operator to use properly is the
Cadence solution.) Astro users are already 'numb' to operator pain, so
it does not seem too bad, but to early learners it is pretty severe.
The Astro/PhysOpt combo is a bit better than it was pre-merger. It
seems like a lot of work to get the design through. The Magma solution
is not quite as tight and does not necessarily give you more margin;
but it does meet timing and die size with a lot less grief than the
Astro flow. A Magma user can also be an engineer with less tapeout
experience, and still provide a qualified design.
I have just started playing with the high end MTCL API interface to
Magma which should allow the power users to push the technology and
play on the bleeding edge where Astro lives. It seems to work well,
especially when you start from the baseline solution that the tool
provides in standard mode vs starting from ground zero like Astro."
- Pallab Chatterjee of SiliconMap
"I mostly do physical design using Cadence's Silicon Ensemble. We are
now moving to use First Encounter."
- Mark Gaffen of Motorola
"We are starting an evaluation of Astro/Jupiter/Hercules/NanoSim/Cosmos
this week. So far, we have no experience with this backend tools from
Synopsys. Was always a Cadence user before."
- Santiago Fernandez-Gomez of Pixim, Inc.
"We only have a very small design, albeit one with a very whacky aspect
ratio. Astro running on Linux was a dream. Apart from performance,
the Astro clock skew management and timing & buffering improvements
were very impressive. We did not purchase it yet (due to economic
conditions.) Migration was a snap and the AE support was excellent."
- Shiv Sikand of Matrix Semiconductor
|
|
