( ESNUG 283 Item 4 ) ------------------------------------------------ [3/5/98]
Subject: ( ESNUG 275 #1 279 #3 280 #5) Even More "I Like Module Compiler!"
> 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?
>
> - [ A "CAD" At LSI Logic ]
From: Chris Rowen <rowen@tensilica.com>
Hi John,
Tensilica is funded venture working on high-performance IP for rapidly
growing volume markets. Our key systems customers care intensely about
five critical charateristics of design environment they may use:
* application performance - a combination of circuit-level performance and
architectural performance, measured by data throughput, power etc.
* portability - the opportunity to have the system-on-a-chip silicon built
in the most appropriate fabrication technology, as measured by cost,
performance and business terms
* adaptability to the task at hand - the opportunity to get all the
features they and no more in order to ensure optimal price
and performance.
* ease of integration - the opportunity to easily add value in hardware and
software along side the independently produced IP, and to validate the
whole system using the tools and methods with which the system design
teams are already familiar
* quality - confidence that the silicon and system produced will work as
expected on the tightest possible schedule.
We have evaluated Module Compiler as a possible key tool for use our
development. There are some key characteristics that make it attractive
for datapath-intensive IP:
* Standard Libraries: The fact that we get results, good results, from
off-the-shelf cell libraries is enormously important. Our customers get
the foundation for portability they demand, without a significant
sacrifice of performance. We resynthesize and tune each design against
a number of libraries in order to make sure we have robust micro-
architectures that will work well in a variety of different
configurations and processes.
* Turn-around time: We can take even a fairly large block (many tens of
thousands of gates) through the Module Compiler in less than 15 minutes.
This gives us unprecedented opportunity to tune the design in non-trivial
ways, making major architectural restructurings a thing of hours, not
weeks. In fact, the performance we get from improved architecture
probably far outweighs the possible circuit-level suboptimality of using
standard libraries.
* Uniform approach: We mix datapath and control arbitrarily, as needed by
the problem at hand. Module Compiler's excellent optimizations for
datapath structrues, especially adders, shifters and multipliers, means
that we get good circuits fast. More important yet, we find it pretty
easy to describe control functions in the same way, using
application-specific macros and pre-processing.Since all the interesting
critical paths run through both datapath and control logic we have a far
easier time finding and improving our logic when we synthesize as as
single unit. Any approach that requires a manual or even automatic cut
between datapath and control is likely to take too long, leave too many
optimization opportunities on the table, and lead to poor portability,
configurability and integratability.
* Conciseness: Module Compiler HDL lends itself to extremely concise,
readable, configurable, structurally-oriented logic descriptions. The
comparative clarity of representation means that one person can actually
understand a large unit, and that the number of logic bugs, even on
configurable designs, is reduced. We have done a couple of fairly large
prototype designs -- what would have been complete ICs only a few years
ago -- in less than 1000 lines of source code each. The comparative to
ease of writing and tuning this more concise code probably has saved us a
couple of months of development time versus conventional RTL coding and
implementation styles.
* Quality of Results - Module Compiler's sophsiticated datapath
optimizations are essential for the high-performance functions we're
implementing. We have had good success using Design Compiler as a
post-processor on Module Compiler output. While DC is too slow to
use in that rapid architectural exploration phase, it is so adept as a
peephole optimizer on MC output that it can still find a few
percent of critical path delay even on good circuits. The combination
turns out to be measurably and consistently better than either DC or MC
could do by itself on large complex mixed datapath/control units.
Module Compiler is not perfect, but to borrow Winston Churchill's comment
on democracy, it is can be said that Module Compiler is the worst form of
HDL tool except all the others that have been tried. ;-) Improved support
for floorplanning would clearly reduce uncertainty from statistical
wireload models. We would also like some better hooks for control logic
description, better UI and better reporting (especially for multiple
critical paths and false paths). MC has some very interesting hooks for
memory array integration -- these also need to be fleshed out and driven as
standards for RAM generators in order for Module Compiler to help full
realize the dream of portable/optimized IP.
- Chris Rowen
Tensilica, Inc.
---- ---- ---- ---- ---- ---- ----
From: "Kenneth Wagner" <kwagner@s3.com>
Dear John,
Just a short note as a first response to the great "Module Compiler" debate
you launched in the recent ESNUGs. The gentleman from LSI has written a
thought-provoking note. Unfortunately, I, too, have to weight in saying it
is quite unbalanced. He was highlighting perceived deficiencies while
making no attempt to recognize MC's advantages. Module Compiler, like ALL
tools, comes with caveats. They can be circumvented. The architects and
design engineers here at S3 used MC creatively and successfully for several
different purposes. Just my 2 cents.
- Ken Wagner
S3, Inc. Santa Clara, CA
|
|
