( ESNUG 431 Item 6 ) --------------------------------------------- [07/14/04]
From: JC Wang <jc.wang=user domain=broadcom spot calm>
Subject: Customer Does A Detailed Comparision Of Magma 3.2 and Magma 4.0
Hi John,
Our business unit completed a thorough evaluation of next generation P&R
tools two years ago. We used three difficult test cases, including one
for high-speed design. In the end, we decided to use Apollo for our
design at that time, and Blast Fusion for our next generation design. We
recently finished our first tape-out using Blast Fusion. It's 70 million
transistor at 0.13 micron. I wanted to share both the positive and the
negative part of our experience with your readers.
Blast Fusion strengths:
1. Timing closure. Blast Fusion delivered closed timing. Magma has a
fundamental advantage with their algorithm. Usually backend design
engineers have to "swallow" the frontend mistakes. For example, in
the front end, many inexperienced engineers would have DC add buffers
on clock trees or high fanout nets. Blast Fusion deletes all the
buffers in the beginning of physical design. Also, in DC, frontend
folks use wireload models to decide the driver strengths, with no
physical design information. Blast Fusion uses a "super cell"
concept to re-assign the cell driving strengths on the fly during
the cell placement.
2. Database openness. Magma's Volcano database is very open, which gives
the user more ability to access the database than going through old
Avanti Scheme files. In our case, we could write more Tcl scripts to
fix layout issues in the Volcano database.
3. Since Blast Fusion's timing correlation is close to PrimeTime and
there are minimum surprises, we trust the Magma reports. We compare
PrimeTime results to SPICE, and PrimeTime results don't always
correlate with SPICE, but Magma's timing reports correlate to the
PrimeTime results that do match SPICE.
4. Tcl interface. Magma uses TCL as their interface language and it is
much easier than Scheme. This makes it easier for people to start
using the tool right away.
5. Automatic antenna avoidance. We had no antenna problems within
the blocks because of Magma.
6. From a cost standpoint, Blast Fusion is cheaper than the other P&R
tools we have looked at. Magma overall has great technical support,
and they even gave us an on-site support person. A few Broadcom
folks actually stopped using Avanti's P&R due to support issues.
Blast Fusion gotchas:
1. Their router is not yet mature. Being a relatively new tool, their
router still has problems. For example, compared to the Astro router,
Magma's router still has some problems dealing with spacing and it
always leaves some DRC errors. We must interactively do manual fixes.
As the Magma router matures more, we expect that it will produce
better results with respect to DRC.
2. In order to meet setup time goals, Magma will intentionally skew the
clock. It creates a clock balance problem, although this is okay for
our design philosophy. However, we have questions as to whether Magma
guarantees it will work for blocks that are 20 to 50 million gates, as
it potentially requires a large hold time margin. The largest block
we have successfully implemented so far is over 2 M gates, and Magma
claims that other customers have verified it up to 5 M gates flat in
their new version 4.0. We must still evaluate if this is true for
ourselves though.
We had some additional issues during the design that Magma says are fixed
in version 4.0. We have not finished evaluating whether all these fixes
meet our needs. I wanted to raise these points, in case any of your
readers had the same issues in the earlier version.
1. Power. For Magma's version 3.2, their clock tree power was 100%
greater than that in Magma 4.0 based on what Sente reported.
Magma 3.2 used only H trees, compared to Magma 4.0, which also
supports cluster clock trees. When we estimate power using version
Magma 3.2 layout results, Magma had 20-25% worse power than our
estimation, which was based on our Apollo experience. This was fixed
in 4.0, and Blast Fusion's power results are now reasonable. With
Blast Fusion 4.0, we have validated that Blast Fusion's power results
are actually 20% better than Apollo. Again, this is based on Sente
analysis.
2. Some PrimeTime compatibility issues. Our designs are hierarchical,
and for hierarchical nets, Blast Fusion inserts a backslash so that
PrimeTime doesn't understand it. This could perhaps be a PrimeTime
bug. Additionally, Blast Fusion's design output couldn't feed to all
PrimeTime versions. PrimeTime is the industry standard and Magma must
support it. Magma claims full correlation with PrimeTime in 4.0; our
analysis team needs to verify if there are any remaining issues.
3. Verilog out issue. Blast Fusion had trouble outputting unique
floating nets. Though the connectivity was correct in the layout
database, there was a problem with outputting hierarchical Verilog
correctly. We caught the problems through formal verification and
fixed them by hand. It is critical that a physical design guarantees
the functionality, and Magma's AEs and R&D engineers have told us
that hierarchy maintenance has since been fixed in 4.0. We still
need to verify this important fix.
For our current design, we still used Apollo at the top level, and Blast
Fusion only at the block level. We plan to evaluate Blast Plan at the
top level, since we want to work with only one database. We had looked
at First Encounter, but decided that First Encounter is for novice
designers, not power users. We have a monster chip! Additionally, our
design was channel-less so we need to line up the pins, for minimum
connection. This feature is part of Magma's floorplanning tool Blast Plan,
not Blast Fusion, so we are now testing the pin assignment and pin
refinement in Blast Plan.
Our internal goal is to turn around a layout block in less than 24 hours.
While among the other issues I mentioned, Blast Fusion's router was not
mature, Blast Fusion's timing closure was good and the final result was
that our team was still able to meet the physical design turnaround time
for most of the layout blocks that we did with Blast Fusion. We plan to
continue to use it for our next design, and, as I mentioned above, we are
also looking into Blast Plan.
- JC Wang
Broadcom San Jose, CA
|
|
