( ESNUG 280 Item 5 ) ------------------------------------------------ [2/12/98]
Subject: ( ESNUG 275 #1 279 #3 ) Wait A Minute! I Like Module Compiler!
From: "Jean-Didier Allegrucci" <jda@alpinesemi.com>
Hi, John,
As an "expert" user of Module Compiler (MC), I felt obligated to respond to
this obviously biased opinion about MC from [ A "CAD" At LSI Logic ]. I've
also been using Design Compiler for the past 10 years with great success.
> From: [ A "CAD" At LSI Logic ]
>
> To twist an infamous quote from a former EDA CEO -- if Synopsys put
> "DogFood Compiler" on the market, would users be sending ESNUG
> testimonials about how tasty the gravy bits are?
>
> Module Compiler used to be the SciArc Datapath internal tool. Even though
> Synopsys bought SciArc & is trying to reposition them as a Design Reuse/IP
> vendor, deep down they really truly want to be the "standard" ASIC vendor.
> This is the old EDA vs. ASIC CAD argument with a twist. Do you think that
> Synopsys really wants us independent consultants & ASIC vendors adding our
> value to silicon; when they have the opportunity to make everybody produce
> the same lousy gates in all designs using Synopsys tools, IP, & designers?
I guess some people will never get the idea. It's always the same trade-off
situation between optimized solution and time to market. You can design for
3 years and get a really efficient design while missing the window of
market opportunity for the product or you can come out with a sub-optimal
but still decent solution ahead of everybody and cash-in. It's up to you to
decide, but any successful company knows what the answer is. Maybe this is
why tools like Synopsys are so popular. It shrinks your design cycle time
by a significant amount, and if you spend the time learning how to
efficiently use it, the result you get is pretty good. But then again, some
people will still be entering schematics 10 years from now.
> Libraries
> ----------
> Library support is always important for new tools - for datapath tools
> this is even more critical. Any of us who have done datapath designs
> know that you absolutely need custom cells in-context optimized for
> speed/density. Hell - us real designers don't even use standard cells,
> we design the whole chip at the transistor level for breakfast. So how
> can this crowd of talented custom designers be drooling over Module
> Compiler, when it uses the same lousy standard cell libraries that
> Design Compiler uses?
Obviously you've never tried MC. I find your comments as an insulting.
But, Hey, LSI Logic knows better. In my previous company, Silicon Graphics,
several designers, including myself, evaluated the tool for 6 months, and we
came to the conclusion that it was years ahead of any other similar tools
on the market. This is why we opted to purchase many licenses right away.
It was targeted for multi-million gates design with speed equivalent to
today's processors.
> Here at LSI Logic we have an entire world of custom circuit engineers -
> your whole chip can be built with custom libraries if you want. I have
> lost track of how many customer specific libraries have come through
> this shop. Of course we will charge you massive NRE and long cycle
> times to do this. But hey, we figure that you know that custom IC
> design is 2-3x faster/smaller than what everyone else gets in the
> standard library - so you must figure the time and money is worth it.
Like I've already said, while your optimizing your design and spending all
this money on a circuit team, I'll be producing my second design on the
latest technology available.
> After a while I got tired of seeing yet another multiplier or adder
> cellset from yet another guy who read yet another conference paper.
By using MC, you do not get yet another multipler or adder, you get a
customized datapath element that fits your design. You can manipulate
the structure of the adder depending on your needs and it also take into
account the arrival time of each of the bits independently. How many
parameterized netlists would you need to do this? A lot! Why waste time
creating a library when you can get it in no time. As for multipliers you
can control the partial product generation, the reduction tree and the
final adder stage. Hell, you don't want to use the final adder stage
because you want to merge the output of the reduction tree with some
other logic if you don't have to! You have total control. Of course, you
need to understand how it works. The best results from any tools are
obtained when you spend the time to understand how they work and how
you can take advantage of the features.
I'm not taking about designing high-performance micro-processors where
every ps is important, I'm taking about everything else where you need
reasonnable speed and area that can comes within 10-20% of a full-custom
design but with only 50-75% of the design time.
> Why not put these same circuits guys to work building a datapath
> library that everyone can use? The only way to do this was to write
> parameterized netlist/placement generators to control the cell usage -
> this way everyone can get the same custom IC result with a lot less
> time and money. The problem was to fit this into the standard EDA/ASIC
> flow, so that you would use it. We could wait around for Synopsys to
> realize that every ASIC vendor wants to have their own datapath
> libraries tied into Design Compiler or we could do something else...
How about pipelining? Can you build a library of adders with all the
possible pipelining situations? I doubt it. It would take you more time
then you have left to live. What is your solution for this? Twenty
circuit designers?
> Conclusion
> ----------
> TeraPath supports the standard synthesizable RTL that fits into the ASIC
> based sign-off flow, and does not change your use of RTL formal/functional
> /accelerated verification tools in any way. Tera Systems also supports
> standard library/placement interfaces that automate the gate-level
> implementations that LSI Logic's custom designers have previously been doing
> manually. Many of us here at LSI Logic find the marriage of standard top
> down design with custom bottom up physical design to be the coolest thing.
>
> I have used TeraPath's RTL-based module-level logical/physical synthesis
> for a while now on datapaths. I can routinely do designs by myself
> several orders-of-magnitude faster than the custom-design teams, and yet
> achieve equivalent or better results. Finally datapath design is not
> limited to expensive side projects using niche tools that do not fit in
> well with the rest of the design flow.
>
> - [ A "CAD" At LSI Logic ]
No, the conclusion is, if you do not want to waste your time or lose your
shirt in a full-custom adventure, try out MC and see for yourself. Also,
Terapath obviously requires some special libraries, while MC uses libraries
already available today.
- Jean-Didier Allegrucci
Alpine Semiconductors
---- ---- ---- ---- ---- ---- ----
From: adrianj@ondoline.engr.sgi.com (Adrian Jeday)
John,
I was reading (ESNUG 279 Item 3) and soon realized that it was just another
manifesto (yawn) praising yet another new tool. I have nothing against new
EDA tools but I just want to mention a few words about my experience with
Synopsys Module Compiler.
I have been using Module Compiler since its early days (known back then as
SiArc's DataPath Architect) to build fast arithmetic and various data paths
structures. Something that Design Compiler was not, in my experience, very
good at achieving.
The tool has improved a great deal since then and has become an indispensable
part of my design flow. MC has been a great help in getting the best
performance out of my arithmetic structures (short of hand-designing it
gate-by-gate). In addition, it's great for analyzing precision vs.
gate-count trade-offs early in the design phase.
So why am I rambling on about Module Compiler? No, I'm not employed by an
EDA vendor nor do I own Synopsys stock. I just want to give my two cents
before somebody else bashes the tool. I was very skeptical about this tool,
but after several successful deep sub-micron designs, I think it's a great
addition to any CAD tool set.
- Adrian Jeday
Silicon Graphics
---- ---- ---- ---- ---- ---- ----
From: Tony Young <youngt@comspc.geg.mot.com>
Hello John,
I've used module compiler at a couple of sites and I have to say that I
have been impressed with the results. I not sure that comparison
to a datapath compiler is quite an apple to apple comparison. Many of the
comments from "CAD at LSI" apply to design compiler, not module compiler.
Module compiler has the ability to create an "on the fly" logic structure
that will collapse arithmetic operations into wallace trees as needed to
meet timing. A statement that contains several adds and multiplies along with
other arithmetic operations will be collapsed into a single element.
Outputs of arithmetic operations can be saved in carry-save format. This
is extremely powerful. Add to this automatic pipelining and ability to
add pipelines as need to align outputs from sources with different latency
and you have a very powerful architectural tradeoff machine. Not to mention
the speed of output. I've seen 2hr 15mins on design compiler reduced to
2.5 minutes (no error, i said minutes) in module compiler. That is netlist,
reports, and behavioral RTL.
I understand some of the reasons for the new language. How do you write
a 5 input multiply operation in VHDL or verilog and have an output that is
in carry-save format without it being a gate level netlist or some complex
RTL. I dont like the fact that there is another language, but I can see
why one was created. I certainly would not wish to limit myself to a less
robust design because of my language preferences. I like the idea that I
can code this on one line of code rather than instantiate wallace trees
and such.
MC will build a custom design for you that takes into account the time that
the inputs arrive and build accordingly. This may mean that an adder is
part ripple and part CLA or fast CLA. Parts built on a demand basis! How
about a 7 input multiplier that takes the most critical input into account
and builds a custom design on demand, and then pipelines it to a 3ns cycle,
if you wish. It doesn't require that a 7 input multiplier exist in a
library. What if you wish to sum another input to the output of the
multiplier. Just tell the multiplier to stay in carry-save format (that
means its smaller also, no adder is built at the end of the multipler) and
then build an adder that accepts carry-save input all "on-the-fly". And
then pipeline them all and make sure that the output aligns to another path
that has a latency of 14 or so. Think of all the tradeoffs that I could do
early in the design (at breakfast). What if some other design from another
designer has to change the input latency to my design. I can be up and
running with a new design, with a newly designed multiplier/adder/FIR
filter/whatever (with pipeling in the middle of all the gates) before the
cereal bowl can be put away.
As far as the placement issue is concerned, Im sure they are looking at a
solution, isn't everyone??? How many layout tools are trying to do IPO or
some equivalent. And how many synthesis tools are taking a hard look at
layout issues. And look at who bought who to gain technology. MC works in
a different area, architectural tradeoffs and collapsing of functions. I
can create a much better design in the area that it works in than I could
even touch with design compiler.
And if the wire-load isn't accurate (they can't be, its just an average of
all nets in the scope of things) then choose an optimistic one that will
allow you to get the results you need. Fix errors in IPO or REOPT with the
real parasitics back annotated. Don't pre-buffer the design, post-buffer it
only where you need to.
Is there a better solution to the wire load? Look at the REOPT solution in
Design Compiler. Estimates wire on a net by net basis as well as placement
to meet timing. Takes a lot of computing power on a large REOPT, but the
approach is interesting. It can't be done on the whole design, but it will
certainly help get a few NS back from a "almost there" design.
Timing driven layout will place the most critical cells together if it does
a decent job, datapath layout will do an even better job. All the layout
tools are looking at or announcing datapath extraction from RTL or GATES
coupled to layout. You're better off to focus on creating a design that
can meet critical path constraints during layout and then fix all the paths
that had initial slack but were placed futher apart due to their less
critical requirement. These non-critical paths have room for additional
buffering or upsizing. Getting the critical path designed is the most
important up front issue.
Datapath layout will help, but its just as important to start with a better
design. MC will help in that arena and improvements are all I ask.
- Tony Young
Motorola
---- ---- ---- ---- ---- ---- ----
From: "Bob Prevett" <prevett@nvidia.com>
Hey, John,
That guy from LSI Logic is way off the mark. In an ASIC design environment
where time to market is top priority, Module Compiler is *THE* tool to use
for arithmetic pipeline designs. It allows for very fast architectural
exploration and early convergence on an optimal design solution. While at
Silicon Graphics doing 3-D graphics chip design, the team's use of MC helped
to cut months off the design cycle. ( We're using it for the same reasons
here at NVidia.) And given a good P&R tool, the resulting density of the
physical design was real good as were the MC-generated datapaths. The tool
fit very well into SGI's standard ASIC RTL/synthesis design flow.
When that LSI guy said "Hell -- us real designers don't even use standard
cells, we design the whole chip at the transistor level for breakfast.",
I had to laugh. As a "real designer", I would rather spend my time
developing innovative architectures quickly and getting them market as fast
as possible. And that's what MC allows a designer to do for arithmetic
intensive designs.
- Bob Prevett
NVidia
|
|
