ASIC Design Flow

Optimizing Multiple
EDA Tools within the
ASIC Design Flow
Lionel Bening and Harry Foster
Hewlett-Packard

This proposed design methodology incorporates

modern programming language principles, such
as information hiding, to let engineers optimize a
designs functionality and simultaneously support
multiple EDA tools.

processes throughout the course of design and

enables augmentation of new processes. It
leaves the designers text and functional intent
undisturbed throughout the designs duration. It
offers cooperation and support for multiple EDA
tools while achieving higher verication coverage in minimal time. Finally, our approach claries the design intent at the RTL, increases
design productivity, and raises the abstraction
level without forcing the designer to adopt a new
hardware description language (HDL).

SELECTING A SINGLE REGISTER TRANSFER

46

Hardware description languages

level (RTL) coding styleone that maximizes

the performance of simulation, Boolean equivalence, and model checking while achieving an
optimal flow through synthesis and physical
designis a formidable task. To reconcile competing tool-coding requirements, the HewlettPackard Richardson VLSI Lab has developed a
coding style and a design ow methodology that
incorporates modern programming language
principles. Using the principles of information
hiding, abstraction, and encapsulation on all
functional grouping of state elements (and other
objects), our engineers can focus on design functionality rather than on each individual electronic design automation (EDA) tools optimal
coding style requirement.
Building on these principles, we have developed a design methodology to automate the
generation of tool-specic libraries. This methodology, which optimizes multiple process points
within the application-specic integrated circuit
(ASIC) design ow, has several advantages: It
permits a seamless optimization of design

Developed in the mid-1960s, the original

HDLs addressed the deficiencies of building
hardware models using rst-generation, higherlevel programming languages such as Computer
Design Language,1 Digital Systems Design
Language,2 A Hardware Programming
Language,3 and Instruction Set Processor
Specification.4 For example, higher-level programming languages during this period lacked
support for concurrency and a correspondence
or relationship to a specific hardware implementation, at least when modeling at the RTL.
Such features are necessary for hardware design
analysis and synthesis automation. Todays
HDLsfor example, VHDL5 and Verilog6have
evolved to support the concepts and advancements in modern programming languages as
well as the principles underlying good programming practices. The decision to apply
these programming principles when coding in
HDLs, however, generally lies with the engineer.
Parnas7 of Carnegie Mellon University intro-

0740-7475/01/$10.00 2001 IEEE

IEEE Design & Test of Computers

duced the programming principle of information

hiding, which instructs designers to hide details
pertaining to a single design decisionparticularly one thats likely to changewithin a program module. This principle lets designers
isolate or localize those design decision details.
This localization results in a level of design
abstraction surrounding the interface relationship with other design segments, a concept
known as the abstraction principle.8
Engineers are accustomed to creating multiple levels of abstraction within a designs RTL
description by partitioning and localizing related functionality into a module description. In
optimizing EDA tools performance, however,
we recommend applying the information hiding principle to each distinct grouping of state
elements within the designs RTL. This technique lets each register bitan RTL descriptions fundamental building blockbe
functionally grouped into a register object and
detailed at a lower abstraction level.
The design methodology lets the project
computer-aided design (CAD) or design verication group automatically generate tool-specific libraries, which provide the lower
abstraction level details in an optimized EDA
process format. The objects abstraction interface within the RTL description permits referencing of a targeted tool-specific optimized
library for each process point within the design
ow. Equivalence checking validates functional consistency between the targeted libraries.
Design methodologies
VHDL and Verilog offer engineers two methods for creating design abstraction. VHDL provides a mechanisman entityfor creating an
abstraction level in the design. The architecture
specification defines the entitys behavior.
Using the same entity interface, engineers can
reference different architecture libraries containing definitions optimized for specific
processes within the ASIC design ow.
Verilog, on the other hand, provides a mechanisma modulefor creating abstraction in
the design. The module provides the details for
the abstracted interface as well as the abstracted
behavior. Verilog can link a different denition
for a specic, instantiated module by referencing
JulyAugust 2001

