( ESNUG 299 Item 6 ) ---------------------------------------------- [9/21/98]
Subject: ( ESNUG 298 #1 ) The Synopsys/Mentor "Reuse Methodology Manual"
> Overall Conclusion: Excellent book, wrong title. A more appropriate title
> would have been "Best-In Class ASIC Design Practices".
>
> - Janick Bergeron
> Qualis Design Corporation
From: Yatin Trivedi <trivedi@seva.com>
John,
First the good news -
The book is actually readable. It is written for engineers, not English
majors. Each chapter starts with a good overview of the topic at hand,
provides a good "glossary" type overview of terms.
There are a lot of flow diagrams in the book. In most places, the diagrams
make the reading and understanding the surrounding text a lot easier. An
exception is figure 2-3, system-on-a-chip design flow, that could use
at least another page worth of explanation such as how those vertical
partitions interact with the horizontal ones and what are the problems that
possibly get addressed (causing inward spiral) at these points.
If you are willing to forget words like "reuse", "IP", etc. and just
remember ASIC, HDL-based design methodology, functional verification,
structured design practices, etc., you will get more out of the book.
Otherwise, you will spend more time looking for the relevant topics and
getting to those few pages than actually reading the text.
In other words, if you have taken a course such as "Intro to VLSI Design"
or "CMOS Design 101", read this book to get the "Big Picture". A good
book to review the night before the interview, specially if you are
interviewing with a large company. Good chances that the design, synthesis,
and verification tasks are carried out very close to what the book says.
So your interviewer is likely to find you "ready to jump in, feet first".
If you can recall Methodology Notes that came out in early 90s, most of the
guidelines were already known to most readers. If you have been designing
with DC for sometime, you have read these guidelines, used them yourself,
seen them being used, recommended to use, and felt the unbearable pain when
you or someone on your team didn't follow them properly. Some of us also
had/have the privilege to teach it and discuss it and take sides with (or
against) it.
If I are a Synopsys sales person, I would give 100 free copies of this book
to each engineer so that his/her bookshelf has no place to keep any other
books that contained a design flow that is feasible with other (superior??)
commercial tools.
Ah, so I must have started drifting towards the criticism ....
Let's see, how many of the Mentor's IP acquisitions (excuse me, Inventra)
have rewritten their models (or plan to) based on these recommended
guidelines? Practicing what you preach may be a good start.
I don't think there was any mention of PLI in the book (OK, maybe a passing
reference), yet a bulk of Logic Modeling components are PLI based (for
Verilog users). Should we count them out as "Unsafe Sex?"
I would also be curious to know how many of the leading IP (soft and/or
hard) vendors actually carry out the guidelines and methods suggested
/recommended in the book? I (and others at Seva) have had the (sometimes
unpleasant) pleasure of being at the receiving end of the IP spectrum:
integrating and verifying. The book, with its less than 10 pages devoted to
this end, certainly falls short. After using 5 or 6 different IPs from
different vendors on different projects, I can't even tell you that I know
the golden rules. All I can tell you is that the woodpecker proverb means a
lot to me ("If we built the society the way we build software, the first
woodpecker to come along our way will destroy the whole civilization.")
Yes, the macros work standalone and conceptually we the buyers believe that
we can integrate and verify the whole system and be happy ever after. But
Toto, we are not in Kansas anymore. It is a lot more than connecting the
ports and passing/overriding parameters on an instance to integrate the
macros in our systems. All sorts of issues ranging from initialization and
register/signal accessibility to testbenches and debug process become severe
bottlenecks. Integration of multiple IP blocks, possibly not from the same
vendor, is no trivial matter. Sometimes, you have to run three different
license daemons just so that you can integrate these models ... who needs
lawyers?
OK, so I digress into a soapbox talk.
Most of Chapter 5, RTL Coding Guidelines, can be found in HDL compiler
manual or other HDL books. A good job on Basic Coding Practices section,
however. We have written custom "checker" tools for these sorts of things.
Seeing a compilation is one place makes me very happy. In 5.2.11, port maps
and generic maps, the book recommends use of explicit mapping for ports and
generics (parameters for Verilog). The Verilog part of example 5-7,
unfortunately, must use unnamed parameter passing (for the purists, module
instance parameter value assignment) because HDL Compiler does not accept
the named association (defparam) construct. The example shows port
connection by name and silently skips the parameter association.
Section 5.5.5, blocking and non-blocking assignment, missed one of the
important guideline that the two types of assignments should not be mixed
for assignment to the same register. (i.e. a = b + 1 ; and a <= c - 1;)
Later on, section 5.5.8, coding state machines, has a guideline about
creating enumerated type (in VHDL) for state vector, and using `define in
Verilog. The example, 5-36, turns around and uses parameter [1:0] ...
Although the example shows the *real* preferred method, the use of bit range
for parameter declaration is an illegal syntax (see IEEE 1364-1995, section
3.10, page 25).
The testbench chapter (Macro verification) is interesting, but weak. More
talk than real substance. Chapters 10-13 are nothing more than a cursory
overview, a rather disappointing search for the real substance.
A question for Kluwer Publishers: did you get this book reviewed "by peers"
who were not employed by Synopsys and Mentor? and no one objected to the
blatant marketing/sales push for the tools? Or maybe the standards and
considerations have changed and I missed my calling ... There *IS* a
difference between a tool user's guide and a technical reference material.
The authors state on page 1 of chapter 1 that they expect to update this
document on regular basis. I sincerely hope that the book goes beyond a
marketing push for tools and really sticks to methodology, guidelines
and practices. Tools are an essential part of the solution, but several
good tools exist in the market place and several new ones will come in.
Due "respect" should be given to several tools including Mentor's system
level and co-sim tools.
- Yatin Trivedi
SEVA Technologies, Inc. Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: [ Michael Keating of Synopsys & Author of the "RMM" Manual ]
John - in response to Janick's review:
Rant and Rave Section: Companies don't write books, individuals do. It is a
book written by an engineer (me) based on a bunch of internal manuals and
papers (all written by ASIC designers, not EDA/CAD guys). The original
intent was for internal consumption - a guide for our engineers, and
contractors working for us, to make sure the designs we got were reusable.
We're the group that owns DW Foundation (and drove the bug rate down to
zero), developed the 8051 (we think a showcase for ease-of-integration) and
the new PCI (we think a showcase of how to design and deliver a highly
parameterized core). We are also the group that did the synthesizable ARM
7TDMI. The book really captures the technical side of what we had to do
when we (principally myself and Warren Savage) came in and had to clean up
the mess of the original PCI. Everything we talk about in the book is based
on real problems we have seen in real IP, both Synopsys-developed and third
party IP.
Those of us who wrote and reviewed this book do design for a living - just
like Janick. Our over-riding goal was to create a methodology that works,
not to hype Synopsys or impress academics.
Now for my calmer, more reasoned response:
John - Janick clearly read the book carefully and critically, and with
great passion for the subject. No author can ask for more. A lot of his
points are valid, and no doubt many of his suggestions will find their way
into the next edition of the book. But it's probably worth while to address
some of the points he raises, particularly where he may have missed the
intent of what I was trying to do.
Janick's concerns fall into two categories: sins of commission (errors in
the book) and sins of omission. Of these, his greatest concern appears to
be the sins of omission. So let me address these first.
The biggest problem a technical author faces is that engineers don't read.
I was taught this in a tech writing class many years ago and certainly
re-learned it with the RMM. The first version (Synopsys Design Reuse Style
Guide) which we put together early in 1997, was twice the size of the RMM,
with a great deal more material, especially in design for test and
chip-level implementation. The trouble was, I couldn't get anyone to read
it! Five hundred pages was just too thick; people weren't even cracking it
and reading the first page.
So the next year was spent taking much of the material out of the book, and
refining the remaining sections to hit what we thought were the most
critical issues.
The original style guide was, as Janick observes of the RMM, focused on IP
creation much more than IP integration. This is based on our experience
creating and integrating IP. If you try to integrate crappy blocks into
your chip design, no methodology is going to solve your problem. On the
other hand, good IP can be integrated effectively into chip designs using
many different flows and methodologies. Our conclusion is a basic rule of
reuse:
The reuse battle is won or lost based on the quality of the IP.
That's why we focus on IP creation almost to the exclusion of integration.
Of the dozens of 8051 customers, only one had any problem at all
integrating the 8051 into their design (and that one, I hate to say, was
staffed by really, really junior engineers). On the other hand, I have
recently been working with a customer trying to integrate a processor where
they were given the transistor netlist and told - go ahead, good luck! They
ended up doing hardware-software co-simulation using SPICE, for god's sake.
The real problems that real chip teams are facing using the IP are
incredibly basic. And for that reason, we felt we needed to start by
establishing a baseline of good engineering practices that are the real key
to success in reuse. That means defining the deliverables for IP (the
critical point at which the IP creator and IP integrator meet), and showing
how to create deliverables that can be used. Janick seems to feel we have,
by and large, met this goal, and this is gratifying feedback.
Janick states that the book sins in making all the guidelines very DC
centric. Here he has perhaps missed some points. First of all, the basic
design guidelines (fully synchronous design, etc) are just good design
practices -- I was doing this long before I even heard of DC. He may be
talking about the coding guidelines. But (my second point) synthesis is a
cornerstone of IP. Even hard IP must have a synthesizable RTL version as a
reference implementation description. Direct hard IP porting is just too
slow to get critical blocks migrated to new technologies fast enough.
(Thirdly), certainly the guidelines, where synthesis-specific, tend to be
couched in DC syntax. But a couple of my contacts elsewhere in the industry
have commented that the guidelines closely match the requirements for all
synthesis tools.
This might be a good time to discuss Janick's apparent concern about some
of the specific tools mentioned. Verilint, he claims, is given inadequate
importance. It's hard for me to argue with his perception; if that's what
he got out of the book, then that's what he got out of the book. But
certainly the intent was to highlight linting tools, such as Verilint, as a
key component of the flow. It appears in all the flow diagrams right there
beside synthesis and functional verification. We tried to reflect in the
book, as in all the presentations I make to customers and conferences, that
linting tools and code coverage tools are critically important, and that
they have made a dramatic contribution to the design process. To the dismay
of some Synopsys sales guys, after my customer presentations on reuse, the
tools most often discussed are lint and code coverage, perhaps because many
customers are unfamiliar with them.
The intent of the book was to talk about the tools that are actually used
in practice by engineers to solve their problems, not to promote any one
companies tools. When Janick points out that Chrysallis is not mentioned,
he is absolutely right to call this an oversight. I actually thought I had
fixed this, but to err is human. Chrysallis has made a critical
contribution to the industry. There was always some formal verification
available in DC, but until Formality, Chrysallis was the only practical
formal verification tool, and saved the bacon for a number of design teams.
This will be fixed (along with may other shortcomings), in the second
version of the RMM).
Janich states that we put too little emphasis on behavioral models and
testbenches, and again it's hard for me to argue with what's in the eye of
the beholder. So let me clarify the intent, and let your readers decide if
this is reflected in the book. Behavioral models and testbenches are
critical (and show up at the top of the flow diagrams) for a large class of
designs, especially those with algorithmic complexity. For something like
processor or an MPEG design, simulating at a high abstraction level is the
only way to get the simulation performance you need early in the design
cycle. Developing a testbench at this level also allows you to verify the
RTL design against the behavioral model. On the other hand, behavioral
models are not useful for another class of design (like a bus interface)
where the cycle-by-cycle behavior is the critical design factor.
Again, where he says Verilog simulators are as troublesome for portable
code as VHDL, this has simply not been our experience. We test our code on
VSS, Vantage, MTI, Leapfrog, XL and VCS. Consistently our greatest problems
are with the VHDL simulators, though we have had some problems with the
Verilog ones. With Verilog, the basic key is to stick to fully synchronous
design, and follow the blocking-non-blocking rules, and you'll run into few
problems - except for real bugs in the simulators. Maybe we should have
pointed out that Verilog-XL, with certain optimizations turned on, has
bugs. I ran into this problem years ago; at that time it looked like they
were doing port collapsing wrong. Some of the problems have been fixed and
others have not. It just didn't occur to me to talk about coding around
these bugs. It just seemed like info that would be obsolete (hopefully) by
the time the book got out. Maybe it is worth revisiting this decision.
As for specific complaints on blocking-nonblocking, and the example in
5.5.6, come on Janick, give us a break! It's a toy example, for God's sake,
to show the coding style, not to show an example of exactly how getting the
order wrong can screw up your code. This is covered in the good VHDL and
Verilog books. We're really just trying to get people to think about these
issues and re-check their VHDL/Verilog books. We don't want to replace
these books. (On the other hand, there is a very embarrassing typo in
another example, where we use blocking assignement inappropriately. I can
only say Warren and I must have been dozing when we proof-read that example).
In general, as Janick points out areas where we could have devoted more
discussion, he is right. We will be updating the RMM, hopefully for a new
version out at next DAC. His input, as well as all the input we get from
readers, will be factored into the updates. Again, we will have to make
tradeoffs in order to keep the size of the book under control, but
unquestionable the book will be improved from the feedback we have gotten.
Finally, let me address Janick's final remarks:
1) lack of new material: In our experience, the problems that real creators
of IP have is not following the basic good design practices described in
the book, and in not providing the deliverables their customers need. The
intent of the book is to address the most common, not the most advanced,
issues in design reuse. We wanted to establish a baseline of practices so
that all IP is created in a way that allows integrators to build their
chips. This, we feel, is the most important contribution we can make in an
initial book. Future books and articles will address some more advanced
issues. The two most important ones are probably how to verify IP and how
to design parameterizable IP. Both of these are, in my opinion, still
research topics with no definitive solutions.
2) Why does reuse fail when the technical problems are overcome: This is a
fascinating question, and one that again is a research issue with no
definitive solution. I address some of this in an article in an upcoming
issue of Computer Design. In a nutshell, based on my observations, the
problems come down to this: The incentives within a company often do not
reflect the incentives (ie, market pressures) the company receives from the
outside world. Engineers are rewarded for tricky designs instead of designs
that contribute to the bottom line, managers are rewarded for short term
goals at the expense of the long term goals. Solving this problem is
complex; we are working with some customers to try to solve this today.
But I have to question Janick's assumption that there are some design
groups that have solved all the technical problems in reuse. There are at
least two unsolved technical problems: the problem of verifying a design to
100% levels of confidence, and the high cost of design for reuse. There is
a clear need for IP that has no bugs; why reuse code you end up having to
debug. But there is no way, today, to produce a significant design with
(provably) no bugs. And the cost of designing for reuse often exceeds 2x
the cost of developing a design for a single use. This is a serious
liability when engineering teams decide what to make reusable.
In summary, there are solved problems in design reuse; we have tried to
include the most important ones in the RMM, and we will expand this work
based on feedback from readers like Janick. There are unsolved technical
and non-technical problems, and we will probably address these in separate
papers as the technology evolves and as we help companies migrate to
reuse-based design.
Anyway, thanks to Janick for the thoughtful review, and I would certainly
invite him to be one of the reviewers of the next version of the RMM before
it goes to publication.
- Michael Keating
Author of the "RMM" Manual
Synopsys
|
|
