( ESNUG 346 Item 1 ) --------------------------------------------- [3/16/00]
Subject: ( ESNUG 345 #1 ) Magma Sorta Worked; PhysOpt Not; But Who Cares?
> I'm just now getting a peek at wiring congestion within the IBM tools.
> Although I did not run a separate PhysOpt run to specifically address
> congestion, nothing I see today looks unreasonable or any worse than
> our previously released ASICs. The 5% timing goal achievement is close
> enough from my standpoint. The assumptions made during RC extraction are
> gross, and the assumptions made about global wiring obstructions are
> incomplete. The IBM tools are fully capable of taking the PhysOpt output
> and completing the P&R task.
>
> I can say from experience that I'm now at least one month, maybe two,
> ahead of where I would have been without PhysOpt and it only cost me a
> week's worth of work. This result has definitely generated a stir around
> here at Cray/SGI.
>
> - Roger Bethard, Design Engineer
> Cray/SGI Chippewa Falls, WI
From: [ Tony, the Tiger ]
Hi, John,
If you decide to publish this, please do not publish my name, my username,
or my company name. We're in hip-deep with 3 of the 4 companies mentioned,
and I'll be in a world of hurt if they saw me saying this. Thank you.
I've worked in layout automation and chip design for over 10 years. Of all
the engineers I know working _physical_ design on ASICs and processors, most
won't even look at PhysOpt because they don't want to correlate a placement
engine that doesn't have its own router (making me wonder how PhysOpt even
qualified in the GDS II category since it can't get to polygons under its
own steam). It seems to me that lack of a router in PhysOpt leaves alot of
heavy lifting to the Avanti/Cadence/IBM back-end flows (try notch-filling,
antenna checking, and cross capacitance, for instance!)
I'm not talking out of my ass here, John. We looked at PhysOpt. We
couldn't even get PhysOpt to run -- but that may be more symptomatic of
where we are on the Synopsys support/sales pecking order than the actual
quality of the tool.
Who is trying PhysOpt? Most (not all) of the people I've found tempted by
PhysOpt are logic designers who have been brainwashed by the Synopsys sales
machine into believing that they can close aggressive layout timing from
within the physically antiseptic confines of Design Compiler.
These are the same Synopsys people who told us tightening our wireload
models would give us good timing correlation. Now they've figured we need
to see some layout, but not all of it. For crying out loud, look at real
timing! Tune your wireload models, back-annotate your loading, check
your Static Timing Analysis reports, but for God's sake, GO LOOK AT THE
LAYOUT. Its not evil. It's just design data.
The people I've seen eager to get on next generation physical design tools
are those stuck with a non-timing-driven placement tool in 0.35 or 0.25um.
Talk about taking a knife to a gun fight! No wonder these people cry for
a better solution. I don't doubt that PhysOpt could beat the pants off of
a congestion-based placers like the old LSI PD or old Cell3. We went
through 40-60 trips through LSI Logic's CMDE no-clue-about-timing placer to
close our aggressive 0.35um ASICs. We doubted we would be able to close
the designs at all. It was design hell. BUT, once we got _timing-driven_
placement flows in place, every single ASIC has closed timing in one pass
through the final layout flow using standard Avanti & Cadence software.
It wasn't a slam-dunk. It wasn't like we took the bright-colored wrapper
off the tools and found ourselves instantly enveloped in design nirvana. We
had to change the way we structured our projects. We had to put a lot more
up-front emphasis on the development of _quality_ timing constraints. But
to get out of that nasty timing thrash, it was more than worth it.
Anyway, I got some tantalizing experimental results with Magma on a nasty
0.35um design. The Magma results were faster, denser, and produced with
less synthesis effort. Why am I _not_ pushing Magma for my next set of
ASICs? Because it's not that simple:
- Cycle time. Magma tromped every non-timing-driven placer on these
0.35um designs. But when I matched it up against a timing-driven
placer, it only does *slightly* better (5% better vs. 10-20% better).
- Density. I'm pretty much pad-limited in 0.18um, and I'm going to
be pad-limited out the wazoo in 0.15um. Density's nice, but I'm not
going to re-make my flow to get it. Zero points for Magma here.
- Synthesis effort. OK, our DC resynthesis effort to close timing
*without* a timing-driven placer was brutal. But since we:
1) ramped up *with* timing-driven placement,
2) partitioned our designs, and
3) emphasized good timing constraints,
our gate resizing and buffer insertion have closed 99% of our paths.
DC with timing-driven placement works. Could Magma have reduced our
synthesis effort even further? Likely. How much further? Don't
know. Don't care.
There's also the TTTMF factor -- Time To Trash My Flow. My friendly
neighborhood ASIC vendors just adopted timing-driven placement in the last
year, even though this technology ramped into the industry 5 years ago.
These guys are allergic to physical design solutions that haven't been
road-tested. Who road-tests new physical design technology? Processors.
Take a look at plots of Merced, UltraSparc III, Athlon -- how much place &
route do you see there? I'm thinking 10%, maybe 15% of their logic, tops,
and the number will almost certainly go down the further they go past 1 GHz.
Are they going to want to road-test new P&R solutions for something that
makes up 5% of their chip? I wouldn't.
Bottom-line: If I'm smart about it, I can close timing with what P&R tools
I've got today. I see a lot of promise in Magma, but I can't guarantee a
payoff worth its stabilization cost. And I don't see any processor guys
interested in getting the kinks out. So the way I see it, all these new
physical synthesis tools are a waste of time.
- [ Tony, the Tiger ]
|
|
