( ESNUG 297 Item 12 ) --------------------------------------------- [7/30/98]
From: janick@qualis.com (Janick Bergeron)
Subject: A Review Of The Infamous Synopsys/Mentor "Reuse Methodology Manual"
Dear John,
At the recent DAC'98, Synopsys and Mentor created an awful lot of hype
around their so-called "Reuse Methodology Manual" (and I use that term
lightly!) Here's my completely biased review of their manual from the
perspective of someone who _actually_ has to do this stuff instead of
just selling the reuse concept to managers.
First the strengths: "Reuse Methodology Manual for System-on-a-Chip
Designs", which is jointly authored by Synopsys and Mentor Graphics, is
clear, concise and to the point. Keating & Bricaud propose valuable
guidelines and rules that can only improve any design methodology. The
book's main achievement is its promotion of a systematic approach to
specification, modeling, and verification in sections 2.3, and 4.2, and
chapters 7 and 11. These are integral activities in high-quality designs.
No longer should these important tasks be relegated to the end of the
project, to be done as time or schedule allows, or by junior engineers
because they are not the fun or sexy part of the design process. These
tasks are the most critical component of the designprocess, the ones that
ensure that the efforts spent on the design proper are not misdirected or
wasted.
The book's greatest failure is its unfulfilled promise to cover issues
faced by the user of reusable blocks. A single chapter (10) is devoted to
this much broader audience and presents little beyond what has already been
known from experience of using silicon-compiled memories. With Synopsys
and Mentor pushing reuse so strongly, why don't they have more to offer
to users of reuseable blocks?
Anyone who has followed the SNUG, VIUF, or IVC conferences for the past few
years, or has several years of experience designing ASICs using synthesis
and HDLs, will find familiar techniques, guidelines and rules outlined in
chapters 5 through 7. The book's contribution is to collect, consolidate,
and present all of the various sets of guidelines published in recent
years. It sins in making all guidelines very Design Compiler centric.
Verification techniques and testbench structures presented in chapter 7
concentrate on the stimulus half of the problem. The more difficult
component, the validation of the output, is briefly discussed in the very
weak section 7.2.4. This section describes a technique that relies on
comparison with a rarely available reference design.
Starting with section 4.3.1, little value is put in behavioral models. That
is an area where I passionately disagree. Behavioral models are a precious
enabler of system-level simulation, of parallel testbench development, and
provide an audit for the specification. Furthermore, a behavioral model of
a reusable macro could also be formidable marketing tool that would enable
customers to functionally integrate a macro into their design without
revealing implementation details or trade secrets.
The book puts a lot of emphasis on the RTL model (rightly so), but it goes
too far in recommending in section 7.3 that testbenches be written in RTL as
much as possible in some situations. The book should not dismiss in so
cavalier a fashion the powerfulness of behavioral models and testbenches.
Some sections in the book show some misconceptions of the VHDL/Verilog
languages. For example, in section 4.6.2, the authors recommend simulating
a macro on several simulators "particularly important for the
VHDL simulators". It is just as important for the Verilog simulators. The
text should mention the unspecified behaviors in the Verilog language that
make it inherently non-portable to various simulators (or to the same
simulator with different command-line options). Specific guidelines are
needed to make Verilog models portable, yet none are outlined in the
subsequent chapters.
Another example is in section 5.5.4 where the text mentions only the VHDL
signal assignment and the Verilog non-blocking assignment, but it fails to
mention the VHDL variable assignment and the Verilog blocking assignment.
In addition, the "poor style" example in section 5.5.6 is very poor: the
entire guideline is completely meaningless for VHDL. Assuming that the
synthesis tool is bug-free, it is impossible for the pre- and post-synthesis
simulation behavior to be different given the semantics of the VHDL language.
The whole guideline probably comes from a literal translation of a similar
guideline for Verilog in section 5.5.5.
There are a few contradictory statements and recommendations throughout the
book. For example, section 2.4 describes a linear design process just after
a spiral design process has been recommended in section 2.2. Another example
is the relative importance given to the macro and sub-block level
verification tasks. In section 4.4.1, very high verification requirements
are put on the sub-block design, yet section 7.2.1 states that the
sub-block testbenches tend to be ad hoc, with the entire chapter focused on
the macro-level verification. Ad hoc testbenches cannot achieve high
verification requirements. Solid verification can only be reached through a
formal verification process -- which is well described in chapter 7.
Readers interested in marketing and sales material should refer to sections
6.4 and 10.4 for Module Compiler. Those interested in VMC can refer to
section 8.6.1; those interested in CBA can read section 8.7. Formality is
the only formal verification tool mentioned in sections 4.6.2, 6.2.9, and
11.5.2 with no reference to the market-leading tools from Chrysalis.
InterHDL's linting tools receive honorable mentions in sections 4.4.2 and
6.2.8, but they are not given their proper due as to the value they can
bring to a design process. The text often implies that linting is an
after-thought activity. However, if linting is an ongoing, up-front
activity, then it will detect several problems in a few seconds without a
single simulation cycle being spent.
Throughout, the book provides an excellent description of the various tasks,
tools, and activities involved in completing today's complex ASIC designs,
from specification, to verification, and to implementation and physical
design. Every company should require any new hire or any engineer with less
than two years of experience to read this book. The investment is well worth
it. Managers and design leaders should also read it. These readers should
pay special attention to the section about specification and verification.
The book would benefit from the additions of rules and guidelines
specifically targeted toward design-for-testability using full scan or BIST
techniques and toward formal verification and static timing analysis to
eliminate gate-level simulation.
But as a book about reuse methodology, it falls short in two areas:
- First, most of the book is devoted to the producer or creator of
reusable blocks. Only one chapter is directly addressed to the users
and integrators of reusable blocks.
- Second, the book does not seem to present any new information that
would not be known to companies with a lot of experience in high-
quality HDL-based design.
For example, all of the concepts, rules, and guidelines presented in this
book are in use at a large, well known telecommunications company, yet they
have been struggling with the concept and mechanisms of design reuse for
years. To this day, very little design reuse happens there. On the other
hand, a small telecommunication component company is very successful at
design reuse because of a historical reuse strategy. Yet they lack modern
HDL design techniques, specification, or verification procedures.
Why then, if a company does everything the book recommends, can reuse fail to
happen? In contrast, how can a company be successful at reuse, while
breaking several of the rules and guidelines presented in the book? For the
user, non-technical, non-design issues must be addressed such as:
- What are the characteristics of an engineering culture that promotes
reuse?
- How do you reward for reuse?
- How should systems be designed to make maximum use of available blocks?
- What infrastructure is required to properly support reuse?
- How far should reuse be carried?
- How does a company protect itself from legal liability issues in an
externally sourced block?
Overall Conclusion: Excellent book, wrong title. A more appropriate title
would have been "Best-In Class ASIC Design Practices".
- Janick Bergeron
Qualis Design Corporation
P.S. John, I'm writing another longer, very detailed technical review to
discusses the design reuse ideas they proposed and how they clashed with our
real world experiences. (It's about 900 lines long. This review was ~150
lines.) Do you think your readers would be interested in it?
|
|
