( ESNUG 301 Item 4 ) --------------------------------------------- [10/15/98]
Subject: ( ESNUG 299 #6 300 #8) The Synopsys "Reuse Methodology Manual"
[ Editor's Note: The ">"s bellow are from Janick Bergeron of Qualis,
commenting on the "Reuse Methodology Manual" (by Kluwer Academic
Publishers). The replies are from Howard Landman of Toshiba. - John ]
Janick Bergeron writes:
> 3.2.1 Synchronous vs. Asynchronous Design Style
> The book politely says, "Anyone using or designing with latches should be
> shot." We agree. The book also fails to mention why flip-flop-based
> designs are superior for timing analysis, formal verification, testability,
> etc.
From: landmh@taec.toshiba.com (Howard Landman)
Gosh, John, I'm taping out a latch-based design at the moment. I thought it
was more like "Anyone using or designing with latches will end up WISHING
someone had shot them". :-) Actually, the situation this year is not nearly
as dismal as it was 2 years ago, but there are still problems. A quick
survey:
SYNTHESIS:
Design Compiler - handles latches OK in 1998.02-02 and later (well,
maybe 1998.02, but there were bugs, so don't use that version).
All older version give extremely poor optimization. Also, there
has been a serious issue with DC being forced to use inaccurate
FF-like "black box" timing models of blocks which actually have
latch-like behavior. This may finally be fixed, possibly, but
you need PathMill 5.2, Primetime, and DC together to find out
(there is supposedly a path from PM to STAMP to PT to db to DC).
We haven't gotten this to work yet, but we just started trying.
And if you're stuck building black box models, the timing of them
depends on the clock frequency, so you need to build a complete
separate set of timing models for every different clock period that
you want to use. (Prior to 1997.08, this was even true for some
standard library cells! Consider the enable pin on an enabled latch.)
This may mean maintaining multiple versions of timing models for
every memory, datapath, etc., and of course multiple PathMill or
HSpice runs to generate them.
Ambit BuildGates - handles latches OK, except that early versions
had some problems with generating gated clocks when synthesizing
enabled latches (didn't read the "clock: true" attribute, tsk tsk).
Latch-like gray box "IP models" seem to work OK.
VERILINT:
Will give you a warning when "a latch is inferred". But in a latch-
based design, you expect lots of these. So, it is harder to find
the if-with-no-else and case-with-no-default bugs. Also sometimes
gives false warnings in complex latch-inferring RTL. But otherwise
works pretty well.
FORMAL VERIFICATION:
Chrysalis (I'm using 2.3) handles latches OK as long as RTL and gate
match precisely. If you have a FF in your RTL and 2 latches in the
gate model (representing the actual transistors), they don't match
automatically; you have to create a guidance file for each such cell.
For comparisons that don't have this issue, latches seem to work fine.
SIMULATION:
No known problems.
TEST GENERATION:
Probably lots of problems, but we don't do it, so it doesn't bother us.
COVERAGE TOOLS:
No real problem in RTL, I think.
LAYOUT:
Most layout tools don't understand latch transparency. But, it's not
clear that this causes any serious problems. Constraints out of DC
are created for each path (from FF/latch to FF/latch), and if timing-
driven layout can meet them, we're OK. Of course, it would be nice to
trade off a speedup on one side of a latch with a slowdown on the other
side ... but eventually you get to do this in analysis.
SEXY NEW TOOLS FROM COMPANIES WHOM I CANNOT NAME:
Well, I saw a few tools I would have wanted to try out ... except that
they don't handle latches yet. So I was prevented from spending (or is
it wasting?) time and effort debugging someone's beta code. But, I
maybe also missed out on useful new functionality. Hard to weight
this category.
There are other areas of incredible pain as well. In theory, latches should
make the design less subject to clock skew problems, but in practice most tools
(including DC and BG) don't understand this correctly, so you don't actually
see any benefit until you get into the transistor timing domain (PathMill,
HSpice, etc.)
Latch enable pins require large setup times. (It's OK for enable to arrive
late, but if disable arrives late ... oops, you just latched data that you
weren't supposed to!) This causes timing problems if designers are not
expecting it.
> 3.5 Verification Strategy
> OK. Now what are the characteristics of a good verification strategy? This
> section should do more to highlight the importance of planning verification
> in the early stage of the design, and the need to change the design to meet
> the requirements for verification.
Yes. On my next project I'm going to *INSIST* on explicitly published
"design for verifiability" guidelines. Designers are like a gas expanding
into an evacuated container; they will do whatever is not explicitly forbidden.
And usually a few things that *ARE* explicitly forbidden. Must be some
kind of quantum-mechanical tunneling effect. :-) Anyway, it's easier to just
not let them do it in the first place, than to try to compress the design
methods later in the project (which creates intense pressure and heat :-).
> 5.5.5 Blocking and Nonblocking Assignments (Verilog)
> The rule states that the non-blocking assignment must be used in
> always @ (posedge clk) blocks. That is true only for regs that are to be
> inferred as FF's. The computation of intermediate values, a technique
> that often minimizes area, requires the use of the blocking assignment.
But it isn't necessary for the intermediate value calculation to be inside
the same always@ block. It's quite simple to adhere to the above rule in
practice. And RTL code which follows it gives more predictable synthesis
(and Verilint) results. So, I agree with this rule 100%. (And it also
applies to latch blocks!)
> Furthermore, the only justification for the rule is that, otherwise,
> simulation results could differ between RTL and gates. If the rule is not
> followed, race conditions will be created and results may differ between
> RTL simulation on different simulators or when using different command-line
> options.
I don't know about you, but that's a sufficient reason for me!
> 10.2.4 Meeting Timing Requirements
> Again, nothing very specific here. What makes a script robust, yet
> flexible? How do I evaluate a macro so I can be assured I will be able to
> meet timing?
Executable timing specs (timing model and constraint file) help.
> A critical chapter that falls too short. Probably the key to a successful
> reuse design methodology. Section 13.1 does not mention the creation of a
> reward system for creating reusable designs, reusing designs, or architecting
> designs so reusable components can be included.
Yes, in my experience this is the biggest problem. Most designs are under
such intense time pressure that no one in management wants to "waste" time
making the design reusable. But they always have time to waste later, when
they're struggling to reuse part of a previous design ...
- Howard A. Landman
Manager, Synthesis & Physical Design
Toshiba America Electronic Components
|
|