application-oriented libraries. With this technique, engineers can generate optimized libraries
for specic process points in the design ow.
We favor an alternate approach to VHDL
and Verilog, one that defines text macros for
various objects in the design (for example, an
n-bit register, specific multiplexer, or latch
arrays). Designers instantiate these high-level
text macros within their HDL. The HDL is then
preprocessed to expand the text macro into
either a module instantiation or inline code.
Our text-macro approach lets engineers modify module interfaces (if required), support
inline code expansion, and customize projectspecic needs seamlesslyall controlled at a
single point within the design ow.
Benefits of text macros
On the surface, our proposed object-based
or text-macro methodology might appear to
recommend coding the design at a low gate
instance or cell-based level. On the contrary, a
text-macro hardware design methodology
enables coding at a higher abstraction level.
The engineer is free to design with higher-level
objects rather than coding lower-level implementation details, meaning tool-specific optimization details are isolated and localized
within process-specic libraries.
Furthermore, the text-macro methodology
facilitates design reuse9 by maintaining cell technology independence, which, if required, is controlled within a synthesis-targeted library.10 The
inference of register cells from a library object is
still possible during the synthesis process.
Alternatively, explicitly referencing a unique
technology cell type within the library object can
be controlled during synthesis, depending on
the users synthesis optimization requirement.
Based on our experience developing large
systems with this methodology, developing the
text-macro object libraries does not require signicant effort. The cost of revisiting tens of thousands of lines of RTL code simply to optimize
or enable a new verification feature
compared with the cost of developing tool-specific librariessupports our cost-effective,
object-based hardware design approach.
In the rest of this article, we highlight example processes in a typical design ow and the

47

ASIC Design Flow

optimization benets that designers can achieve

through a text-macro methodology. The specific optimizations are not signicant; its the ability to optimize these and other processes
throughout a projects durationwithout interfering with the original RTL descriptions text or
functional intentthat principally justies the
text-macro methodology.

Optimizing simulation
In many design projects, RTL logic simulation
consumes most of the computing and human
effort in design verication before tape-out.
Macro-library-based renement can optimize the
simulations performance and support verication techniques, such as two-state initialization.
Two-state initialization
Faster simulation can be achieved by means
of two-state simulation. However, proper handling of register initialization, as well as non-twostate input port values, needs to be addressed.
Tool-specic macro library renements support
the random initialization and X-Z-state trapping
in two-state RTL logic simulation, which is central to our proposed methodology.11 Random initialization addresses start-up problems in a
design, where some (or all) power-on states are
incorrect states for functional hardware. The solution would be, for example, to turn the power off
and on one or more times as needed to bring up
a device in a correctly functioning state.
The two-state random initializations coverage of start-up problems was superior to RTL
simulations coverage with an X state. While it
is widely known that RTL simulation is grossly
pessimistic compared to gate-level simulation,
RTL simulation with an X state can be optimistic as well. RTL simulation X-state pessimism
often points out malfunctions even where there
is no combination of Boolean 1/0 values that
fail. With RTL simulation X-state optimism, simulations pass tests using X states and fail when
1/0 values replace the X states. This optimism
can occur when designers use if-else and casewith-default behavioral RTL statements instead
of lower-level Boolean RTL statements. An
incoming X can result in an optimistic 0 or 1
output when the if takes the else branch or
when the case takes the default branch.

48

Projects typically run a million or more RTL

simulations with different random start-up
states. Applying random two-state initialization,
projects can minimize start-up design problems
through RTL simulations months before tapeout to silicon. Random two-state, RTL-based
start-up simulation provides far better coverage
(and is much easier to debug) than start-up
tests using power-on, power-off sequences of
lab machines after silicon.
X-Z-state trapping supports our two-state RTL
simulation by translating the X and Z states
arriving as inputs to our two-state chip models
into random two-state values. X states may
arrive from older legacy chip models mixed
with our two-state chip models in a system. Z
states may arrive from inactive buses.
Using RTL models for all storage elements
and input buffers in a text-macro library facilitates adding two-state random initialization as
a Verilog programming language interface
(PLI) call in the library and translating X-Z states
into random values at an input buffer.
Simulation performance
Simulators from different vendors (as well as
successive releases from the same vendor) take
advantage of unique RTL coding styles for
cooperation with their proprietary optimizations. Encapsulating modules within a textmacro library relies on specific vendor
simulator performance optimizations. Encapsulation also lets a project engineer target specic optimizations.
RTL-simulation compiler optimization examples that are relevant to the text-macro-librarybased methodology include the following.
Flattening. The library-based methodology

