( DAC 02 Item 13 ) ---------------------------------------------- [ 9/10/02 ]
Subject: Synopsys PhysOpt, Floorplan Compiler, Avanti Jupiter
TOUGH CHOICES: With an estimated 1,200 tape-outs, PhysOpt unquestionably
owns the physical synthesis market. Synopsys obsessively focused on this
niche and took it over. But in one of those strange quirks of fate, while
their PhysOpt completely dominates physical synthesis, their floorplanning
solution, Chip Architect, fell completely on it's face with users. To deal
with this, Synopsys released a new tool at DAC called Floorplan Compiler.
On top of that, in a move that made a lot of waves in the EDA industry,
Synopsys aquired Avanti. So now Synopsys has a boatload of Avanti tools
to sort through. In floorplanning it has to choose between:
1.) Floorplan Compiler (FPC) that has a lot of the look and feel and
functionality of the wildy popular First Encounter. Floorplan
Compiler currently does not run on the Avanti Milkway database.
FPC is production beta right now; meaning that there's only a
handful of users exhaustively testing it on chips now.
-- or --
2.) Avanti Jupiter/Jupiter-XT that has it's own unique look & feel,
it's native to the Milkyway database (meaning it's well debugged
working with other Avanti tools) and has an established user base.
It's a tough choice. Either approach has it's ups and downs. At DAC they
wisely told users to let placement be the deciding factor for now. Use
Jupiter/Jupiter-XT for floorplanning if you intend to use Apollo/Astro to
*place* your chip. Use Floorplan Compiler for floorplanning if you're
using PhysOpt to *place* your chip. That buys them some time for now at
0.13 um, but things are definitly going to change by 90 nm.
"I only use Synopsys PhysOpt. With Design Compiler experience, PhysOpt
is not hard to use."
- Pascal Gouedo of STMicroelectronics
"We've been an early partner with Synopsys on their Hidden-Dragon or
Floorplan Compiler flow. I've been very impressed with this tool. It
can insert feedthroughs between blocks. FPC will insert buffers
automatically for you based on length or parasitics. We enjoy working
with Floorplan Compiler. It has enabled us to do a true top-down
floorplan. Their clustering algorithms are nice. Figuring out how
things should be grouped has been made easy. We have some blocks
running at 250 MHz with 24 levels of logic. Editing is easy. It
has some strong ECO features that makes updating the database simple.
RTL and port changes are all easily handled. Once we have the initial
floorplan, we can turn a new floorplan in a couple of hours to a couple
of days depending on the magnitude of the changes. (We have 6+ million
gate designs.)
What I think FPC lacks now is budgeting. Their budgeting capabilities
still have problems. They generate numerous virtual clocks. Some of
the constraints generated are bogus (input delays greater than clock
period). They don't have an "ideal_net" construct which makes their
budgeting almost useless. (You want to budget up front, not after
blocks have been released and clock trees inserted. Unlike First
Encounter, FPC can't insert clock trees yet.) It lacks a timing driven
placement algorithm. (I am told this is coming out soon.) The tool
works in a reasonable time. The Cadence tool, First Encounter, is
faster on some things, but FPC gives you some more useful data from
its run. I like the fact that the First Encounter flow can insert the
clock tree, while in the Synopsys flow this is done in PhysOpt."
- Maynard Hammond of Scientific-Atlanta
"Synopsys' "Hidden Dragon" was finally released and renamed Floorplan
Compiler (well you just knew it had to have "compiler" in the name).
It uses a "virtual flat" approach, where the design is physically flat
but retains its logical hierarchy. It uses "smart clusters" for
floorplanning, where the logical hierarchy starts out together but
can get mushed around. It does power analysis based on Power Compiler
or Primepower files. One thing they emphasized was their ability to
do abutted floorplans (i.e. no routing space between blocks). In
order to do this you need to be able to automatically generate
feedthroughs, and they emphasized this is much harder than it sounds.
It requires that you update the logical hierarchy with new feedthrough
ports and constraints, and your time budgeter must provide
time-of-flight budgets for the feedthroughs, plus if you need to add
repeaters in a feedthrough it must be added at the right level of
hierarchy, and ECOs become a whole lot harder. Anyway, they claim
this is a unique feature of Floorplan Compiler.
- John Weiland of Intrinsix
"Our eval has convinced us that Floorplan Compiler's virtual flat
approach is a significant value added to our design flow. As for bugs,
the tool appears mostly stable. Its hierarchy management and block
planning features can significantly improve design productivity and we
found it reducing floorplanning cycles from weeks to days. Our target
for power network analysis adoption is early Q4 2002."
- Valentina Baiardo of STMicroelectronics (from ESNUG 398 #1)
"Floorplan Compiler (v2002.05) is available at the SNPS ftp site. Does
anyone know if Chip Architect licenses will be converted to FPC
licences?"
- Mark Wroblewski of Cirrus Logic (from ESNUG 396 #4)
"We tested Saturn for more than 1 year trying to bring up timing-driven
flow in Apollo line. (We have already PKS flow running for over 1 year
in production flow.) In the end, Saturn was proved to be useless.
Very buggy in STA and constraint parsing. I believe Synopsys will
integrate PhysOpt+Apollo and throw away Saturn.
Cadence PKS is pretty good but I still need to build another flow based
on Apollo, so PhysOpt will be our next tool. We have seen pros and
cons in both flows. Hard to say who will win."
- [ An Anon Engineer ]
"Currently use Apollo/Synopsys/Saturn as well as PhysOpt. Looking at
Magma BlastFusion."
- Phil Hoppes of Intersil
"We are using PhysOpt. Amazing step forward. When we did eval last
year it was the only tool that actually worked. Have seen definite
improvements with recent releases of PhysOpt. Even just doing
initial placement without timing it does a better congestion-driven
placement than Silicon Ensemble. I don't like capacity (run time is
related and generally annoying. Our PhysOpt runs typically take a
couple of days.)
I really like having same static timing behaviour between tools.
Although PrimeTime and PhysOpt do delay calculation differently and
there are sometimes minor differences in latch treatment, the
constraint commands work the same and Synopsys is trying to bring
everything closer together."
- John Webster of Intel
"The 0.13 u PhysOpt/Apollo flow that we have in production works. We're
introducing Astro as it's mature and to improve productivity. This is
also to support 90 nm. We already have 2 test chips through the 90 nm
PhysOpt/Astro flow here. FYI, we are also developing and/or applying
on projects Magma, Monterey and Cadence Nano in case they have a
breakthrough somewhere. Maturity problems and their lack of support
prevented us to see any breakthrough there so far. But it might be a
question of time. We're more focused on PhysOpt/Apollo/Astro here."
- Jean-Pierre Geronimi of STMicroelectronics
"I feel that PhysOpt seems ahead of PKS in its quality and GUI, but
PhysOpt is missing floor planning (now they have PhysOpt-MPC) which
makes the flow too complicated. Also the data compatability between
PhysOpt and other P&R tools such as Silicon Ensemble is a headache.
Since we are pushing the performance envelope, we still prefer to use
PhysOpt in our flow. I imagine users with less aggressive timing
requirements may find PKS helpful."
- [ An Anon Engineer ]
"We've had great results using PhysOpt and would use it exclusively
except for the price. Astro has given us almost as good results at a
much better price, so we use Astro mostly. We keep PhysOpt for the
extra hard blocks that have trouble closing timing."
- [ An Anon Engineer ]
"About all I know is that we use PhysOpt."
- [ An Anon Engineer ]
"Synopsys PhysOpt is the real deal. Used it on a tapeout (850K gate
equivalents + RAMs, regfiles, 2 10-bit triple DACs and 3 PLLs;
altogether 9.3M transistors, top speed 180 MHz targeted and achieved)
and PhysOpt did great. What was most impressive to me was we took an
original design, added a block with 15% of the original core area,
and came up with a new chip that was just 3% larger than the original.
The other EDA tools in this space don't matter to me at this point."
- Mark Wroblewski of Cirrus Logic
"PhysOpt seems to be winning, although technology wise, I think
Sequence's PhysicalStudio is better."
- Weikai Sun of Volterra
"Rapid Prototyping Environments Demos
Magma - Blast Prototype
Monteray - Sonar
Synopsys - Floorplan Compiler, Jupiter-XT, PhysOpt-MPC
All of the tools (except Sonar) has some form of Interface Logic Model
that hides the internal paths of a module yet included all of the IF
logic of the module. Jupiter and Magma go one better and also capture
power rail physical info in the model. Magma is the most advanced by
incorporating all physical information important for signal integrity
(called a glass box model).
All of these tools have a sweet spot around 70% utilization. The idea
is that changes due to RTL ECOs, detail route, and SI don't perturb
the whole floorplan.
The Synopsys dogma is:
* If you are using Astro for physical synthesis then use
Jupiter-XT for prototyping.
* If you are using PhysOpt for physical synthesis then use
Floorplan Compiler for prototyping.
but only Astro has a decent SI story.
PhysOpt-MPC does not need a DEF floorplan before it can place gates.
(It will create a crude floorplan on the fly.) The idea is to let the
RTL guy know when an architecture must be changed to meet area or
timimg goals. Results vary greatly w.r.t. pin assignments (so dumb
pin assignments => questionable conclusions about the RTL)."
- Joe Eury of Intersil
"Synopsys has been talking about their Hidden Dragon tool for a long
time, which they finally introduced as Floorplan Compiler. Avanti was
also working on one, which they introduced as Jupiter-XT. With the
merger, Synopsys finds itself in the very unenviable position of not
just owning two competing tools but actually trying to introduce both
of them at the same DAC. Their solution is to say that the tools
aren't exactly competing. I attended the demos or both tools, and in
both cases they said that it is critical that your planning tool be
correlated to your placement engine. If you use Synopsys PhysOpt for
placement, you should use Synopsys Floorplan Compiler for planning. If
you use Avanti Astro for placement, you should use Avanti Jupiter-XT
for planning.
This makes a ton of sense to me, although I must admit the fact that I
agree with an obvious marketing ploy makes me second guess myself.
The Jupiter-XT tool, formerly from Avanti, is supposedly correlated to
the new Astro router, while the Jupiter planner is correlated to the
older Apollo router. Jupiter-XT gives advice on physical vs. logical
hierarchy and keeps the two separate (always an issue). It partitions
based on congestion and timing. It can do non-rectilinear blocks and
can push power lines into the blocks. It produces a TDF pin constraint
file and can support real areas array pads (not just redistribution).
Jupiter-XT can support bump placement, signal assignment, connecting
drivers to bumps, and interfaces to Comet, Encore and Astrorail. It
extracts all top level nets and does time budgeting. It can provide
top level and block level SDC constraints."
- John Weiland of Intrinsix
"I've been using Jupiter for quite a while now and just like any other
tool, Jupiter has its own advantages and pitfalls.
First of all, it operates on the same Milkyway database as the rest of
the Avanti tools and we being completely dependent on the Avanti suite
for the backend, Jupiter fits in very well from the data management
point of view. I can have consistent routing rules (in case I need to
specify different rules for different nets) and this can be propagated
down to Apollo when I do block level design. Jupiter's blackbox
modeling is pretty powerful, if we treat all sublocks as blackboxes.
The need to do so arises because of Jupiter's lackluster performance
in reading in huge gate level netlists & manipulating them at the full
chip level. Identifying and placing the macros/RAMs at the top level
is tough if they are burried into more than one level of hierarchy.
Avanti came up with a better GUI and added some functionalities and
called it Jupiter-XT, but IMHO the price/performance ratio of
Jupiter-XT is not any better than Jupiter. SoftMacro pin editing is
great, but pin generation is purely based on connectivity & congestion
and not timing driven. Also, the pin placements are good based on
connectivity, but they are not the best placements. I do have Scheme
scripts and I put in manual effort after that to come up with a cleaner
pin placement.
Power planning: Jupiter does a good job in creating power straps at the
top and in pushing them down into the blocks. However if there are
multiple instantiations of a block, I don't like the way Jupiter
handles them and I don't buy Avanti R&D's explanation justifying
Jupiter's behavior either. In that case, my experience tells me not
to push down power from the top.
Competition wise, the only other tools that I am aware of in this space
are Synopsys' Floorplan Compiler (FPC) and Cadence's First Encounter.
The technical info and demos on FPC are impressive and I feel FPC is
certainly better than Jupiter, but demos are always good; aren't they??
I haven't updated myself with First Encounter's latest developments,
but it was delivering the technology that FPC intends to deliver now
at least an year back though I do not have a comparison of the QOR.
Now that Synopys has taken over Avanti, I wish and I hope that they
integrate FPC and Jupiter together into one tool with the best from
both. That certainly would be a step in the right direction."
- Jay Pragasam of Brecis Communications
"I'm using Jupiter (the Apollo version) & Jupiter-XT (the Astro rev)
on a project that's a little over a million placeable instances (~5M
gates depending on how you count RAMs). I use the tool mostly for
intital netlist processing, hierarchy manipulation and preliminary
protoyping of my chip (pushing blocks around).
JXT is _much_ better than the classic Jupiter/Apollo/Planet tools with
respect to chip prototyping and floorplanning. Theie new GUI (TCL
based overlay on top of the legacy Jupiter engine) is faster and easier
to use. It could certianly use improvement in some areas such as
memory usage, user interface, speed, and documentation. For instance
you can drag blocks around with the mouse but it's hard to align blocks
precisely. The interface has an X and Y coordinate box that updates as
you move the block. You can type new values in the box (giving the
impression I can just type in the coordinates) but the block does not
move. Once you select the box and move it slightly, the coordinate
reverts back to wherever the mouse put the block. Avanti/Synopsys
definitely needs to pay attention to the GUI details. To be fair I
showed them some of the other issues I had during the eval and they
fixed them in a reasonable amount of time. The support from Avanti has
been great. They sent an apps engineer down here twice (Ryan Hoke)
who was very helpful in getting me up to speed on Jupiter.
Now that my floorplan is stable (blocks are moving around and changing
shape), I scripted the build process using Make and SCHEME scripts (the
native scripting language of the tool). When I get a netlist update I
can run make and rebuild the floorplan in just over a half an hour.
Not too bad. JXT takes about 30 min to read in and process my netlist.
The remaining steps (flattening some hierarcy, binding the netlist,
creating a floorplan view, and placing the IOs and core blocks) takes
about 5 min with the script.
One major limitation Jupiter (and Avanti's tools in general) have is it
can only handle designs with less than 250K instances at one
hierarchical level. I tried flattening my entire design and doing a
placement and after 2 days I killed the tool. In contrast, running
the design in Cadence's First Encounter tool can process the flattened
design in around 8 hours. I get around the instance limit by breaking
the design up into hierarchical blocks (6 major ones at the top level).
This method allows us to apply different tools (PhysOpt, First
Encounter, DC Ultra, etc.) and methodologies to different blocks in the
design as appropriate. It also allows multiple people to work on
pieces of the design in parallel.
Another area that could use improvement is the interface to other
tools. Particularly PhysOpt and First Encounter. We primarly bring
the a design into the tool by reading a netlist, PDEF, and
SDC/Primetime constraints. Jupiter's native reader PDEF reader just
does not work with PDEF files created by FE and PhysOpt. There are
some scripts provided by Synopsys that convert PDEF to SCHEME scripts
but these are just patches. Avanti/Synopsys needs to fix their PDEF
3.0 reader and writer. Perhaps with the merger this will happen soon.
The PrimeTime constraints reader usually requires the scripts be
"cleansed" to remove "unsupported commands" like set_dont_touch. The
read in is OK but fills the log file (and screen) with numererous
warning messages. It would be nice to have a supress messages command
like DC does to filter out don't cares.
One thing I have not been able to do (probably due to my limited
experience in this area) is to get the timing engine in
Jupiter/JupiterXT to correlate with PrimeTime. Usually Jupiter reports
more pessimistic delays. I have yet to be able to get the tool to give
me the same (or at least similar) delay info as a StarRC-XT extracted
SDF run through PrimeTime report. I've done some global P&R work both
congestion and timing driven. The tool seems to work pretty well but
I have no real basis to compare against.
I actually just encounterd a major bug in the Verilog conversion
utility (hdl2A) that interprets all bussed pins on blocks (RAMS and
custom hardmacs) as LSB:MSB order, even though the tool is told to
order them MSB:LSB. This results in all the bus connections to RAMS
getting reversed. Not good. Fortunately I work around the issue by
using the Jupiter netlist reader which works fine. Their AE is aware
of the issue so I'm sure it will get fixed quickly."
- Tom Trocine of Adaptec
"Regarding hierarchical layout, now we are benchmarking Jupiter-XT.
First Encounter and Floorplan Compiler use similar technology. They
use virtual flat technology. AmmoCore also uses it. But considering
test and ECO TAT, maybe traditional floor planner like Jupiter-XT
will be the mainstream.
We are using Apollo/Saturn and Astro. Astro has more powerful
capability than Apollo/Saturn. Regarding PhysOpt, we will
benchmark it after Milkyway and .db are merged."
- Zenji Oka of Ricoh
"John, I just finished a chip in 0.13 um process. It's a well known
synthesizable microcontroller (can't give out the name) but the
requirements from my boss was: "Make it run at 300 MHz as no one else
in the world has done it". Of course in these troubled times no extra
bonus will be given. Be thankful that you have a job. Well... with
that in mind we started with completely writing our own DC synthesis
scripts. The scripts that were provided to us yielded only 200 MHz at
best. The flow was to use DC-Ultra and then do Apollo placement.
Well!! We only got 220-240 MHz after many runs.
I then pushed for PhysOpt (with DC Ultra) and in the first run it
achieved 285 MHz. Subsequent runs got me closer to 290 MHz, but
my design did not improve after that. To get to 300MHz, I did buffer
sizing by hand and acheived my last mile. So in my opinion PhysOpt is
a great tool, although I'd love to see clock tree insertion capablity
introduced into it (its coming I'm told). I have not used Magma but
am told that its a great tool for high-speed designs. We are actually
thinking of evaluating them."
- Himanshu Bhatnagar of Conexant
"Ultima has merged with BTA Technology to form Celestry. They sell a
tool that closes timing by purposely putting clock skew in the clock
tree. With the world moving to tightly integrated physical synthesis
tools, I'm not sure what the future of this tool is, but they say it
fits into PhysOpt flows."
- John Weiland of Intrinsix
"It's not my direct area of expertise, but I think Synopsys will win the
physical synthesis battle."
- [ An Anon Engineer ]
"We're using a design house for physical synthesis. They are using
Synopsys PhysOpt."
- Jay Abel of Shera International
"We're still using PhysOpt. Still getting good results with it."
- Chris Gorzek of Cray. Inc.
|
|
