( DAC 02 Item 14 ) ---------------------------------------------- [ 9/10/02 ]
Subject: Cadence PKS & First Encounter
MONEY CAN BUY YOU LOVE: What a difference a year can make. Last year at
DAC Cadence marketing was desperately trying to convince customers that
they were doing extremely well in the physical synthesis race, that PKS was
"winning technology benchmarks" everywhere, and that Integration Ensemble
was coming any time soon and it would wow everyone. The problem was that
in reality, Cadence was falling flat on it's face here, until Cadence did
what it's truely good at.
Since day one with the Gateway aquisition, Cadence's corporate culture has
been: "Cadence. When the going gets tough, the tough go shopping." And
a shopping they went. With an apparently undrainable check book, Cadence
bought CadMos, Simplex, Plato, and most importanty the wildly popular
Silicon Perspectives. It's that Silicon Perspectives purchase that turned
what appeared to be a large-but-sinking "we've-had-a-nice-run" Cadence, into
a very serious 2nd place contender to Synopsys in the physical synthesis
horse race. First Encounter is a really good floorplanning tool with an
almost fanatical user base. Cadence marketing has been trying to hitch any
and every other Cadence tool it can to First Encounter to tap into that user
enthusiam. "XYZ? Yes, we have that, but it's new and improved and we now
call it XYZ Encounter..."
Now the big challenge at Cadence marketing has been in trying to convince
users that PKS is good enough and that at any place where PKS falls down,
the blessed First Encounter tool will jump in and fix things. PKS isn't
quite there yet. Currently PKS still has less than 100 estimated user
tape-outs (compared to PhysOpt's 1,200 user tape-outs) and 4 months ago:
"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 (from SNUG 02 #15)
What's interesting now (4 months later) is that eleven PKS users responded
to my DAC Trip Report survey. They're talking real bug talk issues. It's
*not* the usual cleaned-up-by-Cadence-marketing "success stories". This
means that at least some users are actually using PKS for real chips now.
"SPC is the winner but it is not integrated very well with Cadence PKS."
- William Lam of Tvia
"Finally Oki has been mulling on moving the backend to a complete
hierarchical backend flow. We are currently evaluating Silicon
Perspective as a prototyping and chip assembly tool."
- Syed Ahmed of Oki Semiconductor
"Cadence PKS combined with First Encounter seems like a good fit. We
plan on checking it out. We will wait and see to see how Synopsys
integrates PhysOpt with its Avanti tools."
- [ An Anon Engineer ]
"Obviously, SPC is the winner. With the integration into a potential
standard DB, it will only becoming more dominant."
- Weikai Sun of Volterra
"Now that Cadence owns First Encounter it'll be interesting to see if
they bundle it so tightly with other Cadence tools that they may
eliminate First Encounter as a plausible choice for anyone who isn't
using a Cadence-only design flow. If Cadence winds up making that
easy mistake, or if they emphasize marketing over continued technology
development within First Encounter, then it'll help clear the field
for tools like Icinergy's SOCarchitect."
- Mike Carter of Idirect
"Synopsys PhysOpt is certainly my 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 another 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 can not trust my $30M to $40M design project with
a new methodology.
Silicon Perspective certainly has the edge in floorplanning. As far
as integration with Cadence, I am not sure if they will work it out.
Typically when Cadence buys the best technology company after 1 year,
they are probably in the 2nd or 3rd. Same thing happened when I was
a design engineer at Sun, we helped develop Pearl. The minute Cadence
bought Pearl, PathMill and PrimeTime took over the market.
I do believe Monterey Aristo offer a good methodology for block-level,
but it will be ONLY a point tool."
- [ An Anon Engineer ]
"First Encounter was very impressive in our evaluation, and our back-end
people want it. But it was fairly expensive and is getting moreso now
with the Cadence premium tacked on. FE may be easier to use in a COT
than an ASIC flow, because ASIC vendors are dragging their feet to
support it."
- John Busco of Brocade Communications
"We don't use any of this directly. Our back-end vendor is starting
to use Cadence PKS and has used SPC FE on some blocks, but not to
any great advantage yet."
- [ An Anon Engineer ]
"We are also looking at Cadence and Avanti, but it looks like Cadence is
not there yet for crosstalk aware routing (which is a big item for me.)
Their SOC Encounter looks like a great floorplanning tool. It can
traverse the hierarchy to solve the hierarchical pin placement problem.
This would be a huge help."
- Cordell Prater of Prairie Communications
"We have tried IC Wizard and First Encounter for breaking up our designs
but they didn't do what we wanted. We are continuing to evaluate these
and Hidden Dragon / Floorplan Compiler. We are using a home brew flow.
Our designs don't have clear 3rd party IP blocks. Channel routing
might be good for those but I think it is a potential problem area if
you have high speed signals comminicating between blocks. If you
channel route high speed signals you really need SI analysis."
- John Webster of Intel
"Using First Encounter is a pleasant experience. It is super fast and
very intuitive. The quality of the results is reasonable. Its data
compatibility with other EDA (and even Cadence) tools is still rough.
You can not use it to tape out your design, but FE gives you great
insights in the early stage of the design. Cadence purchased many
good products before and didn't get the full benefit from them for
various reasons. I hope First Encounter can be different."
- [ An Anon Engineer ]
"We have used Cadence PKS tool since March 2001 and gone through 5
tape-outs. Here is my thought.
1) We like PKS graphic interface and its Tcl-based language.
2) The integrated static timing engine of PKS is actually very
convenient though in the beginning we were not used to it.
3) The CT-PKS clock tree synthesis is our bottleneck. We spent
a lot of time in getting it to work right.
4) The PKS location-based wirload model is accurate enough. The
test results from our silicons are always better than report
from the Ambit static timing.
5) We've achieved first silicon success in the last tape-out
using PKS. The other 4 we had to respin. The test on silicon
(TSMC 0.13 um process) shows no logic errors from 500 MHz to
5.25 GHz bit rate. The design is 100 K gates mixed-signal.
6) Silicon Ensemble routing tool which comes with the SE-PKS package
is hard to use, especially in routing power grid. I happen to
have the Cell3 P&R background and thus manage to use it without
great difficulty.
7) There was a steep learning curse for using PKS. It is not as easy
as Cadence advertised. I think that this is because the PKS method
tries to integrate synthesis, clock tree generation, static timing
and place route in one flow.
8) Hierarchical floorplanning is the weakness of PKS flow. We managed
to use the outdated Preview to work with PKS. Cadence understand
this problem very well. It is why Cadence acquires SPC.
We have good experience with PKS despite some issues listed above."
- Jim Hsu of Rambus
"PKS and PhysOpt gets similar results. Sequence PhysicalStudio is good
for some type of designs. For 90 nm process, physical synthesis
getting tougher. With coupling cap dominant, unless synthesis has
final route complete, otherwise timing will not be accurate. SPC is
currently our top level floorplan and pin optimization tool. So far
so good."
- Wenhua Zhao of Fujitsu
"We have at the moment two chips already in silicon done with a Cadence
PKS flow (Philips SAA6714B and SAA6740). You can add them to your
physical synthesis tape out list. And another one will be taped out
in week 44 of this year.
Floorplanners: We will have a closer look at First Encounter. In
general I have a feeling that you need to have such kind of tools
for complex designs (and short time to market) in the future."
- Raimund Soenning of Philips
"Monterey: promising technology, but Monterey got in touch with us too
late for the current generation (0.13) evaluation. Aristo is a solid
floorplanning tool and I am sure they have good technology. Maybe a
good candidate the next time around.
Magma: snappy marketing pitch. Me thinks too snappy. Poor follow
through -- no results demonstrated in benchmarks, always one excuse or
the other followed by VP level meetings. Final result, sayonara...
Don't call us, Magma, we'll call you.
Synopsys PhysOpt: Results sound promising but they could not support
gate array flow. Support and evaluation had too many strings attached.
(Classical Teutonic Synopsys) No Clock tree generation capability.
Doubtful links to downstream routers and SI tools. Huge price tag upto
US $350K/seat of Physical Compiler. Result: benchmark inconclusive,
call us again later.
Avanti: We had several Avanti tools in house. With the exception of
Star-RCXT which is an EXCEPTIONAL tool, 2 years (< 5 bugs), Avanti
support sucks BIGTIME. It's like dealing with an organization with
a collective bipolar personality when it comes to support. Irrational
and illogical. P&R tools require extensive support and Oki did not
need any additional migranes so Avanti NEED NOT APPLY.
Cadence: Cadence has its ups and downs, but they bend over backwards
to support us. Gate Ensemble and their SLC flow was satisfactory but
not great. PKS was surprisingly good and with good links to downstream
routers. It gave us good results without an additional HUGE investment
(Oki has a multi-year Cadence remix agreement) & the results of PKS 4.0
were good (though sometimes flakey). With PKS 5.0 Cadence finally had
a product with a working clock tree generator (and good heterogeneous
clocking schemes.) We have currently taped out 3 designs in 0.16/0.22u
technologies (Designs 1-4 M gate with timing around 200-250Mhz.) We
are currently working on 2 more tapeouts. Oki typically tapes out
40-50 designs a year and PKS is a standard methodology for 0.16/0.22.
PKS is on probably on par with Synopsys PhysOpt. (Incidentally we
use the Synopsys DC - PKS flow.) A comparative analysis between Ambit
and Design Compiler has shown that Ambit is 4x faster with the same
quality of results. But Oki has still decided to stick with Synopsys
DC because of a huge customer base and consistently proven quality.
PKS strengths: Good timing closure. Improved Clock tree generation
(useful skew reduction has been multifold). Strong links to SI tools.
Decent scan chain reordering and cross talk prevention.
PKS weakness: Hier clock tree generation (seems Silicon Perspective
has one.) Weak floorplanning / chip assembly capability (again SE has
this) and needs a better router (PLATO probably solves this)."
- Syed Ahmed of Oki Semiconductor
"Magma:
1.) Magma solution does not support or provide interface to other
leading third party tool sets, such as Simplex, CadMos & so on.
2.) Magma routing technology and it's strength is in question.
3.) Obtaining a competitive die size is also very challenging, if not
impossible with Magma.
Monterey:
1.) Placement engine can not place JTAG cells seamlessly. One needs
to get the R&D involved.
2.) Lack of customer base.
3.) Gate Level floor planning engine is very weak and complex.
4.) It creates syntactically incorrect Verilog netlists.
Due to these issues, I stopped my evaluation of Monterey, hence, I
do not have any data on the rest of its flow.
Synopsys PhysOpt:
1.) Lack of integration to a routing engine. Obtaining a routable
and timing closed design can be very challenging because of this.
Avanti Astro:
At the time, I started using PKS, and Astro was not released yet.
Cadence PKS:
If you're good in writing scripts, more specifically synthesis scripts,
then you would not have any issues using PKS. PKS is best utilized in
scripting mode, than GUI mode. The difficult piece about PKS is having
too many commands with too many options to choose from. If you are
able to define a working flow "script", then you are pretty much set.
Doing this, I have timing closure in the 1 to 4 weeks time frame.
The only gotcha that could create issues that I've found are if 60% or
more of your design is macro blocks."
- Romeo Kharileh of Valence Semiconductors
"Our company lives off the funds of investors. We're a start-up. We
are now 18 people. One person (me) does the synthesis, P&R and
physical verification job.
When we chose PKS, we were looking for an EDA vendor who could provide
a physical synthesis tool and a strong support team to support a small
start-up like ours. Therefore we selected Synopsys and Cadence. We
didn't select Avanti because their tools were too expensive. The final
cost made us chose Cadence PKS as PhysOpt was much more expensive.
Our design is 800k instances with more than 100 RAMs. The clock is
below 100 Mhz. We decided to do this design flat to save silicon area,
time and to reduce the EDA tool cost. It was a chalenge at the time
we started the design since PKS 3.0 couldn't handle this size of
database. We were happy to see PKS 4.0 in June 2001 because it is able
to run in 64-bit mode and so to handle large databases.
The PKS 4.0 "datapath" option was not really an option for us since our
design would have been 30% bigger without it. With datapath, our size
was comparable to what we could get with Synopsys PhysOpt.
We gave up trying to use the low-power option in PKS 4.0. It was buggy
and anyway to heavy to setup (activity of each net...) I haven't tried
the low-power option of PKS 5.0 yet.
It took us quite a long time to setup the PKS 4.0 flow because of the
workarounds we had to find for the bugs and also because the tool was
not mature enough.
To go from a final netlist to the last step done by PKS, took 1 month.
I did two ECOs within this time, so it was not bad for an 800 k
instance design. I had a hard time managing the database because of
its size but the timing optimization was not realy hard since the
frequency of our design was below 100 Mhz.
When you load a database in PKS, the first "report_timings" command
takes about 30 minutes. The following "report_timings" takes 1 to 5
minutes, but if you change a timing constant or if you change the
operating conditions then it takes 30 minutes again for the next
"report_timings" to work.
Generaly speaking every PKS database query/management is rather slow
compared to First Encounter. More over, some features like placement
and global routing don't run on the PKS DB, but on other databases
so PKS needs to do database transfers. This is transparent for the
user but it seriously effects your PKS memory and runtime. Our average
UNIX process size ranged from 5 Gb to 11 Gb.
PKS did quite a nice job except for the Clocktree. The PKS tool for
clocktree generation "CT-PKS" is behind PhysOpt. That's why we chosed
the First Encounter clocktree generation tool for our tapeout. That
clocktree is 6 times smaller than what CT-PKS generated.
The GUI is between OK and good except for the physical part for which
PKS is less than average. It did improve in PKS 5.0.
Although we had a lot of problems, we were happy to be able to generate
a flat placed and globally routed netlist from PKS. At the time we did
this first tapeout with PKS, Synopsys told us PhysOpt couldn't have
handle such a database size. That was 10 months ago. Now I use
PKS 5.0, but I don't use its new features yet."
- [ An Anon Engineer ]
"When you prototype RTL for feasibility with PKS, you get fairly
accurate estimates of where your timing will be (compared to PhysOpt's
synthesis followed by a placement and buffering). Final chip synthesis
is a straight forward process, as opposed to many iterations.
I guess it boils down the fact that I would rather trust a backend
company that has added synthesis knowledge to the tools, than to trust
a synthesis company that has added backend features. The Avanti merger
will be interesting if Synopsys can work out the partnership, but I
suspect it will be many years before it is seamless.
What's good with PKS:
- integrated sign-off timing within PKS. (Save the hassles of
changing tools.)
- low-power synthesis options. (Found about 30% power savings
for one signal processing design.)
- arithmetic circuits are quite good. (It generates a multiplier
that matches hand optimized booth recoded multipliers.)
Problems in PKS:
- the PKS clocktree tool is primitive. It also doesn't report back
any diagnostics. It simply stays idle until the clocktree is
done 6 hours later.
- still need to use SE to generate floorplans. It will be much
better once Cadence fully integrates all of SE functions in
the PKS tcl framework.
To date we have 4 tapeouts with the PKS. For the first tapeout, we
synthesized the design with Synopsys DC, and then fed the netlist into
PKS for optimization and placement. (The only reason was a time
deadline, and we had legacy Synopsys scripts.) The 3 remaining
tapeouts were completely done with PKS from RTL-to-GDS. All designs
between 100 k - 400 k effective gates, in 0.18um technology.
We didn't look at Magma or Dolphin. Neither of them were mature enough
in our opinion to pursue."
- Dave Garrett of Bell Labs Research Australia
"I used PhysOpt with my previous employer, and am using PKS with my
current employer. I am currently using PKS 4.0.15. I expect to rev to
the PKS 5.0 release soon, but am waiting on some OS patches. I have
been using PKS for about 6 weeks.
I had used PhysOpt rev. 2000.11 and then 2001.08. I used PhysOpt up
until September of 2001. I had been using it for about 1 year as my
previous employer was a beta-partner with Synopsys.
I guess the gist of my response is:
- Both tools seem to provide good performance and select appropriate
logic and placement.
- PKS is easy to set up and use. File exchange with other tools
(ie. First Encounter, SE) is easy. PhysOpt was a bit more
involved and required more Makefile scripting to ease the
generation of the required files (def2pdef, generating plib,
etc.). PKS uses the same LEFs/DEFs as SE and First Encounter.
I expect the Synopsys/Avanti merger to ease the front-to-back
integration issues between the chip-level floorplanner and
block-level synthesis.
- I prefer the options and degree of control PhysOpt provides. I
find PKS to be a bit too much of a "close your eyes and pray"
approach. Basically, I think PhysOpt has a wider toolset that the
user can use to converge for timing and congestion. I think PKS
seems like a bit more of a canned approach, which is fine if it
works, but leaves you beating your head against the wall if it
doesn't. Perhaps this is just because I have more experience with
dc_shell and psyn_shell.
- PhysOpt seems to offer more switches for congestion vs. timing
based placement.
- I like the PhysOpt scan insertion methodology better. I like
having seperate commands for scan insertion and I find it more
configurable.
- I think I should be able to do detailed routing in PKS.
Generally speaking John, I'm pretty happy so far with PKS. However, I
haven't had a chance to run it on larger design blocks, so I don't know
what the run times & timing results will look like compared to PhysOpt.
Also, I stopped using Physical Compiler before it incorporated clock
tree synthesis and routing, so I cannot comment on the comparitive
performance."
- Norman Stewart of Vixs Systems
"I think Cadence shot themselves in the foot with regards to First
Encounter. FE was a very good tool standalone that had great promise.
Cadence marketing put the death-curse on the tool by packaging it with
other Cadence features that weren't useful to anyone using it as a
standalone products and then hiking the price to cover all of the
extra additions. We bought and used FE standalone specifically because
we don't have Cadence back-end tools and required the intelligent
floorplanning abilities. Now we don't use any Cadence products
including FE."
- [ An Anon Engineer ]
"I attended a single Cadence demo that talked about the First Encounter
design planning tool they got when they acquired Silicon Perspective,
the CeltIC signal integrity tool they got when they bought CadMOS and
the Nanoroute router they got when they acquired Plato. Note that they
had also announced their intention of buying Simplex, but at DAC it was
like some cell that's been surrounded by an amoeba but not yet
digested.
It is hard to interpret this mass of acquisitions as anything less than
an indictment of Cadence R&D. In any event, if they have a problem
they are addressing it. All of these tools are at least pretty good
and I think in the case of Simplex very good (I'm not as familiar with
the other tools). They called First Encounter, CeltIC and Nanoroute
together "Silicon Encounter". I'm concerned this may be a(nother?)
case of Cadence calling a bunch of point tools by one name in order to
imply they are some sort of integrated system. Some people have
characterized Cadence back end tools as being loosely integrated point
tools with a bunch of finicky translators and a circuitous flow that
has seemed clumsy compared to Avanti or Magma tools.
Anyway, the Cadence demos sounded very good. They say their First
Encounter design planner has great correlation with your final
parasitics; they say 95% of the nets are within 10% of your final RC
numbers. If that's true it's remarkable given how fast the extraction
engine works; one of my guys is doing an evaluation on it and says you
barely have time to get coffee while it's doing extraction. The tool
does IR drop analysis (using a different engine than SE-PKS) but needs
Cadence wavetable models, which are painful to create given the current
GUI-only tool (un-scriptable) used to create them. It can do either
peak analysis or a guesstimated average analysis using statistical
methods."
- John Weiland of Intrinsix
"We have been using SE-PKS in production flow and taped out more than a
dozen chips since 2001. Basically the flow is smooth now. We can
complete the optimization to routing in a whole run. We are actively
using it to tapeout our timing driven projects (from 0.35um to 0.18um.)
Synopsys refused our evalution in 2000. They said they didn't support
it except for the big 15-16 customers then. Not to mention we're in
Taiwan. Actually Cadence asked us to bring our cases to the U.S. (in
super taxi mode) and let their core comp AE to run for us. We refused
the proposal and Cadence came on-site to support our eval. Cadence's
full support was the key to our adoption of PKS. We chose Cadence as
we think support is the same weight with tool quality. Synopsys is
always 'selling' things. Recently Synopsys was trying VERY hard to get
our attention to their PhysOpt+Apollo flow. We're now evaluating that
flow, too. (Not because PKS is not good. We want 2 flows here.)
The good and bad of PKS:
Good: RTL synthesis, optimization, STA, clock tree synthesis,
placement, global route in one shell. Smooth flow without
data exchange. Smaller area count than Synopsys DC/PhysOpt
in almost every case.
Bad : Weak in achieving better timing than Synopsys DC/PhysOpt. If
we need higher frequency design, we have to use PhysOpt
although our overall area will increase. PKS is also weak in
clock tree (CT-PKS) synthesis. Slow and sometimes not good in
skew control and buffer numbers. Cadence said their BuildGates
Extreme can compete with DC+DesignWare. We are still waiting
for the benchmark now.
Comparing between PKS and PhysOpt:
Basically these 2 flows are almost the same but PhysOpt+Apollo flow
needs several data exchange between PhysOpt and Apollo. We are not
comfortable with this situation. We have seen PKS is not able to
achieve good timing in some critical designs. We simply use DC to
synthesize datapath parts and insert the netlist into whole chip
which was compiled with Ambit/PKS. Combines the best of 2 tools.
PKS 5.0.2 is under testing now. Initial results show BuildGates
Extreme did a good job in achieving better timing than DC 2002.05 so
I expect it can achieve better result than PhysOpt, too. But
DC 2002.05 runs faster than Ambit. Haven't tested PKS and PhysOpt.
ClockTree in PKS (CT-PKS) is weak, too. Slow and QoR is sometimes not
acceptable. We used ClockWise as an alternative. PhysOpt is weak in
handling already-inserted scan chains and spare cells handling is
weak, too.
We're still benchmarking PhysOpt 2002.05 vs SE-PKS 5.0.2 although in
the end, we plan to have both flows running."
- J.S. Yang of Sunplus
"We used PKS for physical synthesis. Timing correlation was in 3-5%
range. Our main issue is related to the fact that depending on the
step being run in PKS, its vision of the database is not the same,
therefore some PKS functions are not available for optimization and
require a new iteration.
We also tried PhysOpt, and honestly, got similar results (this was done
directly by Synopsys guys, so we lost some time for constraints
description and learning.)
We have not tried nor considered Monterey. We spent some time looking
at Magma. Integrated solution and found it interesting in our next
future. We sub-contract our physical design to Cadence, and we have
a full Cadence solution."
- Ange Aznar of Tachys Technologies
"We're evaluating First Encounter in Texas, and we expect to start
evaluating Floorplan Compiler soon. But if it's like Clocktree
Compiler (which I just evaluated) Floorplan Compiler may not be truly
ready. Might be alot better when the August release of these tools
comes out."
- Mark Wroblewski of Cirrus Logic
|
|