adds a hierarchy level. The RTL simulation optimizer must eliminate any simulation runtime
overhead resulting from hierarchy boundaries
by removing those boundaries. In the attening
process, the optimization replaces the ip-op
instances with the code for the ip-op model:
dffr r0( .d(dp_a), .ck (ck),
.q (dp_ff[0:3]), .r (rst));
dffr r1( .d(dp_b), .ck (ck),
.q (dp_ff[4:7]), .r (rst));

IEEE Design & Test of Computers

becomes
always @(posedge ck)
begin
if (!rst)
dp_ff[0:3] <= dp_a;
else
dp_ff[0:3] <= 4b0;
end
always @(posedge ck)
begin
if (!rst)
dp_ff[4:7] <= dp_b;
else
dp_ff[4:7] <= 4b0;
end

always @(posedge ck)

begin
if (!rst)
dp_ff[0:7] <= {dp_a, dp_b};
else
dp_ff[0:7] <= 8b0;
end

Flip-flop models with delayed assignments.

The design community continues to debate

whether to specify a uniform delay value in ipflop assignments. The delay value can overcome skew in clock fan-out paths, and separate
the cause (positive-edge clock) and effect (ipflop output change) in waveform viewing; on
the other hand, the delay value can slow some
simulators by adding an extra evaluation cycle:

Common control consolidation. Flattening

eliminates the boundaries, but a simulator

would have to repeatedly fan out the clock
edge effect and test for reset. Common control
consolidation eliminates this fan-out and
repeated tests:
always @(posedge ck)
begin
if (!rst)
begin
dp_ff[0:3] <= dp_a;
dp_ff[4:7] <= dp_b;
end
else
begin
dp_ff[0:3] <= 4b0;
dp_ff[4:7] <= 4b0;
end
end

While a text macro library methodology relies

on common control consolidation, the methodology can also take advantage of this optimization. By testing for reset, test, or scan modes in
a common ordering across all library modules,
the consolidation optimization can encompass
large sets of assignments.
Bus reconstruction. In the common control

consolidation example, an RTL simulation

compiler improves simulation performance by
the engineers assigning the bus as a single unit:
JulyAugust 2001

always @(posedge ck)

q <= #1 d;

or
always @(posedge ck)
q <= d;

In our work, from one project to the next, we

have alternately invoked and omitted a delay
for all ip-ops.

Optimizing equivalence checking

Boolean equivalence checking, a formal verification process, uses mathematics to prove
the logical equivalence between a designs different refinements, without simulation or test
vectors.12,13 Here we show how a macro-library
methodology can optimize the equivalencechecking process.
Identifying register or latch-pair mapping
points constitutes a large percentage of the time
devoted to equivalence checking . This and the
rest of the equivalence-checking process can
benet from a text-macro practice and tool-specic library methodology.
Latch mapping
An equivalence-checking optimization
advantage that the text-macro methodology
provides is the ability to automatically identify
all register and latch pairs between the RTL

49

ASIC Design Flow

Register
transfer level (RTL)
with text macros
module Top ();
case () ;
if () ;

Automatic name mapping of registers and latches:

Hierarchical RTL Flat gate
foo.r0.q \foo.r0.q
RTL

RTL text
macro preprocessor

Equivalence
checker

module Top ();

case () ;
if () ;
dff_3 foo (q, d, );

Simulationtargeted library
module dff_3 ();
wire [0:3] d; reg [0:3] q:
always @ (posedge ck)
if (dsel)
q<=d;
else if (i_scan)

Flat gate

module Top ();

SMUX \foo.a0 ();
XDFF \foo.r0 (q[0], )'
XDFF \foo.r1 (q[1], );
XDFF \foo.r2 (q[2]; );

Synthesistargeted library

Equivalence
checker

Vendor
cell library
module dff_3 ();
SMUX a0 ();
XDFF r0 (q[0], )'
XDFF r1 (q[1], );
XDFF r2 (q[2], );

module XDFF ();

