( ESNUG 421 Item 10 ) ------------------------------------------- [12/10/03]
Subject: ( ESNUG 420 #6 ) An Eval Of Magma Tools & 4 More Magma User Papers
> We all knew that the Magma tools performed well on flat designs, but at
> least 2 papers demonstrated there is also now a real hierarchical top down
> flow with BlastPlan or BlastPlan Pro. From the papers presented by Magma,
> the most surprising to me was the one about BlastCreate, the new Magma
> front end environment. Magma makes a very strong claim about run time,
> cell area, timing closure and tool capacity. It is always amusing and
> exciting to hear such comments. Is it real? I hope we could get comments
> of ESNUG readers about that claim.
>
> - Philippe Sarrazin
> Teradiant Networks
From: Mike Newman <mikenewman=user domain=airgonetworks spot calm>
Hi, John,
I use Magma's BlastFusion, BlastPlan and BlastNoise for Airgo's wireless
chips. Specifically, I used Magma to tape-out a full chip which was 5M
gates, 120 MHz, using Artisan 0.13um TSMC. Here are my unabashed thoughts
about Magma's tools as per Philippe's request.
BlastFusion & BlastPlan:
PROS
1. Most of my physical implementation and optimization flows and work can
be done in a single Magma environment and data model.
2. I created a Magma netlist-to-GDS flow from scratch and was able to do
the design hierarchically in less than 3 months from flow conception
to tape-out -- even though our design's netlist and timing constraints
were still very dynamic. This is a big change after years of having
to integrate multiple point tools, and iterate between analysis and
optimization tools.
3. The ECO flow was "fix eco", cell sizing & buffer insertions, including
wire sizing and spacing and noise driven post route optimizations.
ECOs based on point tool timing and noise verification were minimal.
4. Top level clock skew balancing between multiple clocks (Version 3.2)
worked well, although there are still some issues to work out in
the Magma supplied hierarchical optimization.
5. Full chip, one pass P&R w/ noise was 6 days from netlist-to-GDS.
6. Mtcl: It just takes a few lines of Mtcl to do what you need done.
7. Ability to work hierarchically via BlastPlan. We are seriously
considering BlastPlan Pro for hierarchy exploration to improve top
level optimization of both area and power reduction. We hope it
will help us address how logical hierarchy impacts yield and cost.
CONS
1. Only pin alignment was done with automation. Pin optimizations were
done manually to get the pins to the correct edges of the block. As
I understand it, pin optimization is available in version 4.0,
including assigning buses, net groups and pin optimization that is
virtually flat or global route-based. We need to evaluate it before
starting the next project.
2. Structural glass box memory image reduction was only around 60%. We
need 75% reduction to run top level on Linux boxes. Structural was
only used because of a "bug" in timing driven glassbox creating with
MUXed clocks.
3. The Magma power router had difficulties connecting pads to the core
ring, and rails to core ring. Their top level power implementation
requires manual interventions to be LVS/DRC clean and to pass point
tool power EM analysis. Again, Magma claims to have fixed this. We
will evaluate it.
4. Magma's clock latency estimates with Elmore were off as much as 30%
from AWE. This caused us to have to use fully routed glassboxed from
fix clock on at the top level.
So far, Magma has the most complete and functional toolset for standard
cell design that we've found commercially available.
BlastRail:
I'm currently evaluating Magma's BlastRail power planning & analysis, but
have yet to use it in a production environment.
PROS
I like Magma's approach to integrating of analysis and optimization via
an accessible data model resident in memory. I believe this will be
necessary as power constraints become more predominant.
CONS
I think Magma needs to add more functionality to optimize the power grid
with minimal guard band. Their power analysis will not only have to take
into account EM effect, but it will also have to be better integrated
with the delay calculator and static timing analysis engine in order to
take into account IR drop. It needs to ensure that any IR drop present
will not impact circuit reliability or functionality.
BlastCreate:
I'm about to eval BlastCreate (RTL-to-placed-Gates). I like their idea of
using BlastCreate as part of an RTL "what if" flow to give designers
quick feedback (minutes) on the "real" timing of their modules. Our RTL
logic designers need that quick feedback to come up with a flow that has no
timing interactions through the backend flow.
I don't have any comments yet on the actual usability of BlastCreate, tho,
as we are just beginning our eval on it.
- Mike Newman
Airgo Networks Palo Alto, CA
Editor's Note: On late Friday afternoon I'll add 4 more user papers
from the 2003 Magma User Group meeting as items #53, #54, #55, and #56
in the DeepChip.com downloads section. Happy reading, ya'll! - John
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 17,088 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
