( SNUG 02 Item 15 ) -------------------------------------------- [ 5/15/02 ]
Subject: PhysOpt vs. Magma vs. Cadence PKS vs. Monterey
GLOAT, GLOAT, GLOAT: Right after DAC'01 last year, I reported on ESNUG the
following June 2001 physical synthesis numbers:
Synopsys ########################################### 170 tape-outs
Magma ######### 36
Cadence PKS ### 12
Monterey 0
This data was explained at the time in DAC 01 #27 & ESNUG 374 #7. Well, lo
and behold, Dataquest reported 5 months *after* I reported my tape-outs
their marketshare numbers. I'll be damned! Matches my data nicely.
Dataquest FY 2000 Physical Synthesis Market (in $ Millions)
Synopsys ################### $19.1 (64%)
Magma ####### $6.9 (24%)
Cadence ### $2.9 (10%)
Monterey # $0.5 (2%)
I'm sorry for gloating here, but you don't know the crap I got from Cadence,
Magma, & Monterey for reporting those tape-out numbers. I don't blame them
really. They came out behind, so it was in their best interest to discredit
anything that made their physical synthesis marketshare look bad -- even
though it was the bloody truth at the time! (Sheesh.)
Anyway, here's my estimated tape-outs for May, 2002:
Synopsys PhysOpt ######################################## 600 tape-outs
Magma ####### 100
Cadence PKS ## 36
Monterey 3
Synopsys reported 500 tape-outs at SNUG'02 and just this week they claimed
600 tape-outs in a press release. Magma made the 'over 100 tape-outs' claim
at the big press event they had 2 weeks ago. I called them on it and they
said 50 of them were from TI. That kind of surprized me because I know that
at least TI Dallas Broadband, TI Phoenix MSP, TI Houston DSP, TI India, TI
France, and TI Japan Wireless are firm PhysOpt users -- not Magma users. It
turns out that the only group I could find that's using Magma was TI ASIC.
This complicated things because TI ASIC is an early Magma investor. It
means they're under internal pressure to show that the investment in Magma
was wise. That 50 could be real or political... Wait! Either way, this
is no biggie. We already know PhysOpt and Magma have working flows. If
there are 6X or 12X PhysOpt tape-outs for every Magma tape-out, does this
say anything new? PhysOpt's way ahead of Magma. No new news here.
Now the hard part. I found 7 Cadence PKS tape-outs in my initial Dec 2001
tape-out count. Three months later (Mar. 2001) in SNUG 01 #7, Cadence
reported a total of 12 PKS tape-outs. By scouring ESNUG and the press
releases/success stories on the http://www.cadence.com web site, I found:
# of Cadence
Date Company Tape-outs Tool Source
-------- ----------- -------------- ---------- ---------
01/17/01 Crest Microsystems 1 PKS/SE-PKS Press Release
01/17/01 Fujitsu 1 PKS/SE-PKS Press Release
08/29/01 Cisco 1 PKS/SE-PKS ESNUG 376 #3
09/01 AHA 1 PKS/SE Success Story
09/28/01 TDK Semiconductors 1 PKS/SE-PKS Success Story
11/01 XtremeSpectrum, Inc. 4 PKS/SE-PKS Success Story
11/28/01 Sunplus 4 PKS/SE-PKS ESNUG 383 #1
01/02 Jaldi Semiconductors 1 PKS/SE-PKS Success Story
This is a total of 14 PKS tape-outs being reported on the Cadence web site.
Since 2 of these are on 01/17/01, I'm assuming they're already part of the
Mar. 2001 count of 12 PKS tape-outs. This means that altogether, I can find
only 24 Cadence PKS tape-outs. Now assuming that there's an additional 50
percent of PKS tape-outs that Cadence couldn't get the customer to agree to
talk about publically, this makes the true total of 24 + 0.5(24) = 36 PKS
tape-outs one can reasonably justify. This makes PKS 15X behind PhysOpt.
"I would have said that PKS only has about 30 user tape-outs right now,
but that's a guess. People are trying it from their bundled tool
purchases from Cadence. Power users don't use PKS; it's the under
200 Mhz, 0.25 um, under 2 million gate mainstream users trying it."
- Gary Smith of Dataquest
The 3 Monterey tape-outs I counted myself: 2 at Infineon and 1 at Zoran. It
must really suck to be Monterey. With 740 rival tape-outs ahead of them,
this makes Monterey 248X behind everyone else! Ouch.
"We expect to migrate to PhysOpt in the next 12 to 18 months. We
expect it to be easy to migrate to from Design Compiler."
- Scott Campbell of Motorola
"There's no way to avoid one of these tools. When Synopsys gets to
RTL2GDSII, they will be hard to beat. Until then I'll use whatever
tool my ASIC vendor tells me to (which is Magma for this chip)."
- Brent Lawson of Texas Instruments
"You ask if we using this within the next six months? We're using
PhysOpt on real designs as I write this. We chose Synopsys after a
lengthy eval, in large part due to past experience with their toolset.
Having said that, there's a strong base of PKS users in other groups
here and a drive to 'converge' on a single toolset; this may affect
our future tools."
- an anon engineer
"PhysOpt works good enough. We don't have to have a Synopsys engineer
holding our hand. These other companies (and to some extent Astro,
from Avanti, for that matter), address some issues today, that PhysOpt
doesn't: such as integrated clock tree synthesis (available with
PhysOpt to 'limited' customers), detail routing (again, available to
'even-more-limited' customers), and some degree of SI-aware P&R.
PhysOpt has caused us some heartache in post-route optimizations of
congested designs. It's Steiner router does not correlate with
detour routes taken by Apollo/Astro to work around congested areas,
resulting in huge numbers of DRC violations. This problem will
continue until Synopsys gets Route66 (or some other *working*
detail router built into PhysOpt) productized!"
- Neel Das of Corrent Corp.
"We use PhysOpt here and been generally been happy with it. However we
use it mostly to 'prove' feasibility to our customers. Their design's
scan/clock_tree/ECO etc is done back in Japan."
- an anon engineer
"Introduction to Physical Compiler (PhysOpt)
+ Overview of PhysOpt flow (nothing really new presented)
+ PhysOpt is suppose to have sufficient command line interface
to do floorplanning (without GUI).
+ ClockTree Compiler and Routing Compiler not released yet.
Q: How will Avanti flow integrate with PhysOpt flow?
Hierarchical Physical Synthesis with ILM Models
+ Interface Logic Models (ILM) allow PrimeTime/DC/PhysOpt to run
faster using less memory.
+ PrimeTime ILMs are flat with no phyiscal information, written
out as flat Verilog netlist and support back annotation.
+ DC/PhysOpt ILMs contain original hierarchy and physical info,
in DB format and support back annotation.
+ DC/PhysOpt ILMs will allow top-level optimizations/routing to
be run on the full-chip without having to load entire design.
Q: How well will ILMs interface with 3rd party tools?"
- Kent Ng of Microsoft/XBox
"I asked Oren Rubenstein (ex-HP Canada, now with nVidia) what he thought
about doing RTL2PG physical synthesis and the ideas behind MPC (minimal
physical constraints - a way for logic designers to create a quick dumb
floorplan and run compile_physical with it). He said they don't route
each block (they route groups of blocks) so it wouldn't be useful."
- an anon engineer
"PhysOpt-MPC sounds interesting, but not if it costs much more than
Design Compiler."
- Oren Rubinstein of Nvidia
"I attended the second Wednesday session entitled 'Physical Synthesis
/ Timing Closure'. The first two talks had very little of interest
in them. It seemed to me that Jay McDougal had talked about most of
the material 3 to 5 years ago. The first presenter did mention using
PhysOpt MPC beta and getting good results, but they only used the
netlist. They threw away the floorplan as it had illegal cell and
macro placements (overlaps), core rows unflipped (causing VDD and GND
shorts), and other problems. The presenters agreed that RTL2PG can
lead to long run times. Other points that were made: don't use
map_effort medium with congestion_effort high, set both to high, also
it would be nice to be able to tune X and Y congestion thresholds
independently.
The third presentation was an excellent overview of the timing closure
problem and the flows that have been used to attack it. The only
criticism I have is that the testcases used were both fairly small by
today's standards. Interesting ideas from this presentation:
- Two pass placement: first place the cells connected to IOs,
then place the rest of the cells
- Run initial physopt twice: first with -area_recovery, second
with -incremental
- G2PG flow results in a much better area than RTL2PG flows
- PrimeTime and PhysOpt's timing numbers are close so no need to
overconstrain (though Kurt Baty says overconstrain by 15%.)
The paper's called 'A comparison of Timing Closure Approaches'."
- an anon engineer
"Overall I think PhysOpt is not ready to compete against LSI's MPS and
MRS. However Synopsys appears to be committed to making PhysOpt a
standard in the industry.
Cons: Some of the problems I saw with PhysOpt was that it was not
user friendly when it came to placing individual cells, had bad
optimization techniques during placement, had no crosstalk placement
analysis, has only been tested on small designs, and does not
interface Avanti very well.
Pros: Some of the benefits of PhysOpt were the use of ILM's to
perform Hierarchy flows, its ability to work with other Synopsys
tools (DC and PrimeTime) for timing based placement and that it
could be run in non-GUI format.
There is a new Beta tool that ST and Synopsys are working on called
PC-MPC. It has the same purpose as lsimom, in that its trying to go
from RTL -> to route with minimal human engineering efforts. Overall
the presentation was good but MPC has its limitations. ST is the first
to point out its weaknesses but its clear there is a push in the
industry for this kind of technology. It might be worth getting in on
some of the Beta test programs of this tool to see how effective it
really is. One down side is that it uses PhysOpt for its automation
placement. Good informational presentation."
- an anon engineer
"PhysOpt to me basically seems like DC with a lot of clumsy overhead
used to replace WLMs. We are currently using it at Philips based
the on judgment of a CAD manager who fancies himself to be a guru of
all things Synopsys. I think it came down to less work for him than
using Cadence PKS as an alternative."
- an anon engineer
"I haven't used PhysOpt, but for timing critical designs, the philosophy
behind it seems very sound. If I do switch from DC, I would push for
PhysOpt, given my familiarity with DC."
- Eric Mitchell of Cypress Semiconductor
"Actually about a year ago we compared 3 tools: Cadence Silicon
Ensemble PKS (SE-PKS), Avanti Apollo2 and Monterey Dolphin as a back
end tool. At that time, Synopsys PhysOpt didn't have a router. We
left it out of our selection. Magma was also attractive, but it needs
a lot of scripts to run, so it was left out, too.
Our key points were:
- Since we started a new design team with a few engineers (and
not very experienced), the tool/flow should be easy to learn,
very self-explanatory and straight-forward.
- Very fast turnaround time needed. For schedule reason it was
important to be able to re-run quickly in case mistakes are made.
- Due to the tight time schedule and no time to plan/design system
upfront, we had to make sure that we don't have iterations for
timing closure, routing, etc.
Silicon Ensemble and Apollo are tool sets. They are very flexible, but
need a lot of scripting work and CAD management to maintain.
Furthermore, Cadence and Avanti had their engineers focused on their
new EDA tools, Integration Ensemble and Astro. They announced they
won't do any enhancement requirements concerning legacy tools like
Silicon Ensemble and Apollo II except certain bugs.
On the other hand, Monterey didn't have all that baggage.
It took about 3 month to build a basic Monterey design flow with
Soliton's (Japan Agency of Monterey) help. We believe that
Dolphin should satisfy our many requirements for improved TAT and
design efficiency in the mid-range Mixed Signal ASIC design flow."
- Hiroyuki Nakamura of Canon
"We evaluated PhysOpt and thought the tool did a good job but was
overpriced. A floorplanning tool should be incorporated into PhysOpt
and not be a separate part of it. I want a tool that you can floorplan
with at the pre- and post-RTL stages, and then use that same tool to
turn your floorplanned RTL into a placed gate netlist. This also
implies that power routing and clock tree insertion should also be done
with this same tool. PhysOpt tool on its own is only half a tool."
- an anon engineer
"At this point I have two choices as I see it, get a PhysOpt seat, or do
RTL hand off. I think I'll most likely do the latter because of the
learning curve on these tools."
- David Bishop of Kodak
"I attended the tutorials on PhysOpt. Tech content pretty good. I do
not understand why every single session indicated 'you do not need wire
loads for PhysOpt'. In order to use PhysOpt you need to have a floor
plan already built and all of these tools need a wire load to setup
the block level partitioning. All of the PhysOpt sessions also had the
same question over and over from the audience - 'how do you get the
initial module placement?' The correct answer should be 'from a timing
driven floorplan created with Chip Architect or Planet/Jupiter' however
this was not offered for 4 sessions. The response instead was 'we are
working on it'. Unfortunately, the physical world is not the same as
synthesis. You need to have some sort of basis for the pad ring,
origin for the power grid and hard macro placement for all the 'detail
placement' tools to know where the boundries on the design are.
Synopsys needs to let these front end designers know that unfortunately
the concept of a physical size and pin out are coming to their world."
- Pallab Chatterjee of SiliconMap
"PhysOpt looks to be late in incorporating clock tree synthesis as part
of their flow. This feature is available now with Astro, Monterey,
Magma. We have seen also some SI divergency between PhysOpt and Apollo
(the flow we use is Physopt + Apollo).
We ran comparison benchmarks about a flow composed of PhysOpt 2001-08
+Apollo 4.9 versus Monterey 2.1 versus Magma 2.1 on a 0.18um process.
What we saw:
- Significant run time improvement with either Magma and Monterey
versus PhysOpt+Apollo with normalised CPU runtime, independantly
of multi threading.
- Fast prototyping loop available in Magma and Monterey (Sonar) which
allows to save a lot of time in tuning the timing constraints and
floorplan. It was typically 7 hours compared to a whole 34 hours
implementation run.
- QoR better with Magma & Monterey for what maxCap/Tran fixing is
concerned.
- Fact that clock tree is part of the physical synthesis process is
simplifying the iteration loops, and reduces the overdesigning.
- Apparently, Signal Integrity is better handled - at least seems
transparent - in Monterey and Magma.
- Scripting is much more simpler in Monterey and Magma than with
PhysOpt + Apollo.
Overall, we think there is an advantage to move to Magma or Monterey.
Our fear is that those approaches are a bit 'black box' and less open
to manual tuning than PhysOpt and Apollo. Although Monterey is more
open than Magma, using DEF interface at the placed gates level."
- an anon engineer
"No, we don't envision forking out more big bucks for these new
physical synthesis tools. Our DC/Apollo/Primetime flow seems to
be still chugging along fine for our 300k gate chips."
- Jeff Waite of Netergy Microelectronics
"PhysOpt Advanced Topics:
- the -check_only and -quick options are useful
- overconstraining unnecessary and costs time and area
- use GUI to find congestion, use -congestion_effort high
and -timing_driven_congestion
- set_congestion_options command
- wide power nets should be complete obstructions
- average cell displacements should be less than one row height,
large displacements mean a poor floorplan
- check_legality -verbose command
Other tutorials that look good are:
Test Synthesis and ATPG Methodologies for Large, Complex Designs
Physical Synthesis Heirarchical Design Flow"
- an anon engineer
"Synopsys has done a great job of selling PhysOpt into the DC installed
base, but my impression is that they are still selling mostly to
front-end designers. While it is true that PhysOpt can output a
DRC-correct placement, I don't know of anyone who is using PhysOpt as
the final, detailed placement engine for >1 million gate designs.
Magma is enjoying some success selling into Avanti's installed base.
They seem to do very well on small, sparse designs that are timing
limited. They have trouble on designs larger than 1 million gates,
or on designs that are very dense and congested area or routing
limited. Their fixed timing approach requires a certain amount of
'area slack' in order to be able to swap in the required cells.
They also require a cell library with a high level of granularity.
Monterey claims to have done some very large, flat designs (3-5
million gates). Their big drawback is that they require a huge
machine, and they do not yet support Linux. Their constraint
reduction capability is an absolute 'must have' for large designs.
Plus, for block assembly Aristo continues to gain design wins."
- an anon engineer
"Synopsys PhysOpt: costs too much relative to what you get out of it,
also it works on different database from the P&R tool, not give a
complete solution, not really save time in the flow, and I think that
its time pass already.
Cadence PKS: also does not give a complete solution, and does not solve
issues related to a deep sub micron processes, the internal algorithm
is based on S&S that activate some old other Cadence tools, and have no
signal integrity solutions, its time pass.
Magma: a tool from the new generations that give a complete solution
from RTL to GDS, take care of most of deep sub micron issues and signal
integrity. Seems to me a very powerful good tool, needs to demonstrate
itself on some big designs, cost a lot.
Monterey: a tool from the new generation very user friendly, give
complete solution from netlist to GDS, IC-Wizard is a very powerful
placer that saves many many hours of work, and enable to achieve a very
fine tuning floor plan ready for Dolphin. Dolphin is also a very
powerful tool, very simple to use and give fast results with very good
performance, save also many engineering hours of work, in the block
level the tool is mature, in the full chip top level some issues are
still under development and need improvement.
We are using Monterey tools and very satisfy from it, its enable us to
short schedule dramatically comparing to Avanti or Cadence flow with
much smaller team (basically one engineer).
Also we got very attractive price on Monterey, so the total price
performance is really good."
- Gideon Paul of TeraChip
"Two of my customers are using Monterey Sonar/Dolphin with excellent
results. You can use 4/8/16 processors with Sonar/Dolphin and get much
faster turnaround than using PhysOpt. None of my customers are using
Magma Blast or Cadence PKS yet for production work, although they are
evaluating them."
- Tom Moxon of Moxon Design
"I was requested by an independent consultant of Monterey to give you a
response to some of your questions. Synopsys PhysOpt is certainly the
tool of choice. Reasons
a) Proven technology - has much greater silicon behind it to have
hashed out the bugs.
b) PhysOpt is linked somewhat with logic synthesis and no one would
choose other synthesis tool for risk management issues, other
than DC.
If I am looking to solve a point problem, then I would consider Magma
or Monterey, but I cannot trust my $30 M to $40 M design project with
a new methodology."
- an anon engineer
"I had some experience with PhysOpt in the past and I think it's an
excellent gates-to-placed-gates point tool. The problem is the flow.
We are doing low power designs, and we gate clocks extensively. This
was a headache for most of the physical design tools. Since PhysOpt
doesn't contain a clock tree compiler (at least available for us. I
guess they are trying it with some big customers) I didn't see a full
solution. We started to work with Monterey recently, and we already
taped out our first design. The nice thing is that Monterey gives you
a complete gates-to-layout solution including floorplaning, physical
synthesis, clock tree generation, routing and X-talk awareness."
- Nir Sever of Zoran
"I'd like to look at Magma as it has a complete solution. I think they
may either go out of business or blow Synopsys away in the next two
years in this market. It will depend upon how quickly Synopsys
can swallow Avanti."
- Tom Tessier of t2design
"We've found Monterey Dolphin correlates within 1-2% of Simplex
extracted parasitics through PrimeTime. CPU time used by Dolphin is
higher than what I'm used to in the Avanti tools, but Sonar, with it's
early estimates of timing based on early placement, helps to reduce
iterations due to incorrect inputs, poor floorplanning, or bad
netlists. Sonar is essentially the early stages of Dolphin, they
correlate within 10% of each other and Sonar uses 30% the CPU time
of Dolphin. There is also less interaction with Dolphin than there was
with Avanti. Dolphin generally creates first pass Calibre DRC/LVS
clean GDS, so the actual wall clock time to finish a block is less.
Dolphin is very good at block level, but is missing a few features for
an easy hierarchical flow. The top level chip is treated the same as
block level such that a lib and a LEF is required for all mega cells.
IC Wizard helps with this issue, but until Dolphin and IC Wizard are
integrated, it isn't enough."
- an anon engineer
"Synopsys (including Avanti) and Cadence (without Silicon Perspective)
have no new ideas. They have limitations in design size, turn around
time, clock implementation (e.g. usefull skew), power optimisation.
If I use them in the near future ,it would be not my choice but comming
from the management.
Magma and Silicon Perspective (paired with Plato) seem to have the more
innovative approaches. Of course, they also can't solve all problems,
but their R&D teams are adressing them at least.
We have very good results from Magma and working closely with them for
further improvements. The timing closure is excellent and we see
nearly no DRC, LVS or formal verification problems. (And a fix if
something is found is available very quick). Design size, useful skew
and their roadmap (in terms of timing accuracy for IR drop) make them
my first choice.
In Silicon Perspective the turn around times are excellent and the
timing closure is good. If my main goal is time to market and my chip
is not timing critical, they are my first choice. (For Plato, the
approach sounds good but I was not able to test them yet.)
For Monterey: I have not used their tools and have no contact to anyone
who has used their tools without major help from their R&D team. So no
statement on this from me."
- an anon engineer
"If we were to migrate to a physical synthesis tool, it would be
Synopsys."
- an anon engineer
"Even though PhysOpt is selling well, people don't use it in a
RTL-to-placement flow. Instead, people still use DC for RTL
to gates and then use PhysOpt for gates-to-placed-gates. This
means they practically treat PhysOpt as just a placement tool
(plus some global route function) for now.
- Andrew Cheng of Cisco
"We are using Magma now. The reason are:
1) Capacity. Magma can handle our chip flat with a reasonable
turn-around cycle.
2) Real integrated flow under one tool, one GUI. The same
interface is used for P&R, DRC, Extraction, and STA. You
no need switch to other tools. And this can save some
iterations.
3) Hold timing fix. We have run a few tests on Magma, almost
no design has hold timing violation which we spend most of
our time for ECO with Apollo.
Magma works for us."
- Hui Fu of Infineon
"We will be using PhysOpt for a 0.18 um tapeout within 6 months."
- an anon engineer
"We outsource layout. I'm intrigued by what I hear about Magma, but
I've also heard very good things about PhysOpt."
- Curt Beckmann of Rhapsody Networks
"We chose PhysOpt, and now we're living with the results. One area
that's giving us problems is tool integration. Data exchange isn't
particularly smooth, even among Synopsys' own tools. (e.g. Chip
Architect currently cannot create a DB on its own; it can only
update an existing DB with physical information.) But Synopsys is
pretty responsive, and we have a good apps engineer to help us."
- an anon engineer
"PhysOpt is the only interesting one, in my opinion, and we use it
with great success. And it's one of the main focus points for
Synopsys, right now, which means we'll see constant improvement."
- Oren Rubinstein of Nvidia
"These are new tools and so support is a very important. We will be
using PhysOpt as Synopsys has the best customer support. We don't
want to wait for a long time for the AEs to come and fix a problem."
- an anon engineer
"I'm using PhysOpt on my current project."
- Scott Fuller of Creative Labs
|
|