always @ (posedge ck)
q

Figure 1. Optimizing the equivalence-checking latch-mapping process.

50

specication and its gate-level implementation.

For example, by referencing the equivalencechecking or synthesis-targeted library, we can
directly map the hierarchical RTL instances to
their synthesized netlist instances. This enables
the equivalence checker to reconstruct structural similarities between the two designs.
Figure 1 illustrates the method of referencing the synthesis-targeted library from the RTL
during equivalence checking. The hierarchical
RTL reference \foo.r0.q directly maps to the at
gate-level netlist reference \foo.r0 .q because of
the synthesis-targeted or equivalence-checking
librarys referencing the shared vendor cell
library. The designer uses an equivalence
checker to efciently validate the synthesis-targeted library against the higher-level simulationtargeted library.

advantage of the text-macro methodology is

mapping a two-state master-slave latch pair to
a single state-point representation (within the
RTL specification). Referencing an equivalence-checking optimized targeted library for
the state-element object accomplishes this latch
folding. The equivalence-checking targeted
library is constructed to accurately model the
master-slave functionality for each bit within
the functional grouping of state elements
instantiated in the RTL. For example, 16 lowerlevel master-slave latch pairs can optimally
model a 16-bit instantiated register for equivalence checking. Without using an equivalencechecking targeted library, the equivalence
checker must invoke routines to identify the
two-to-one state mapping between the implementation and the specication.

Master-slave latch folding

Another equivalence-checking optimization

Optimizing model checking

Model checking, another formal verication
IEEE Design & Test of Computers

process, uses mathematics to prove, without

simulation or test vectors, whether a designs
implementation satisfies its specification.14
Model checking is also an example of a new
verification process that we added at a later
point in the design phase without disturbing the
engineers RTL description.
The text-macro methodology does not
optimize model checking against state explosion. Our methodology, however, overcomes
various tool-specific coding restrictions while
enabling the model checking tool to take
advantage of clock abstraction across multiple clock domains. This can be accomplished without disturbing the engineers
original RTL source. Overcoming tool coding
and usage restrictions seamlessly and unobtrusively within the ASIC design flow is justification for the text-macro methodology. For
details on applying this methodology to solve
model-checking integration problems, see
the literature.4,6

Optimizing physical design

To ensure a specific macro-cell implementation during synthesis, particularly related to a
unique or specic register inference, designers
frequently must instantiate vendor-specific
macro cells directly into their RTL. By adopting
a text-macro methodology, however, designers
need not functionally verify slower gate-level
macro-cell models during simulation and
model checking. In other words, the synthesistargeted library (see Figure 1) lets designers
tune the lower-level synthesis process for the
projects duration, whereas a simulation-targeted library maintains a higher abstractionlevel view within the RTL.
Two physical-design areas that benet from
our design abstraction and tool-specic library
methodology are synthesis and scan chain
hookup.
Synthesis
Clark describes synthesis,10 as developed in a
company-wide methodology. One challenge
Clark addresses is developing an RTL reuse
methodology that maintains vendor cell library
independence at an RTL. Our text-macro
methodology supports RTL reuse by
JulyAugust 2001

identifying a common set of RTL functional

text-macro objects,
creating a generic Verilog library describing
the functional behavior for each text-macro
object, and
creating, when appropriate, an explicit gatelevel version of the generic library to be referenced during synthesis.
For many circumstances, correct register
inference is still problematic during synthesis.
Our text-macro methodology enables careful
control for exact register (or other) cell selection during synthesis. In theory, however, there
are good reasons not to force registers to a specific instantiation. For example, a specific
instantiation limits synthesis exibility to select
appropriate cell types based on specific optimization time or area compromises.
The reality of routine design is that the
designer can usually make the correct choice
with only modest extra effort. The benefit is a
consistent synthesis result after multiple iterations, and a consistent strategy of specifying
and implementing clocking, resetting, and
scanning across the entire design organization.
We can bundle groups of register (or other)
cells into a text-macro object under one hierarchy level. This bundling lets the designer reference the appropriate library for each process
within the design ow. For example, in Figure
2 (next page), the synthesis-targeted library
contains the exact instances of desired vendor
cells and is referenced from the RTL during synthesis.
A simple 20-bit-wide, 2-to-1 multiplexer
macro with an inverted output illustrates the
explicit selection of a vendor cell during synthesis. The multiplexer text-macro would be
coded as a preprocess text macro:
MUX2X1 (20, U1,sel,data0,data1,
muxout);

