( ESNUG 300 Item 8 ) ---------------------------------------------- [10/7/98]
Subject: ( ESNUG 299 #6 ) The Synopsys/Mentor "Reuse Methodology Manual"
[ Editor's Note: The ">"s below are from Michael Keating, the author of
the "Reuse Methodology Manual" (by Kluwer Academic Publishers); the new
replies below are from Janick Bergeron of Qualis Design. - John ]
Author Mikael Keating wrote:
> 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.
From: "Janick Bergeron" <janick@qualis.com>
Actually, they do read a lot. Anybody who has mastered Unix and EDA tools
had to read an awful lot. They simply do not want to wade through long
winded paragraphs to find the few pearls of wisdoms on how to do things.
They like easy to find and follow pointers with some explanations (if they
happen to initially disagree with them) or the risks involved in breaking
them. That way, they don't have to read all 500 pages: only the headings,
then read on for more details as required.
I think your chapter 5 was by far the best written for engineers and
probably the one that will be referenced the most. If only the other
chapters were written in the same style!
> Janick states that the book sins in making all the guidelines very DC
> centric.
Where did I say "all"? *Some* of the guidelines involved DC shell commands
and scripting - can't be more DC centric than that.
I would recommend you structure guidelines according to applicability (such
as we have done in our own web-based reuse document) general coding (e.g.
comment, indentation), HDL coding (e.g. signals vs variables, assignments),
RTL coding (e.g. synchronous design), Verilog coding (e.g. avoiding race
conditions), VHDL coding (e.g. 87 vs 93) and DC coding/synthesis (e.g.
defining clocks).
> 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. (...) 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.
I definitely didn't get "critical" out of the book. And I disagree with
your assessment of their usefulness for cycle-by-cycle interfaces. Here's
a Verilog behavioral model for read/write cycles on a i386SX bus. It's a
fully synchronous bus with specific cycle-by-cycle behavior. Yet the model
is completely behavioral, simulates faster than an equivalent RTL model,
faster to write, easier to debug and can be interfaced to any similar bus
models for another bus interface to quickly create a behavioral model for
a bridge.
And it does not convey any intellectual property.
We feel that a behavioral model should be part of *all* IP components
delivered.
// Note: all delays values should REALLY be parameters...
time LAST_RDY;
always @ (RDY) LAST_RDY = $time;
time LAST_D;
always @ (D) LAST_D = $time;
//
// Read Cycle
//
task READ;
input [23:1] ADDR;
output [15:0] RDAT;
begin
@ (posedge CLK);
A <= #4 ADDR;
RW <= #4 1'b0;
ADS <= #4 1'b0;
@ (posedge CLK);
@ (posedge CLK);
ADS <= #4 1'b1;
repeat (2) @ (posedge CLK);
while (RDY !== 1'b0) begin
repeat (2) @ (posedge CLK);
end
if ($time - LAST_RDY < 19) begin
$write("WARNING: Setup violation on RDY at %t\n", $realtime);
end
if ($time - LAST_D < 9) begin
$write("WARNING: Setup violation on D at %t\n", $realtime);
end
RDAT = D;
fork
begin
#4;
if ($time - LAST_RDY < 4+19) begin
$write("WARNING: Hold violation on RDY at %t\n", $realtime);
end
end
begin
#6;
if ($time - LAST_D < 6+9) begin
$write("WARNING: Hold violation on D at %t\n", $realtime);
end
end
join
end
endtask
//
// Write Cycle
//
assign #4 D = DATA;
task WRITE;
input [23:1] ADDR;
input [15:0] WDAT;
begin
@ (posedge CLK);
A <= #4 ADDR;
RW <= #4 1'b1;
ADS <= #4 1'b0;
@ (posedge CLK);
DATA <= WDAT;
@ (posedge CLK);
ADS <= #4 1'b1;
repeat (2) @ (posedge CLK);
while (RDY !== 1'b0) begin
repeat (2) @ (posedge CLK);
end
if ($time - LAST_RDY < 19) begin
$write("WARNING: Setup violation on RDY at %t\n", $realtime);
end
#4;
if ($time - LAST_RDY < 4+19) begin
$write("WARNING: Hold violation on RDY at %t\n", $realtime);
end
@ (posedge CLK);
DATA <= 8'hZZ;
end
endtask
> 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
If all you are porting are RTL models, then of course you won't get problems.
But what about the 1.5-2.5X amount of behavioral code that makes up the
testbench? In *every case* where we had to port behavioral code from XL to
VCS (or vice-versa), it broke down (the code was not written by Qualis mind
you :-). One of our engineers is right now tracking down why a simulation
that works just fine under VCS won't work at all under XL (although every
thing compiles fine...). We even had testbenches that did not work if we
did not use the proper +turbo options in XL. Some other behavioral model we
have seen simply could not be ported without a significant amount of
rewriting because XL and VCS resolve relative hierarchical names differently.
A nice thing to use is the shared access warning in the MTI simulator: it
catches some of the race conditions (i.e. multiple writes to a reg in the
same simulation cycle). If anybody is interested in writing a "lint" tool
that will do some structural and dataflow analysis on behavioral Verilog
code, I have a set of rules to look for to detect race conditions and
questionable constructs...
> The real problems that real chip teams are facing using the IP are
> incredibly basic (...) But I have to question Janick's assumption that
> there are some design groups that have solved all the technical problems
> in reuse.
If those problems are so incredibly basic, why is it so hard to believe that
some groups have overcomed them? I claim that (and know) groups follow
almost every technique you outlined in your book, yet little reuse happens
there. My point was that the content of the RMM is not a *sufficient* (and
sometimes not a necessary) step to enable reuse.
> There are at least two unsolved technical problems: the problem of
> verifying a design to 100% levels of confidence (...) 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.
That can *never* be achieved. Nor it is necessary. We succesfully design
right-first-time ASICs today - no one claims these ASICS to be bug free or
verified at 100% confidence. Why not right-first-time IP?
> and the high cost of design for reuse. (...) 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.
Here you seem to be arguing against reuse... Everybody knows that reuse
saves in the long run. We also have customers who claim that reuse actually
makes design *cheaper* (when designing their own IP) because it forces them
to compartimentalize functionality, write better specification (especially
of the interfaces) of more manageable blocks, partition then allocate
designs more effectively, reduce the number of interfaces, verify at a level
where there is more visibility using common interfaces (thus reusing
testbench components as well), perform system-level verification, etc...
All items you outline in your book but actually implementing them are more
cultural and management issues than technical.
- Janick Bergeron
Qualis Design Corporation
|
|
