( ESNUG 451 Item 9 ) -------------------------------------------- [02/08/06]
Subject: ( ESNUG 446 #11 ) Magma Blast PlanPro replacing Synopsys Jupiter
> FE has come a long way from being only a pure stand-alone SVP tool to
> doing more floorplanning tasks like IO planning and power routing. It
> already had hierarchy planning features and within the SOC framework
> it has been integrated to work with a variety of Cadence back-end tools.
>
> Synopsys Jupiter was the established product in all the floorplanning
> tasks I listed above (prior to the advent of hierarchy planning).
> However, Jupiter has not scaled very well for hierarchical planning of
> large designs, and only recently has Synopsys been able to claim to have
> a competing solution in this space.
>
> You need to include Magma's Blast PlanPro product in this discussion also,
> as our experience with Blast PlanPro has been very positive. It has all
> the key capabilities present in the other two tools, plus some unique
> benefits since it is totally integrated with Blast Fusion (which we are
> using as our implementation tool).
>
> The advantages of a fully integrated Blast PlanPro <-> Blast Fusion
> are substantial as they share the same user interface, same language
> interface (via TCL), same native functions/algorithms, and use a common
> Volcano database. Given the increasing popularity of Blast Fusion as an
> implementation tool, I would expect these advantages will quickly force
> Blast PlanPro into this discussion.
>
> - [ Bender from Futurama ]
From: Jeff Echtenkamp <echtenka=user domain=broadcom spot calm>
Hi, John,
A set of comments on this post. We've been Blast Fusion users for 5 years
now, and only recently started using Blast Plan. The reason for this is
not because it didn't work, it was just a matter of priority. (We were
still using Planet/Jupiter since before Fusion we were Apollo users.)
Anyways, about 18 months ago I started looking at Blast Plan. The key point
here being, as your reader noted, we are Blast Fusion users. We do alot of
coding, and using a Planet/Fusion flow required us to write 2 sets of the
same code many times. In addition, support for Planet/Jupiter at times
seemed non-existant. These issues became such a large burden we decided to
look at Blast Plan (but not eval Jupiter XT or FE for comparison). We did
look a little into the competition, and going through the features that
mattered to us, we didn't really see any serious "missing bullets", so we
figured, we'll pound on Blast Plan, and if it works as promised, we'd use
it. Anyways, February 2005 we had our first Blast Plan tapeout (working
silicon), and will be taping out 2 more chips in the next month.
You ask 10 chip layout engineers what they want from a floorplanner, and
you'll get 10 answers. So I'll tell you my needs. My group designs
settop boxes. We have a LOT of IP reuse (at a high level, reconfigurable
soft IP cores), and have had this as long as I've worked here (8 years).
Our design methodology is very reuse centric. As such, we have spent a lot
of time coming up with a "correct by construction" methodology, to eliminate
things like top-level crosstalk, timing budgetting, etc. As a floorplanner,
our big goal is "figure out the pieces of the puzzle"... aka physically fit
the design in as small of a form factor as possible. (soft block placement
and sizing, pin assignment, congestion analysis, etc)
Our flow with Blast Plan was to start out using "empty box" floorplanning,
and then as the IP cores became available, switch to a virtual flat
methodology (first unregioned, then regioned). (This is one of the gotchas
of virtual flat... you gotta have a netlist which binds and has enough of
the blocks close to give useful results.) The reasons for doing this were
to aid in soft macro sizing/placement and then pin assignment. (Our old
Jupiter flow used empty box exclusively, and led to many iterations due to
"my block is unroutable".) Our flow also used a home-grown "semi-abutment"
flow. We then did a very fast prototype of each block before handoff, to
catch gross errors (no timing... figured it's too much to ask the chip
person to look at timing for every block, so only looked at utilization
and congestion).
I could probably write a book on what all we learned and the tweaks we
did to get correlation between chip and block level. In the end, we got
pretty decent results, but it was a lot of work. (Fortunately, we've
shown the methodology we came up with was something we could apply
directly to future chips.) The other nice thing we saw once things
correlated, was that it enabled the chip floorplanner to see block level
issues, and to fix the problem, not the symptom. We often saw problems
before we handed the floorplan off (as a matter of fact, our first chip
had no major floorplan iterations due to block implementation issues...
not bad considering our old Jupiter flow typically scheduled at least
1 week for this.)
I think the other thing that is worth mentioning pretty strongly is
Magma's programming interface. As I said before, we write alot of code
in my group. I wouldn't even want to "count the lines" of the code in
our flow... in general, their TCL interface allowed us to do alot of
things in an efficent and repeatible manner which we couldn't have done
in Milkyway. The drawback was in my opinion, at times we were required
to do this too much... while its a benefit to have a strong programming
language to help you work around bugs or missing features in the tool,
one would prefer not to have to do this type of coding. (Examples: in
the end, I wrote my own padring router, as we couldn't get Magma's to
work reliably. They also have no TCL-based custom router, only GUI
based... we have alot of analog nets in our SOCs, and this feature is a
must. While its cool to say I wrote a TCL-based custom router, its also
sad to say that... it's even sadder to say that 2 years after we brought
up the lack of this basic feature to them, it still does not appear to
have been addressed, and I haven't heard any Magma roadmap to lead me to
believe I can retire my code in any timeframe.) What I've noticed in
rolling out my flow is, in the backend world there are 2 frames of mind,
the people who are more efficient with a GUI and the people who are more
efficient writing code. The people who are code writers love Blast Plan.
The people who are GUI people, tend to like Jupiter. Obviously, I love
Blast Plan. :)
Power routing was probably the biggest nightmare of Blast Plan. We only
have one layer for PG and a lot of analog, and as a result, we don't have
this nice square 2 layer PG mesh every floorplanner thinks you have. As
I mentioned, Fusion had no TCL-based custom router. Well, our PG is so
random that it is in some spaces alot of custom routes. This was also
difficult in Planet (mainly Planet gave us too many false violations).
But in Blast PlanPro, we had issues with getting our mesh drawn, getting
adequate vias dropped, and getting the nets slotted. They are improving,
but it still isn't the prettiest. On the slotting, Fusion's big issue is
they don't attempt to determine current flow direction, and sometimes slot
incorrectly drawing routes that would violate EM. It was annoying, but to
put it in perspective, it was still useable. Apollo's slotter was so bad
we didn't even try to call it.
Magma pin placement is also an area of concern for us. (Planet would
probably rate a "D" at this.) There were numerous issues we encountered.
The biggest thing we saw, was to get a good pin assignment using a virtual
flat placement, it means first off, your placement has to be right. Then
your routing has to be right. Then your pin assignment has to be right.
We found that roughly 80% of the work to get a good pin placement was to
get a good virtual flat placement, where the cells connecting to your top
level net were near where the pin would eventually be. If you didn't have
this, you were screwed. We were able to do some tweaking to get better
results. But our feeling was there are alot of things which eventually
need to be folded into the Magma placer itself. For example, if I put a
pin constraint on a design, the placer needs to respect this, as does the
router. In Blast PlanPro, only the pin placer honors these constraints,
so its screwed before its even given a chance. Another good example is if
I put a spacing rule on a pin, the Magma global router should adhere to
this. Likewise, if I put a spacing rule on a net, the pin assigner should
respect this. Additionally, their empty-box flyline based pin assignment
was overly simplistic and often yielded bad results. We were able to come
up with our own hack to help out. Their pin assigner also works on a block
by block basis, rather than a net by net basis, so you can often get pins
that don't line up perfectly between abutting blocks. Their error recovery
methods (for example, when it wants to put more pins on a side of a block
than can fit) often don't respond gracefully. Other "nice to have" features
were also missing, like being able to constrain pins on rectilinear blocks
and grouping bus pins together.
Anyways, I said I gave Planet a "D", I'd probably give Blast PlanPro a "C+".
It's not great, but I think short/medium term, we'll be able to work with
them (and with our own code), to get this in the "B" range.
For chip assembly, Magma's router was very nice (vs Apollo). The quarter
grid routing allowed us to use alot of variable width/spacing rules on our
top level nets much more efficiently than we could with Apollo. The Magma
router was also much faster and more memory efficient than Apollo. The
other nice thing we saw was their DRC/LVS engine correlated much closer
with Calibre than Apollo. Apollo tended to give us so many false flags,
it was hard to look at a report. In our first chip, we were able to get
Blast Fusion to report us as DRC clean. (Ended up with under 10 real errors
on first Calibre run, which were tracked down to 2 systematic issues with
their abstract representation... by our 2nd Calibre run we were clean.)
In the end, I guess, every tool has its bugs. That's why we engineers
get paid alot of money... (right, if the tools worked we would be out of
a job). So let me try to quantify what we saw:
1) Our chip taped out, and came back working.
2) One good metric of a chip is controlable density (basically, the area
of the standard cells versus the area of "placeable area"... aka chip
area minus pads/memory/analog.) Using this metric, this chip was the
densest SOC my business unit has taped out since we tracked data. By
several percent. This was our first chip, and we saw positive results.
(Typically for us, it takes about 2-3 chips to see positive return on
investment in many cases... to iron things out, build up experience,
eliminate bugs, etc.)
3) The flow we developed has shown to be reproducable on 2 more chips
4) Floorplan iterations due to block-level implementation issues, were
greatly reduced versus our old flow.
So in general, I'd say we were pretty happy. It could have been better.
But I felt it was a step forward for us. I think over time, we'll see
things improve, as more of our engineers become familiar with the Magma
tools and our internal code base improves. Unlike AVNT/SNPS, Magma does
seem to have some people actively working on this tool, and we are seeing
progress. Of course, we'll always say its too slow. :) But as I see it,
they provide me a nice canvas and set of paints on which I can draw my art.
- Jeff Echtenkamp
Broadcom Corporation Irvine, CA
Index
Next->Item
|
|