and expanded to the RTL as

mux2x1_20 U1
(sel,data0,data1,muxout);

The appropriately sized simulation-targeted

51

ASIC Design Flow

Text macro
library
Text macro
preprocessor

Register transfer
level with
text macros

Modelchecking
library

Model
checker

Equivalence
checker

Simulation
library

Simulation

Equivalence
checker

Equivalencechecking
library

Register
transfer level

Equivalence
checker

Equivalence
checker

Synthesis
library

Synthesis

Gates

Figure 2. A typical ASIC design flow using the text-macro object preprocessor.

module mux2x1_20(x_, d0, d1, s);

output [19:0] x_;
input s;
input [19:0] d0, d1;
mux2x1_4 m0(.s(s), .d1(d1[19:16]), .d0(d0[19:16]), .x_(x_[19:16]));
mux2x1_4 m1(.s(s), .d1(d1[15:12]), .d0(d0[15:12]), .x_(x_[15:12]));
mux2x1_4 m2(.s(s), .d1(d1[11:8]), .d0(d0[11:8]), .x_(x_[11:8]));
mux2x1_4 m3(.s(s), .d1(d1[7:4]), .d0(d0[7:4]), .x_(x_[7:4]));
mux2x1_4 m4(.s(s), .d1(d1[3:0]), .d0(d0[3:0]), .x_(x_[3:0]));
endmodule
Figure 3. Vendor cells in synthesis-targeted library.

library is automatically created with a functional behavior model optimized for simulation:
module mux2x1_20(x_, d0, d1, s);
output [19:0] x_
input s;
input [19:0] d0, d1;
assign x_ = (s ? d1 : d0);
endmodule

The synthesis-targeted library contains the

explicit vendor cells shown in Figure 3.
Notice the unique instance names in the synthesis-targeted library. The consistent instance

52

names improve equivalence-checking performance as previously described. Additionally,

multiple synthesis for the same block containing the text macros yields predictable results for
unchanged logic.
Scan chain hookup
In scan chain hookup, the designs scan ring
typically is connected, or stitched, within the
physical design flow. When a text-macro
methodology is adopted, the wire interconnect
for the scan ring can be automatically backannotated into the RTL through a scan connect
file (derived from optimized place-and-route
IEEE Design & Test of Computers

scan ordering) at the top design level. This le

has global references to the scan port connection defined by each tool-specific targeted
library instantiation. Without a text-macro
methodology, back-annotating the scan connection into the RTL is impractical. With text
macros, however, back-annotation is seamless.
Elsewhere, we discuss RTL scan chain backannotation in detail.15

Text-macro implementation
There are myriad possible techniques for
implementing a text-macro methodology.10,16,17
For example, designers could automatically
generate tool-specific libraries during an RTL
postprocess by identifying specific instantiations (or text-macro objects) that require a
model in the process-specific libraries. For
instance, they could identify a parameterized
dff object during a Verilog postprocessing step.
Conversely, they could preprocess the RTL and
use a text-macro instantiation to identify the
unique objects. They could then build tool-specic libraries along with Verilog RTL expansion
of the text-macro, as Figure 2 shows. The preprocess approach has the following advantages
over a postprocessing technique:
Unrolling of instance names can be controlled within the synthesis library, something not possible with parameterized
modules. This is necessary for identifying
latch-mapping points between an RTL specication and a gate-level implementation.
Redefining the RTL module port definition is
possible for specific process points within
our design ow without changing the original RTL preprocess description. For example, adding an enable signal port to support
model-checking multiphase-related clock
abstraction is possible without modifying the
original RTL preprocess code.
Providing a boilerplate or template (set of
port connection defaults) for commonly
used signals within the macro definition
(such as scan control and reset connections) simplies text-macro object instantiation within the design.
As we mentioned earlier, designers can readily
JulyAugust 2001

implement a text-processor object preprocessor

