( SNUG 01 Item 12 ) -------------------------------------------- [ 3/28/01 ]
Subject: Physical Compiler (PhysOpt) vs. Cadence PKS vs. Magma BlastFusion
ONE LEAK: OK, so Aart was pummelled by customers for not making any of his
usual 4 or 5 technology leaks in his SNUG Keynote. In general, these
customers were right. Aart didn't leak much -- but he did sublty leak
something:
"In the future, you will be able to compile timing delays due
to crosstalk."
- Aart de Geus, CEO of Synopsys
Knowing that crosstalk can have a big impact on timing below 0.18, this
means that the delay calculations in PhysOpt are going to take crosstalk
into consideration. This means a much better QoR for PhysOpt.
Chip Arch games and tea leave reading with Aart aside, PhysOpt enjoys a
strong lead role in the physical synthesis horse race. Physical Compiler
enjoys (at least) 65 verified customer tape-outs and Cadence PKS demos
devote a lot of time comparing themselves to PhysOpt. (Tells you who
Cadence sees is leading.) Rajeev has serious credibility problems with
his so-called "25" Magma tape-outs. And nobody's mentioned the word
Monterey even once. PhysOpt is in a sweet position as it fits nicely into
the standard Design Compiler flow. "It's just a few new commands" sells
a lot easier than a new flow with a new GUI and God knows who helping you
run the tool. Also the level of customer banter about PhysOpt and Chip
Architect and (to a lessor degree) FlexRoute in ESNUG, clearly indicates
that lots of people are actually buying and *using* Synopsys physical
synthesis tools.
"PhysOpt fits easily in a Synopsys flow. I will have a try on it
(they promised testing licenses). I do not see the use of FlexRoute
or Chip Architect."
- Klaus Vongehr of Philips Semiconductors
"Physical Compiler (or a similar tool :-) is the way of the future, but
I have one major request from Synopsys: to provide free "demo"
licenses, the way they do with DesignWare-Foundation. In demo mode,
PhysOpt should do everything it normally does, except saving the
placement information.
That would allow us, the users, to finally get rid of wire load models.
Without spending an extra half a million per seat, of course. Even the
most optimistic sales rep in Synopsys can't believe that will ever
happen.
In the good old days, it used to be "if Design Compiler can synthesize
with no violations, the layout can be made to meet timing as well".
And Design Compiler was more than a synthesizer, it was the feasibility
proof as well. I want to be in that situation again, and I'm hoping
Synopsys might like to get that role back."
- Oren Rubinstein of Nvidia
"I think PhysOpt should have an advantage over PKS because it uses the
native Synopsys constraints and should have consistent modeling and
timing. PKS & Magma have a whole set of timing correlation issues."
- an anon engineer
"Physical Compiler -
They have added several new switches to PhysOpt including a scan
reordering capability, an ECO mode, and power optimization capability.
PhysOpt can do scan reordering which we have always avoided, but might
be worth looking into as a routability improvement PhysOpt will also
do power optimization simultaneously with timing optimization which
may prove important in our next generation. Both Synopsys and three
Intel engineers are reporting better timing results with RTL-to-Gates
versus Gates-to-Placed-Gates approach although they claim the
improvements are design dependent. The cost of doing RTL-to-Gates
with PhysOpt is considerably more than doing it with DC because of the
considerable difference in the cost of the licenses and the number of
licenses we have for both.
Cadence PKS -
I also talked to the Cadence PKS experts & expressed my disappointment
at the lack of support we got on our initial evaluation of PKS. I've
heard that LSI Logic concluded that PKS did a better job than PhysOpt.
Since we are looking at IBM again, I invited Cadence to help us take a
second look at PKS. One of the main advantages I see now with PKS is
they maintain the hierarchy of the design and do not require
uniquification. Our biggest problem with the current Physical Compiler
process is that it has not been able to totally close on timing yet, so
we still need to do a fair amount of placement work. When we need to
make a logic change after doing the physical work, we have no way of
doing it incrementally. If we could maintain the hierarchy we could
probably use our retain_name program to bring in an incremental change
late in the game."
- Ken Merryman of Unisys
"I benchmarked PhysOpt and got excellent results. I am very happy about
it. I don't see the usefulness of Chip Architect. FlexRoute... Hmmm.
Cannot comment as I haven't used it.
Something very fishy is going on at Synopsys w.r.t. the Clock Tree
Synthesis in Physical Compiler. I asked the question about it last
year and Aart said "Its the top priority and it will be release by
December". This year I asked the same question and got the same
answer. At the R&D night, none of the Synopsys engineers could give me
a clear answer. Is Aart hiding something??"
- Himanshu Bhatnagar of Conexant
"1) Physical Compiler may not be that disruptive to our flow after all.
Synopsys has always represented Physical Compiler as the next evolution
of synthesis. Input RTL, output placed gates. But many presenters
on the subject of Physical Compiler actually used it in a gates-to-gates
mode, and it worked well. Although most thought they would have gotten
"even better" results doing RTL-to-gates, the gates-to-gates flow
was good enough for what had been tough timiing closure problems.
The upshot is that clearly Physical Compiler can be thought of as
a synthesis-aware placement tool as well as a placement-aware synthesis
tool. What this means to us is that PC may not cause the sort of
disruption in the flow that I had been assuming, or at least that the
disruption can be held off for a few more years. In the short term,
we may find that simply substituting PC for existing placement tools
is enough, without changing our flow.
In fact, given PhysOpt's rumored high price, this may well be the
standard model for years to come. We synthesize a netlist, and the
vendor (or COT team) uses PhysOpt & our timing scripts for placement.
2) We need to start paying close attention to where we MUX clocks.
The need for accurate top-level (or at least top-of-hardmacro level)
timing scripts is growing and growing. Design Compiler's capacity
is improving, and tools like Physical Compiler and various
timing-driven placement tools will require accurate timing contraints
at high levels of the chip.
This is a real problem for us. None of these tools can propagate more
than one clock to any given flip-flop. Thus, clock MUXes (which abound
in our designs!) are a real problem. We currently get around this
problem by doing synthesis at a low level (below the clock MUXes), then
running PrimeTime at the top in multiple passes. Physical Compiler and
timing-driven placers need to see the WHOLE timing problem in ONE PASS.
We will need to pay more attention to how and where we MUX clocks in
the future."
- Paul Zimmer of Cisco Systems
"I read some postings on ESNUG referring to the difficulty of using
Apollo as the backend to Synopsys Physical Compiler. We are
particularly having trouble reading PDEF 3.0 into Apollo and we have
tried the various methods that have been suggested (pdef2adb and
Scheme scripts). Do you have any additional information on this?"
- Scott Marvenko, Department of Defense [ This problem was
fixed in ESNUG 367. ]
"One interesting fact from user papers at EuroSNUG on PhysOpt was
that most customers use it in a gates2placedgates mode. It wasn't used
as compiler at all, but more as a timing-driven placer. Only a few
users have fully replaced DC with PhysOpt until now, though you can
get ~10% better results when starting at RTL instead of a netlist.
I guess, Synopsys is pretty much aware of the threat by all those
RTL2GDSII companies."
- Lars Rzymianowicz, University of Mannheim, Germany
"Walter Tuck (from Infineon, San Jose) and I are using the PhysOpt
RTL-to-Placed-Gates flow on a 450 Kgate block (upper two-digits
MHz frequency) in a 1.1 Mgate datacom ASIC. 0.25
That block has very critical area and congestion issues. After
having a lots of problems with PhysOpt 1.21 (fatals, out-of-memory,
no high fanout nets fixing) we now see much better results with
PhysOpt 2.0. Timing fixing, DRC fixing, congestion removal and
scan chain stitching/reordering work pretty well now. Convergence
in the Avant! Apollo backend flow looks like it's going to happen."
- Johann Bechteler of Siemens AG (Germany)
"Synopsys really seems to be on the right track with PhysOpt. I think,
however, that which physical synthesis tool you choose is still tied
to which logic synthesis tool you like best. I mean, if you don't
like what Ambit does then you aren't going to choose PKS. Still,
Synopsys is throwing stuff together and their inexperience in the back
end flows is a concern. The bottleneck is still the place and route
tools. These tools are not yet sophisticated enough to properly handle
0.18 micron (and below) design rules and parasitic problems. You can
loop through a physical synthesis flow until you are old and gray and
still not get it clean if you are actually pushing the technology.
Magma still scares me. Too many claims for too few people over too
short a time."
- Grego Sanguinetti of Accelerant Networks
"Session PhysOpt: Physical Synthesis
Of course this is Synopsys' big push to get us all to buy their
new physical synthesis tool. A magical solution to take you from
RTL to a chip all in one tool. Of course they don't have detail
routing, or clock tree synthesis (yet).
Several user papers were clearly invited from around the world
to discuss physical synthesis. It certainly seems that to use these
tools you have to be much more integrated into the back end flow.
You need a floor plan, you need your macros stuck somewhere, you need
to know where you want your pins. PhysOpt takes your block and
doesn't need any wireload models at all. It just compiles it,
optimizes, places the gates. You also need a floorplanning tool
to figure everything out, then there's the power grid, gettin the
power pins mapped out, figuring out from the top level where the
subblock pins should be, the challenges of physical hierarchy getting
routes scribbled all over it and if you make that exist in your
logical hierarchy.
My basic feeling coming out was that PhysOpt was very cool, and I want
to avoid using it as long as possible. That may not be best for
the chips we make, but it certainly lets me concentrate on designing
scopes instead of chips.
One thing is clear: they've got a lot of customers buying (or at least
trying) this product.
- Paul Gerlach of Tektronix
Another very telling PhysOpt event happened during the "Synopsys R&D Night"
part of this SNUG. During this time we're all put in a big hall with lined
by 18 tables staffed with Synopsys R&D engineers. As usual, for the first
30 minutes, all the customers collected around the food and open bar in the
center of the room. Once fed, though, over 60% of the customers in the hall
crowded 3 deep around the 4 Synopsys physical synthesis R&D tables. The
remaining 40 percent were divided amoung the 14 other Synopsys product R&D
tables. A very telling event.
|
|
