( SNUG 04 Item 11 ) ---------------------------------------------- [08/11/04]
Subject: Synopsys PhysOpt, Galileo
WHAT IS GALILEO? There I am, putting together this trip report, pawing over
the PhysOpt user responses to the survey and out pops:
"We do not use PhysOpt, but are looking forward to Galileo."
- [ An Anon Engineer ]
Hmmmm... What is "Galileo" ? I called up one of the marketing hacks at
Synopsys and left a voicemail. I went back to work on the report. A day
later, the hack calls back. "Galileo was a 16th century astronomer first
to use a telescope to make major astronomical discoveries." -- what the!?
I balk loudly over the phone. "OK. I can also tell you that Galileo was
a NASA spacecraft that probed the atmosphere of Jupiter in 1995. That is
all I am authorized to say on this question." WHAT?! Huh? What the %#@*
is bloody "Galileo" !!??
Anyway, back to PhysOpt. Concerning Aart's claim that his new rev of
PhysOpt is "50% faster", the customer consensus is that it's really only
20% to 30% faster. Not bad, but it's not 50%.
On the technical side it's interesting to note how users are now linking
scan chain insertion with PhysOpt. ... now, what the heck is "Galileo" ?
6.) Aart bragged that PhysOpt 2003.12 was now 50% faster. Real or hype?
How does PhysOpt do vs. its rivals Cadence, Magma, Sierra Pinnacle,
Zenasis ZenTime? What physical synthesis tools are you using now?
We use DFT Compiler with PhysOpt to generate placement-based scan
chains. Recently I evaluated the Unified Test DRC and timing-based
scan chain ordering. Their Unified Test DRC is useful to fix ATPG
errors within DFT Compiler environment. The timing-based scan
chain increased the wire lengths compared to the placement-based
scan chains which prevented 300 hold violations.
- Harish Dangat of Cypress Semiconductor
I think DFT Compiler is better tool to use, especially if combining
with PhysOpt. Placement-based scan stiching/re-ordering can be
done under the same hood.
- [ An Anon Engineer ]
We use Mentor test tools for the most part. We are pushed into using
Synopsys DFT Compiler when a design is using PhysOpt because of the
integration and, therefore, QoR benefits.
- Andrew Bell of PMC-Sierra, Inc.
I don't have enough time to write all I would like to say about DFT
Compiler. If PhysOpt gets a 1 (out of 5) on my scale of "EDA tool
goodness" then DFT Compiler gets about a -3. Horrible! And we're
only trying to get it to *insert* scan, not even do ATPG or anything
remotely complex!
- [ An Anon Engineer ]
Based on our recent evals we have switched our test tool flow to
DFT Compiler because of its very tight coupling to PhysOpt at the
frontend and to TetraMAX ATPG at the backend. Using DFT Complier
along with PhysOpt has helped us avoid handoff problems between
logic synthesis, scan insertion, and P&R tools.
- Arvind Chopra of Philips Semiconductors
PhysOpt is still our #1 choice for placement and optimization. Magma
and Cadence can not do a better job if your design has a lot of hard
macros and blockages. New 2004.06 version of PhysOpt does improve the
capacity 2X, handling 500 K instances design overnight. For timing
non-critical design, you may use FE or Magma.
- [ An Anon Engineer ]
PhysOpt is a slight bit faster going from 2003.06 to 2003.12. No way
it's 50%; more like 20%. If the comparison is to 2003.03, maybe it's
better; can't comment, haven't used that version in ages.
- Leo Butler of Brocade Communications
I don't know about 50%, 20-30% maybe. We use PhysOpt, but it isn't
a physical synthesis tool. Except in rare cases, gates-to-placed-gates
always results in better QoR than RTL-to-placed-gates. I hear the
PhysOpt RTL-to-placed gates flow is being dropped altogether by SNPS.
- [ An Anon Engineer ]
That 50% faster might be true. We have used PhysOpt, but not for recent
tapeouts. I heard Magma is fast in timing closure in flat design, but
haven't tried it yet. We use Astro exclusively for our recent tapeouts.
- Haiming Jin of Intel
I did a few tests with PhysOpt 2003.12, had quite a few crashes before I
figured out the right combination of flags to avoid them, and found out
that, yes, once it works PhysOpt was basically 2X as fast. I'm
impressed. The combination of 2003.12 and Opteron is really hard to
beat, at the moment, and if it didn't exist we'd be stuck for runtimes
and process space reasons.
- [ An Anon Engineer ]
I am not sure about PhysOpt 2003.12 being 50% faster, but it certainly
is faster. However, the speed ups don't always give the same results
or even have new bugs. If you rely on lastest code for a project you
may be in trouble as it is often the Service Packs -SP* releases that
are more stable. Again hardware improvements are showing our biggest
gains.
- [ An Anon Engineer ]
We definitely use PhysOpt. I haven't noticed that big improvement in
term of runtime. Perhaps was he referring to 50% runtime improvement
figure in DC, that is the first step of a PhysOpt run (that is
compile_physical)?
- Marcello Vena of Xignal Technologies AG
We use PhysOpt. I don't know its performance metrics.
- Andrew Bell of PMC-Sierra, Inc.
We use PhysOpt for placement and Cadence NanoRoute for routing in our
production designs.
- David Fong of S3 Graphics
We use PhysOpt.
- [ An Anon Engineer ]
We managed without any physical synthesis tools so far. DC-Avanti flow.
- Santhosh Pillai of Parama Networks
PhysOpt 50% faster? MAJOR MAJOR hype.
I would not use PhysOpt again voluntarily unless a gun was pointed
to my head -- or unless my job was at stake. PhysOpt is one of the most
memory-hungry tools that I've seen yet. This coupled with its inherent
slowness and poor performance on timing-driven placement just puts it in
my "trash can" folder as far as EDA tools go. The only thing it has
going for it is Tcl (versus the horrid Scheme we all love and fear when
dealing with Astro) and good static timing correlation to PrimeTime. As
a placement optimization tool, I'll skip PhysOpt next time if I can,
that's for sure! Can't wait to try something else like FE coupled with
the Get2chips engine.
- [ An Anon Engineer ]
PhysOpt definitely faster. Maybe not 50% faster, but significantly
faster. PKS does relatively poorly for us, especially in context within
Encounter. No Magma nor Sierra Pinnacle data. One small group using
Zenasis products on specialized cases. They're quite happy and moved
away from PhysOpt.
- [ An Anon Engineer ]
50% faster than what? (Sorry, I missed the speech.) We were even
further down-rev on PhysOpt, at 2002.05-SP2. I'm looking at 2003.12
right now, but focusing more on results rather than speed. But with
regard to speed, the "run_router" command seems to complete faster.
I'm more pleased that Synopsys managed to improve the correlation
between estimated and routed parasitics with the 2.5-D libraries.
We fell back on using the 1-D libraries, with scaling factors, because
we could get a tighter spread that way. With 2003.12-SP1, the spread
is slightly tighter with 2.5-D.
- [ An Anon Engineer ]
Now using PhysOpt.
- [ An Anon Engineer ]
We use PhysOpt just because it is cheaper for us. The alternative is
Magma. Cadence costs too much.
- Massimo Scipioni of STmicroelectronics
Don't use PhysOpt, although we are thinking about trying it out since
several people I've spoken to seem to think that the placer and
optimization in PhysOpt is superior to the one in Astro.
- [ An Anon Engineer ]
Don't know about a comparison of physical synthesis tools. Currently
using Magma.
- [ An Anon Engineer ]
We use PhysOpt, but again 2003.6 due to the bug issues in 2003.12.
- [ An Anon Engineer ]
Again, we're using SoC Encounter's phyopt features. I've used PKS's but
found that they are essentially garbage. The tie-in between PKS and
Encounter is also horrible.
- Gord Allan of Carleton University (Canada)
|
|