with a simple Perl script. A preprocessing implementation of the text-macro methodology
would comprise the following steps:
Identify all of the preprocessors user-specied text macros within the designs RTL.
Replace the text macro in the RTL with a
unique instantiated module call, creating a
new abstraction level in the design.
Generate or supplement tool-specific
libraries (if needed), which are optimized
for specic process points in the design ow.
Validate the functional equivalence between
all tool-specic libraries created in the previous step, using equivalence checking.
Figure 2 illustrates a typical ASIC design ow
using the text-macro object preprocessor. The
RTL-with-Text-Macro file is the designers source
RTL, which is written in Verilog with the exception of the various objects, implemented as textmacro calls. The Text-Macro Library contains a
macro template description for all targeted
libraries in the ASIC flow. For instance, the
example below illustrates the text-macro library
template description for a simple nonscan- and
nonreset-based ip-op targeted for simulation
and synthesis:
dene DFFD $size $name $ck $q $d
expand
dffd_$size $name ($ck, $q, $d);
endexpand
interface
dffd_$size ($ck, $q, $d);
output [$size1:0] q;
input ck;
input [$size1:0] d;
endinterface
sim
always @(posedge clk) begin
q <= d;
end
initial $InitialState(q);
endsim
syn
cffd r<$11:0>(.d(d<$11:0>),
.clk(clk), .q(q<$11:0>));
endsyn

53

ASIC Design Flow

enddene

The text-macro preprocess replaces the $ symbols in the macro denition.

In the body of the RTL-with-Text-Macros
source le, the designer instantiates the selected text macros (objects) and actual design
variables corresponding to the macros formal
parameters:
DFFD (2, reg_idle, r_idle, clk,
c_idle);
DFFD (4, reg_head, r_head, clk,
c_head);

The preprocessor replaces the text-macro

references with specic module instances and
creates the nal Verilog RTL le:
dffd_2 reg_idle ( .d(c_idle),
.clk(clock), .q(r_idle));
dffd_4 reg_head ( .d(c_head),
.clk(clock), .q(r_head));

It might appear that the engineer must track

numerous unique module instances to design
effectively with our methodology. In reality,
the engineer must track only a few generic
objects; for example, the dffd text macro
as just shown, and not the larger set of unique
module instances in the Verilog RTL file
just shown.
Besides generating the final Verilog with
model instantiations, the preprocessor automatically generates (or supplements) all toolspecic targeted libraries with unique-sized (or
parameterized) module denitions. To continue our example, the simulation targeted library
would appear as
module dffd_2(q, clk, d);
output [1:0] q;
input clk;
input [1:0] d;
always @(posedge clk) begin
q <= d;
end
initial $InitialState(q);
endmodule
module dffd_4(q, clk, d);

54

output [3:0] q;
input clk;
input [3:0] d;
always @(posedge clk) begin
q <= d;
end
initial $InitialState(q);
endmodule

As previously mentioned, we could construct the simulation targeted library using parameterized modules. However, standard Verilog
(IEEE Std 1364, 1995) did not support the
Verilog instance name iterator (that is,
parameter iteration on instance names).
Predictable instance names are required for
efficient name mapping and equivalence
checking of the nal netlist. An optimized synthesis-targeted library for our previous example,
which contains the appropriate number of cell
instances required for the designers specied
text-macro bit width (with uniquely composed
instance names), might appear as
module dff_2(q, clk, d);
output [1:0] q;
input clk;
input [1:0] d;
cffd r0( .d(d[0]), .clk(clk),
.q(q[0]) );
cffd r1( .d(d[1]), .clk(clk),
.q(q[1]) );
endmodule
module dff_4(q, clk, d);
output [3:0] q;
input clk; input [3:0] d;
cffd r0( .d(d[0]), .clk(clk),
.q(q[0]) );
cffd r1( .d(d[1]), .clk(clk),
.q(q[1]) );
cffd r2( .d(d[2]), .clk(clk),
.q(q[2]) );
cffd r3( .d(d[3]), .clk(clk),
.q(q[3]) );
endmodule

The equivalence-checking process can now

exploit these unique instance namesr0,
r1, and so onduring the register-namemapping step.
IEEE Design & Test of Computers

BY APPLYING THE INFORMATION-HIDING prin-

