!!! "It's not a BUG, 
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / INDUSTRY GADFLY: "Cadence Shock and Awe"
_] [_
by John Cooley
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
You may remember a few months ago where I wrote about how three Intel
engineers beat me up for calling Cadence First Encounter a floorplanner.
Eng. #3: FE couldn't do abutted blocks on our chip. You had to have at
least one track between every block plus you had to then
do top level routing. Jupiter doesn't make us do this.
Eng. #2: RTL nerds like you, John, would trust FE's congestion maps. When
the design comes into a real backend tool, these congestion maps
don't correlate to what the FE play tool tells you.
Eng. #1: FE is great for prototyping, but it's an immature floorplanner.
Eng. #2: Yea, it's for quick and dirty feasiblity studies. It's not
complete nor legal. It's not for closing.
Eng. #1: Yea, it's not for signoff. Jupiter is.
- from http://www.deepchip.com/gadfly/gad072204.html
At the end of that column, I asked my Physical Design readers to speak up
about whether or not FE was a legit floorplanner.
Here are the results of that survey.
At first, I received 3 letters agreeing with the Intel guys:
We, too, were burned by FE during the development of our network
processor, probably 3 years ago now when the company was SiP. We used
FE expecting one thing and ended up with another. The major features
we expected to use were pin assignment/optimization, ability to handle
rectilinear blocks, constraint budgeting and wire buffering. What we
ended up with was a tremendous amount of effort to work around
deficiencies in each of the above features. Here are a few examples:
- busses were twizzled when routing from one block to another when
the blocks were not aligned in FE.
- rectilinear blocks were a joke in FE, first in the manner in which
they are handled (create a rectangle and then insert blockage
on the area outside the proposed rectilinear area), and in the
way the pins are optimized. Think of an inverted "L" shaped
design. The pins required to be optimized on the inside of the
verticle edge (where the blockage was added to create the
rectilinear shape) were instantiated on the verticle outside edge.
- FE constraint budgeting simply didn't work.
- wire buffering had to be hand-held in FE and constrained with
lengths instead of running with a true timing-driven solution.
Needless to say we used FE once and only once, and it sounds like FE
has not improved much since then.
- Brian Arnold of Vitesse
I come from an Astro (Apollo) background, so was much more familiar
with floorplanning in this environment. Currently I am using First
Encounter and Jupiter-XT and have had a reasonable amount of tim
to learn both.
First Encounter is a "Silicon Virtual Prototyper" with aspirations
to be a floorplanner (but not quite making it). Jupiter-XT is a
floorplanner with rapidly advancing skills in being a "Silicon
Virtual Prototyper".
For example I like FE's fast timing analysis and fast turn around
times. However, when you start to get to the nitty gritty of power
strapping etc. you can't beat being in a database environment that
you will do your final P&R in.
FE is fine for course floorplanning when you are deciding the aspect
ratio of your block etc. However, the timing in FE needs some
massaging (with cap multipliers) to make it get close to PrimeTime.
Jupiter-XT's timing analysis isn't as fast as FE's during my
investigations, but speed wise it is perfectly acceptable. I could
have easily done the prototyping work in Jupiter-XT, but used FE to
keep my skills up on both tools!
- [ An Anon Engineer ]
I currently use FE for prototyping capability, but for true production
worthy floorplanning I would prefer to have an alternative solution.
One that works as advertised, is extensible, and when it breaks you can
rely on getting it fixed quickly. I'm not saying that Jupiter-XT
would be my first choice.
- [ An Anon Engineer ]
Then I got 2 letters that were sort of rationalizing on the question:
Here's the deal... synthesis is a straightforward process. Place and
route is a straightforward process. Floorplanning is highly
subjective. That's why nobody has gotten it right (or, "right
according to my definition of right"). Ask 10 different engineers
from 10 different companies what the most important thing in a
floorplanner is, and you'll get 10 different answers. How is an
EDA company supposed to design a tool and mass market it, given that?
- Jeff Echtenkamp-Cho of Broadcom Corporation
The way I see it, FE and Jupiter-XT are both floorplanners and are
direct competitors. I don't see our company purchasing both tools
for the purpose of having a Prototyper and a Floorplanner. And I
don't see our team switching between two tools just to get a
floorplan done. Therefore, you would have to pick one, which IMHO
makes them competing in the same EDA niche. Ultimately, we couldn't
tape out without a floorplanner. In our case, we use Jupiter-XT.
- [ An Anon Engineer ]
Then there were the 6 letters that directly disagreed with the Intel guys
on a "detailed" technical basis -- which was a fancypants way of saying
that the Intel guys were obviously using an olde version of FE:
I have no experience with Jupiter XT, but have worked with recent
versions of Encounter (3.3_usr2) and Astro (2003.09-SP1-2). My
colleagues use Astro and sometimes Jupiter XT. Our recent design
would have taken too long to develop and maintain a complete floorplan
in Jupiter/Astro, given our late changes to RTL and constraints.
Encounter plus some custom TCL had the features we needed. Jupiter XT
may have worked, but we did not have sufficient time or access to it.
> Eng. #1: Whenever we took any FE Scheme commands to create ...
> ... What a mess. We wound up writing a Perl script to
> resequence FE's Scheme commands...
We used FE out to PDEF to PhysOpt to Astro, not the FE Scheme (tdf)
output to Astro. We did have to resolve library and flow issues, as
should be expected.
BTW, why not use Tcl instead of Perl for such scripting? Tcl is fast
and flexible, and is the language used in Encounter shell and now the
Astro shell. Oh, never mind, that's another debate.
> Eng. #2: The frustrating thing was that we didn't catch this until a
> month later because we stupidly trusted FE's internal rail
> analysis.
FE's rail analysis is approximate. Cadence says to use a detailed
rail analysis tool for tapeout, preferrably their VoltageStorm which
has some support from within Encounter.
> Eng. #3: We had problems with FE pin assignments across blocks ...
Our design was flat, so we did not use FE pin assignment.
> Eng. #1: We had keepouts and some constraints get lost when we ported
> the FE blocks to Astro and PhysOpt...
We had no problems like this.
> Eng. #3: FE couldn't do abutted blocks on our chip.
We did not use abutted blocks.
> Eng. #2: RTL nerds like you, John, would trust FE's congestion maps.
> When the design comes into a real backend tool, these
> congestion maps don't correlate to what the FE play
> tool tells you.
Congestion maps depend on the global router used. FE's is different
from Astro. FE's congestion map is to get you close, but you must
route the design to know for sure.
> Eng. #1: FE is great for prototyping, but it's an immature
floorplanner.
Encounter 3.3 has the primary features we needed, is solid and runs
very fast with less memory used. We've added some scripts to more
easily build and maintain a floorplan. It does relative placement of
macros, power and obstruction objects.
> Eng. #2: Yea, it's for quick and dirty feasiblity studies. It's not
> complete nor legal. It's not for closing.
> Eng. #1: Yea, it's not for signoff. Jupiter is.
It was legal for us. A late panic in our design led to many changes in
macro placement. In 4 hours with Encounter, I did the changes, updated
the power plan and regenerated the floorplan.
Later we a identified a database unit discrepancy between Encounter
and Astro. We had no time to change the db unit in Encounter and
regenerate the floorplan and placement. It was too difficult to make
all the changes in Astro. It took just a few hours to change the
placed PDEF in Encounter then read it correctly into Astro.
First Encounter is an effective floorplanner that is ready for prime
time.
- [ An Anon Engineer ]
Indeed, the capability of FE floorplan in older version, like FE 2.X,
did not meet our expectation. The quality of the old FE floorplanning
is only for prototyping, not for real tapeout. But current FE is both
a prototyping and a floorplanning tool.
- Yu-Wen Tsai of Faraday Technology
Regarding the Intel guy's missing power strap, you should never trust
the rail analysis result in FE if you are using Astro for your P&R.
The power straps you see in SOC/FE are not what you get in Astro.
(Astro re-created those power straps using the Scheme command from FE.)
We have been using FE as a floor planning tool for the last 2.5 yrs and
have taped out 3 successful chips. We used both SOCE (v04.10-p003_1)
and Astro (V-2004.06 for IA.32) for backend P&R. We have not looked
at the latest version of Jupiter XT because we are still very happy
with SOCE and have no plans to switch any time soon.
- Lee Li-Siang of Cortina Systems
We have been using Encounter flow for more than 3 years for production
tapeouts. We have not met these issues before, and FE's congestion
maps is real consistent with NanoRoute results.
From our past experience, First Encounter is both for prototyping and
floorplanning. In fact, we count on FE floorplans to make any early
adjustment, and the turnaround time is great.
- Liu Peng of Arca Technology Corp.
I imagine the Intel comments were likely based on evaluations of older
versions, as I certainly ran into similar issues over the past few
projects.
We had FE crashes due to constraints that the tool did not understand,
boundaries moving when we ran partitioning, power/signal pin shorts
during pin opt, bad budgeting, vias on power rails getting dropped,
pin alignment not working -- you name it. We worked closely with
Cadence support to resolve these issues in various releases of FE/Nano
over the past couple of years, and feel relatively comfortable with
the fixes.
Although we still see issues (particularly as we switch to new revs),
the volume of new issues has decreased, and our overall flow has
stabilized. Our last project was an abutted design, and we used an
internally developed flow to generate feedthroughs and push down clock
trees. Our current project is also an abutted floorplan, and we are
now exploring FE's capability to take over these tasks. In general,
whenever we have to implement anything in our design (floorplan or
otherwise), we first ask ourselves "Can we do this in FE?", because
it is the tool with which we are most comfortable, it is fast, and
capacity is generally not a blocking issue.
First Encounter is our primary floorplanner.
- [ An Anon Engineer ]
I think the Intel guys are a few years behind on the Encounter
technology, based on their description of it. It's incorrect to call
Encounter a floorplanner or a prototyper, as it has become much, much
bigger than that.
- Bobby Mozumder of DSM Pro Engineering, Inc.
But it was the 59 additional letters that formed a "Shock and Awe" campaign
that screamed that FE was more than a simple SVP tool:
I used SocEncounter in my previous company, taping out 4 chips
(1 with TSMC .13 and 3 with .18). First Encounter was used from gate
to GDSII. Virtuoso was used to clean up minor DRCs. The Encounter
used were 3.0/3.1/3.2-USR2. In my current job, we have just tapeout
an ultra low power chip with .13 lp using SocEncounter and Astro.
In this chip, Encounter was used for floorplan/placement/IPO/CTS.
Astro was used for routing. Encounter congestion map correlates very
well with the Astro routing result. The Astro version used is
2003.09-SP1. We did run into some minor problem when importing the
P/G scheme (converted from PDEF) in Astro. But this is not a real
issue to us.
In my opinion, Encounter is not only excellent in prototyping but also
a great tool for physical implementation. I like its speed, it's easy
to use and bottom-line, it gets the job done quickly. FE is a tool
for both new users and power users.
- [ An Anon Engineer ]
We have been using First Encounter since 5 years ago, even before
SPC merged with Cadence. For our experience, we used FE as both
a true prototyper and a floorplanner.
- Alan Hsu of Silicon Integrated Systems Corporation
It is certainly a floorplanner. We are using First Encounter for
almost a year, the main purpose of the tool in our flow is to create
a good and robust floorplan.
- Eli Assoolin of Transchip Israel
I am the physical design manager for Marvell. We do many tape-outs
(in the order of hundred) every year. We have used First Encounter
for floorplanning and prototyping, combined with Apollo for placement
and Wroute/NanoRoute for routing as our main flow since day one of
our group.
- Eugene Ye of Marvell Semiconductor
We use FE to do floor planning and prototyping both. The result is
quite useful and FE is very powerful. We already tape out some
chips using it.
- Ye Gang of Fujitsu Microelectronics Asia
I taped out recently I used FE v3.2 for floorplaning, place, clock tree
and IPO. I used Astro 2003.06 for signal routing and power rail
analysis. That flow worked well for the design aprox 1M gates as far
as I handled the design as flat. I like FE since it's very quick. I
would have used Synopsys PhysOpt for place instead of FE if my design
had been timing critical.
- [ An Anon Engineer ]
In my experience, there is no tool available to match the prototyping
capability of FE. We can turn (i.e. prototype) a large design in
several days from RTL to GDSII.
- Dean Arriens of Digeo, Inc.
We use FE for floorplanning and SVP.
- Shmulik Moshonov of Metalink Ltd.
We have been using FE as a protyping tool for our last few designs
extensively for freezing floorplans. We have found that the extremely
quick and efficient FE Prototyping methodology has been giving us good
results in arriving at the best possible floorplans for our designs.
- S. Rajesh of Centillium
We have used FE and NanoRoute for tapeout. The tapeout done internally
was 6 million gate (2 million instances) with 11 million bits of SRAM
on a 15 mm die with TSMC 0.13LV FSG technology. It has around 900
signal pins and uses a 1292 Flip Chip BGA package. We have silicon
back and the chips are working.
- [ An Anon Engineer ]
We use FE for floorplanning and SVP.
- Shiri Fridman of Oren Semiconductor Ltd.
Jupiter seems more user friendly, but for me I'm used to doing
floorplans with FE.
- Scart Chang of Global Unichip
We use FE extensively in a hierarchical (partitioned) design flow as
our primary cockpit for the entire layout from prototyping through
floorplanning, placement, optimization, routing and flattening
(re-assembly). FE certainly can't be ruled out as a floorplanner!
- Todd Houg of Micron Technology
We use FE for floorplanning, prototyping and physical design
implementation.
- Andy Le of Toshiba America
We use FE as a floorplanner.
- Lu HongDa of Motorola
First Encounter is a true floorplanner, in addition to prototyping.
In fact, I don't think these two features can be separated.
- Li Jun of Trident
Used SOC Encounter (SOCE) for our test chip 'Zephyr' in TSMC 0.13 um
G/FSG process. FE is our floorplanner.
- Jeff Khoo of Agilent
We have been using Cadence as P&R for tapeout projects for more than
3 years. We use First Encounter for floorplanning as well as
prototyping.
- Lewis Lai of Solomon Micro
We use FE to floorplan and SVP.
- Kwang-Hwae Kim of Samsung
We just use SOC Encounter to implement a 5M-gate design. For partition,
power planning, floorplan, pin assignment, and congestion estimation,
the flow is smooth and results are good and consistent with further
block detailed implementation. So I don't think FE is a prototyper
only but also a real sign-off quality floorplanner.
- [ An Anon Engineer ]
We handle hundreds of ASIC tape out every year. The majority of our
design service is from gate-level to GDSII. First Encounter is the
major floorplanner in our design flow. For timing optimization,
FE-OPT/PKS/PhysOpt/Magma(4.1) are candidates. Our golden router is
Cadence WRoute. RC extraction is relied on Cadence Nautilus. Our
major flow is based on Cadence product lines.
- Koan Huang of Faraday Technology
FE is being used extensively in our back-end design flow. The designs
which are being done consists of 300K - 400 K instances (around
1.5 million gate) in 90 nm technology. FE is a flooplanning and
prototying tool. I find the performance and capacity of the tool
to be really good and incredible fast run time.
- [ An Anon Engineer ]
The answer for your question is very clear to me. FE is, of course,
a floorplanning tool. We have been using FE for many tape outs.
- Liyi Lin of SiS
In 2002, we used FE (v02.20-P002_1) on a 8 millions gate chip to do
the floorplanning tasks. Today we continue to have FE (V3.3) as the
main floorplaning cockpit in our flow, moving on to 4.1 Reasonning
for choosing FE is quite simple. Floorplanning a hierarchical layout
includes partitionning, IO placement, partition shaping, placement
and sizing, macro positionning, pin optimisation, congestion handling,
feedthru insertion, power routing among other tasks. Basically
getting to the point where physical and timing constraints can be
pushed to the block designer with reasonable confidence blocks can
be implemented. Performing these tasks require global engines that
can run fast on a full chip, with the knowledge of the physical
hierarchy. (Full flat placement, global routing driven feedthru
insertion, full flat trial route, etc.) FE does just that for us.
- [ An Anon Engineer ]
We use FE for floorplanning and prototyping.
- Johannes Wang of Advanced Communication Devices Corp.
We are using First Encounter for past 5 years. We use FE as a
prototyper in early design phase and then finalize floorplan with
it as design progress, and also we use it as final placement.
We are using First Encounter and Nanoroute for P&R. We are not
using Jupitor-XT; FE is enough to do floorplanning.
- [ An Anon Engineer ]
We have been using FE for over a year in IBM and we are pretty happy
with its performance as a prototyping tool and as a floorplanning tool.
We have been using FE a lot in our COT flows. IBM has also started to
adopt FE as a floorplanning tool in its ASIC methodology also (along
with its internal PD tools) and we have seen many IBM ASIC customers
moving in this direction. These chips are pretty big and FE has been
very useful in partitioning these designs as well.
- Charudhattan Nagarajan of IBM Bangalore
And, of course, I had 4 Magma users and 1 Monterey employee whining that
this survey didn't include them -- they misunderstood that this wasn't
a who's-the-best-floorplanner survey but a question about whether or not
Cadence First Encounter has moved beyond its original SVP roots. One
partial perl of wisdom from a Magma user, though:
I think Magma users will want to use Blast Plan Pro for floorplanning
and virtual prototyping. Cadence users will use FE to do virtual
prototyping and floorplanning. Synopsys users will prefer Jupiter-XT
since it's a Milkyway-based tool, and Jupiter-XT now provides some
virtual prototyping features.
Floorplanning and prototyping are very tied to your layout tool.
- [ An Anon Engineer ]
Why I say it's a partial perl of wisdom is that I've seen way too many
Astro/FE users here for that "Synopsys users will prefer Jupiter-XT" part
to be true. It might become true eventually, but from where I see it
today, it's not true. Astro users today prefer to use FE.
So there you have it, folks. The PD Gods have spoken and First Encounter
is definitely no longer just a SVP tool; it's also the world's dominant
chip floorplanning tool.
-----
John Cooley runs the E-mail Synopsys Users Group (ESNUG), is a
contract ASIC designer, and loves hearing from engineers at
or (508) 429-4357.
|
|
