( BSNUG 00 Item 15 ) ------------------------------------------ [ 10/13/00 ]
Subject: Physical Compiler (PhysOpt), Chip Architect, FlexRoute, FlexPlace
11 MONTHS & COUNTING: No real "big" news on the overall Physical Synthesis
came out during the Boston SNUG. Physical Compiler has 10 known, publically
user-confirmed tape-outs (although Aart claims he has 23); Cadence PKS has
one failed tape-out in April from EmpowerTel (PKS was used on a 50 Kgate
MIPS core inside a 3 Mgate chip) with no other confirmed tape-outs; Magma
and Monterey have no tape-outs. This means that Synopsys now has an 11
month lead in this market (the first 2 PhysOpt tape-outs were Matrox and
nVidea back in November'99) and has oddly become the Leader To Beat in this
niche. (Why I say this is odd is that given the backend nature of physical
synthesis, if you'd have asked me 4 years ago who I'd have predicted would
be taking the initial lead in this tool space, I would have said Cadence or
Avanti. After all, the backend *is* their home turf, right? Odd.)
"Synopsys Synthesis is near "End_of_Life":
More and more designs are being done in <= 0.18u, so the usefulness of
static timing convergence using the traditional "wire_load_models" in
synthesis is becoming obsolete. The reason is that when you go <.25u
in feature size, more of the delay is taken up in the routing which is
almost impossible to estimate without placement. What this is saying
is synthesis will be used for RTL->Netlist generation but will not be
able to perform the proper static timing checks based on routing
estimates. This requires the back-end or "routing" tool to do most of
the work to insure the design meets timing. This also means more
(Synthesis->P&R->Primetime) database iterations.
Synopsys is attempting to sell everyone "Physical Synthesis" to help
bridge the gap between front-end Synthesis and back-end PR to cut down
the number of front-end -> backend iterations. The tool allows a
preliminary placement of the design that can be handed off to the
back-end people.
Personal Thoughts:
Although this sounds like a nice solution, depending on the cost of the
tool, it might be worth the investment in the backend tools. If you're
going to spend the time in placing, you might as well do it in the real
back-end tool and iterate in house (we can target any vendor's library
and be more flexible in fab selection). It seems like Synopsys is
attempting to scare customers into believing that the back-end is too
complicated by offering what appears to be the easier solution."
- an anon engineer
"We expect to ramp up on Physical Compiler in the next few months for
our next project. Magma and PKS are too unstable to be viable for us.
Mike Montana gave a good tutorial."
- an anon engineer
"Physical synthesis, physical synthesis, physical synthesis. Get the
picture? That was a hot topic this year as it will continue to be.
Most of the design community represented at SNUG is well below 0.5u
technology and they are becoming more sensitive to the issues of
deep-submicron design. Physical synthesis is starting to take hold
with more of the designers as more of them experiment with it. Mostly
positive reports. Our current designs however don't come anywhere near
needing this type of tool, at least for now. Note: At 0.5u, we are in
the bottom 5% of design flows. About 40% are using 0.35, 40% are at
0.25u, 15% are at 0.18u and below."
- Brian Fall of Microchip Technology, Inc.
"Physical Compiler Workshop Trip Report, 9/19/00 - 9/22/00
(took this immediately prior to the Boston SNUG)
I found the single day workshop on Physical Compiler very worthwhile.
With a strong knowledge of DC and COT flows, one day is plenty to get
the basic concepts down and also get to play with the tools in the
labs. The labs were pretty straightforward, going through the
following steps:
o Converting LEF to plib using the lef2plib utility
o Writing pdb using the write_lib command
o Converting a floorplan DEF to PDEF 3.0 using the def2pdef utility
o Reading in wireload compiled gates, PDEF file, and running PhysOpt
o Analyzing physical views in the GUI
o Dealing with floorplan obstructions from macros and power straps
and creating obstructions manually
o Running PhysOpt with various switches and comparing results.
PhysOpt gets it's floorplan information such as RAM & macro placement,
power straps, pad cells, etc. from the PDEF file. Placement and layer
blockages are supported using routing obstructions. Soft and hard
keepouts are also supported. Global routing is done within the tool,
but that information is lost in the transfer to layout tools. The
output of PC is a legally placed design that can be written out as db
file, or a gate-level netlist and a PDEF 3.0 file. There is a utility
to convert the db to DEF, making the interface to Cadence tools pretty
straightforward. The Avanti conversion uses the netlist and PDEF and
involves the use of Scheme scripts.
The major advantage of this tool is the elimination of wireload models
by using Steiner routes and Elmore delays. The placement engine,
FlexPlace, is not a quadratic placer and is therefore free to place any
cell anywhere to meet timing and reduce wire length. The claims are a
10-15% Manhattan wire length reduction over traditional placers. This
makes the layout more routable and able to run with faster clocks and
less power. Wire length reduction is critical as designs move into
smaller geometries, especially below .25u, since wire delay is by far
the dominating factor. Since wireload models are at best a poor
estimate of the most dominate delay factors in the design, eliminating
the inaccuracy they introduce is key. Traditional methods of margining
the timing in synthesis leads to overbuilding the design, which means
increased area, die size, wire length, & power consumption. Combining
synthesis and placement allows the design to be implemented with much
greater accuracy, while reducing the wire length, area, and power.
Since PhysOpt is built on top of Design Compiler, a lot of the DC
functionality is there. PhysOpt adds physical switches to existing
DC commands. A DC Ultra license triggers additional optimization
features in Physical Compiler. I heard it said that Module Compiler in
DC works with Physical Compiler as well as the -scan switch for
compile. Stitching is still done with insert_scan, and is not yet
location based, but will be in the 2000.11 release. Full integration
with Power Compiler is also in development. Unlike DC, the command
interface is TCL only.
The modes of operation of the tool are gates to placed gates (G2PG)
with the PhysOpt command, and RTL to placed gates (RTL2PG) using the
compile_physical command. Presently, the G2PG method can handle up to
~2M gates. The RTL2PG mode can handle up to ~300K gates since only a
top down methodology is supported. A bottom up RTL flow is in
development, and I later heard it said in the SNUG PhysOpt tutorial
that simple compile mode is supported.
The tool has various switches such as -congestion and -area_recovery.
There is a GUI for viewing the floorplan, placement, and congestion
maps. It can run gates in place-only mode for congestion analysis
with multiple floorplans. Since clock tree synthesis (CTS) is done
outside this tool, the -incremental switch is used after CTS. I
heard there will be CTS by the end of the year, in both Physical
Compiler and Chip Architect. There is an ECO mode to merge in
new/changed leaf cells, as well as an incremental post_layout mode.
This can be used after layout extraction like Floorplan Manager on
steroids producing legalized placements instead of suggested
placements from incremental PDEF. This would be great for combining
PhysOpt with Min/Max compile for post-layout hold fixing.
One interesting aside is the wireload model problem has been pushed
back into the LEF. Having bad R and C parameters can be just as
damaging as having bad wireload models. Therefore, the R and C
parameters must be correlated.
SNUG Boston 2000 Tutorials: Physical Synthesis / Timing Closure
I caught the very end of this tutorial since I already attended the
PhysOpt class. I was just in time to see the live demo in progress
and here some very impressive evaluation statistics including:
o Performance improvements up to 24%
o Gate count reduction up to 4.5%
o Power reduction up to 12.6%
o Elimination of post layout iterations for timing closure
o Back end timing closure achieved in days instead of months
o RC correlation to detail route 0.4% pessimistic to 2.7% optimistic
In the Physical Synthesis tutorial, I found out that RTL to GDSII was
accomplished using a detail router Synopsys acquired from Gambit last
year. Interestingly enough, when I searched for Gambit on the Synopsys
web site, I found a mention in the key installation guide for SCL (the
new Synopsys Common Licensing). The tool listed as being compatible
with SCL1.1 was Encore, with Gambit in ()'s. The individual Gambit
tool entries are no longer shipped, and Encore is not listed among
their regular product offerings. Hmmmm. With CTS in beta, it sounds
like they are really close."
- Bob Wiegand of NxtWave
"Finally, on the subject of PhysOpt. I attended the tutorial on Friday
and have to say the AE from Texas, Mike Montana, was one of the most
dynamic and interesting speakers of the whole week. Not sure what that
says about PhysOpt, but if you are going to try and sell something for
those prices you better have a good spokesman and he was the right man
for the job."
- Martin Gravenstein of TDK Semiconductor Corp.
"Darell Whitaker of IBM did a presentation on Physical Compiler in the
IBM ASICs design flow for customers. Basically, PhysOpt fits in as a
mechanism to work with early floorplanning to synthesize a design and
generate a detailed layout for use in the IBM backend tools. Further
work will still need to be done to insert clocks & scan & do further
optimization.
The room was packed. He got lots of questions, including:
o What is the estimated time/effort for someone to incorporate Physical
Compiler into their flow? How much time did we spend?
We spent about 8 months. It should take much less than that to get the
tools up and running. A good portion of the 8 months was spent working
through issues of data conversion to go between Physical Compiler
formats & data formats used by IBM Physical Design tools. One problem
being worked around is support for differing levels of PDEF 2.0.
PhysOpt uses PDEF 3.0, but IBM is still migrating to that. Other time
has been spent on analysis & correlation between the physical modeling
of the placements between the Synopsys & IBM tools.
o What is the flow for post-routing ECO? Incremental mode?
We haven't investigated this yet.
o Did we do gates-to-gates or RTL-to-gates? What kind of runtime issues
are there in going from RTL-to-Gates? What about benchmarking
Physical Compiler to the traditional DC flow?
Most of our work has been on gates-to-gates. We're looking at
RTL-to-gates now. You can do a RTL-to-gates run in PhysOpt but you
still need to do a rough synthesis run first so that you can create a
floorplan. It's for a rough estimate to drive the RTL PhysOpt run,
otherwise you'd have something Chip Architect (which we don't use.)
Our flow is more back and forth between Synopsys and IBM's ChipBench
tools, so that means we use IBM's floorplanner instead of Chip Arch.
We're still benchmarking, but all the legal crap says I can't tell
anyone about it. Talk to the Synopsys and IBM lawyers if you want
this data.
o Design teams - do they need to change to think about floorplanning?
Darell's answer was that logic designers should always be thinking
about floorplanning. That might be an unwelcome change for some
people, but it's something we have to deal with all the time. We look
at a lot of designs where some redefinition of logic can have a major
impact on creating a design that will meet timing & wire, like large
multiplexers, where data & selects can be grouped based on the
floorplanning needs.
Physical Compiler (PhysOpt) Tutorial -
Good presentation and demos, with examples, by Mike Montana. What I
liked seeing most was the was the new PhysOpt GUI with the capability
to display a cone of logic in the logic viewer and then toggle to a
display of the same cone in the physical layout.
Mike said PhysOpt is using DesignTime and Chip Architect is using the
PrimeTime timing engine. Why doesn't PhysOpt use PrimeTime, too? Why
get more accurate, detailed info from physical floorplanning and then
back off when you go to run PhysOpt?
The coarse route in PhysOpt shoots for under 5% inaccuracy.
They are talking about merging all the db files into one in the future
to combine the logical & physical... so combine .db & .pdb."
- Chris Kiegle of IBM
|
|