ciple to the functional grouping of state elements and other objects within the RTL and
introducing a new level of design abstraction,
we have successfully isolated design details
within tool-specific libraries. This text-macrobased hardware design methodology lets us
simultaneously optimize the performance of
simulation, equivalence checking, model
checking, and physical design within our
ASIC design flow. Furthermore, without interfering with the original designs text or functional intent, our methodology lets us add
new features and tools throughout a projects
duration.
Our discussion and examples draw from
actual product design processes and tool experience. We believe that the text-macro concepts
discussed are appropriate to designs of any size
or complexity. To apply these concepts, however, designers must base decisions on a projects size, complexity, and time-to-market
requirements.

Manual, Kluwer Academic, Boston, 1999.

10. L. Clark, Developing a Company-Wide Synthesis
Methodology, Synopsys Users Group (SNUG99),
http://www.synopsys.com/news/pubs/snug/
snug99_papers/Clark_Final.pdf.
11. L. Bening, A Two-State Methodology for RTL
Logic Simulation, Proc. Design Automation Conf.,
ACM Press, New York, 1999, pp. 672-677.
12. S.Y. Huang and K.T. Cheng, Formal Equivalence
Checking and Design Debugging, Kluwer Academic, Boston, 1998.
13. H. Foster, Techniques for Higher Performance
Boolean Equivalence Verification, HewlettPackard J., vol. 48, no. 2, Aug. 1998, pp. 30-38.
14. E. Clarke, O. Grumberg, and D. Peled, Model
Checking, MIT Press, Cambridge, Mass., 1999.
15. L. Bening and H. Foster, Principles of Verifiable
RTL Design, Kluwer Academic, Boston, 2000.
16. L. Bening et al., Physical Design of 0.35m Gate
Arrays for Symmetric Multiprocessing Servers,
Hewlett-Packard J., vol. 49, no. 3, Apr. 1997, pp.
95-103.
17. P. Barnes and M. Warren, A Fast and Safe Verification Methodology Using VCS, Synopsys Users
Group (SNUG99), http://www.synopsys.com/news/

References

pubs/snug/snug99_papers/Barnes_Final.pdf.

1. Y. Chu, An Algol-Like Computer Design

Language, Comm. ACM, Oct. 1965, pp. 607-615.
2. R. Duley and D.L. Dietmeyer, A Digital System
Design Language (DDL), IEEE Trans. Computers,
vol. C-17, no. 9, Sept. 1968, pp. 850-861.
3. F. Hill and G. Peterson, Digital Systems:
Hardware Organization and Design, John Wiley &
Sons, New York, 1973.
4. M. Barbacci, Instruction Set Processor Specification (ISPS): The Notation and Its Application,
IEEE Trans. Computers, vol. C-30, no. 1, Jan.
1981, pp. 24-40.
5. IEEE Std. 1076-1993, VHDL Language Reference
Manual, IEEE Press, Piscataway, N.J., 1994.
6. IEEE Std. 1364-1995, Hardware Description Lan-

Lionel Bening is a
CAD engineer with HewlettPackard, currently working on
uniform Verilog RTL methods
for effective verification across
large designs. He has also
served as an adjunct lecturer on logic and timing
verification topics at the University of Minnesota.
Bening has a BS in electrical engineering from the
University of Minnesota. He is a member of the
ACM and a senior member of the IEEE.

guage Based on the Verilog Hardware Description

Language, IEEE Press, Piscataway, N.J., 1996.
7. D.L. Parnas, On the Criteria to be Used in

The biography of Harry Foster appears on

p. 15 of this issue.

Decomposing Systems Into Modules, Comm.

ACM, vol. 5, no. 12, Dec. 1972, pp. 1053-1058.
8. D.T. Ross, J.B. Goodenough, and C.A Irvin, Software Engineering: Process, Principles, and Goals,
Computer, vol. 8, no. 5, May 1975, pp. 17-27.
9. M. Keating and P. Bricaud, Reuse Methodology

JulyAugust 2001

Direct questions or comments about this article

to Harry Foster and Lionel Bening, HewlettPackard Co., 3000 Waterview Parkway, Richardson, TX 75080; authors@verifiableRTL.com.

55