Tutorial (T-1)

Functional Verification 2003: Technology, Tools andMethodology

Abstract are two different model or the design equivalent (or at least,
consistent) and does a design satisfy properties (that is
Functional verification is a key bottleneck in the cost- assertions) that guarantee its correctness?
effective design of integrated circuits. It is estimated that
ver@cation in its entirep accormts.for up to 60% ofdesign As an illustration of the “equivalence” problem, it is
resources, including duration. coinputer resources and now routine in the industry to check that RT, gate and
total personnel. The three priiiiaiy methods used in logic switch level models are equivalent. Boolean equivalence
and fiincrional veriQcation of commercial integrated checking remains the most pervasive formal verification
circuits are siniulation, emulation and foimal ver@ztion. technology in use. Commercial tools can compare even the
While it is notpossible to coinprehensively survey thefield largest designs for equivalence. This is possible because of
in a short space, currentpractice in isolated aspects ofall the structural similarities among these models. What is still
tkiee hyes ofveriJication are discussed. lacking is a routine way to compare transaction level
.models (such as Ctt- or SystemC) to RTL (Verilog or
All design arid i!er(fication tools work on a model of a VHDL). This is an area of active research.
clesigii, .for esuriiple. transaction, register tracsfer (Rr),
gate, switck and transistor models. These models are As an illustration of assertion checking, there are quite
defined b,y the seiiiuntics of rhe languages that describe the a few commercial Computer Aided Design (CAD) vendors
niodels. Buf it is not the purpose of this paper to discuss who are selling formal and simulation based verification
language, hut inore to discuss technologies. methodologies tools to check assertions. Primarily these tools are used to
arid applications. h the last .five years the verification check assertions at the block or unit levels of complexity
Iaiirlscape has changed somewhat. We will emphasize these such as bus interface units or internal units. One trend in
changes. For esaiiiple, rhe rise oftestbench languages, the verification is to check at the unit level of complexity,
use of assertions and constraints -- rather than golden especially for standard protocols such as PCI, USB, and
models -- and various iiiipro~~eriierits to formal verification SATA. There is a vigorous debate on standardization of
tools have ernerged. assertion languages such as PSL, Verisity, SysteniVeriloz
assertions.
0 Introduction
The rest of this paper is organized as follows,
Five years azo, I presented a similar paper [Pixley98] simulation verification, emulation verification, forinal
at a conference in Aim Japan. It is interesting to observe verification, synergies between verification strategies,
what has changed and what has remained unchanged in the emerging technologies and algorithms.
intervening five years. Functional verification has become
an increased bottleneck in the rapid design of integrated 1 Simulation Verification
circuits. Functional verification deals only with the logical
and sequential propelties of design and ignores timing, Simulation remains the mosr commonly used tool ill
power, area and manufacturahility considerations--though ,verification. Popular commercial simulators are
these are certainly critically important considerations. competitive in performance (speed) and features. A few
There are two broad questions with which functional companies use internal cycle based simulators to speed up
verification deals: are two models of the design under simulator performance. Of course, h g h level, behavioral
verification “equivalent”, and does a model of the design models in C can simulate faster than RTL models because
operate correctly? In addition t o our 1998 paper, [Pixley961 they are simulating a significant abstraction of the design
also contains a snapshot of 1996 functional verification In fact, stepping down each level of the abstraction from
technology. There are still two key verification questions:
0-7803-7889-x/03/$17.00@2003IEEE.
1
 behavioral 10 RTL to gate to switch, greatly slows randomized hut under certain restrictions such as ranges,
simulation. On the other hand, design details grows as one say 3 to 7, on values inserted into specific fields. The
descends the abstraction hierarchy. constraints may depend upon values of certain variables
that are known only at simulation time. For this reason,
Aside from those few companies with proprietary constrained random simulators need an on-the-fly
simulators, most RTL and gate models are written in constraint solver [Yuan99, ShimizuO2, Iyer031. On-the-fly
Verilog or VHDL. Historically, one of the great synergies constraint solving can be a very difficult problem
of technology was the realization that, suitably constrained, especially when the constraints are very complex. Since
simulation models could also be used for logic synthesis. testbench tools encourage stimulus generation at the level
This was very much an enabling paradigm shift for the of word, instruction and transaction, constraints may not
design process. From the design project point of view, the always be difficult to solve.
’
most important simulation issues are stimulus generation,
monitors and coverage measurement. These functions are Temporal constraints is another way of defining an
addressed in testbench tools. Commercially, the three most environment of a design part. Simultaneously solving
popular languages and tools are Synopsys’ Vera, Verisity’s temporal constraints is necessary in state of the art
E and Cadence’s Testbuilder. The language accompanying constraint solvers. It is important to be able to take a
each of these tools is a programming language with monitor for a bus interface protocol and convert it into a
constructs to support the definition of testhenches. stiniulus generator for the design input. Currently, only a
Unfortunately, since the language of these tools is a full few tools accomplish this “flipping” from monitor to
programming language, testbenches produced by these generator.
tools are generally not synthesizahle and therefore their
testbenches cannot be used directly with formal verification A monitor is a device which watches a simulation
tools or put on an emulator. Testbench tools are used to passively and flags whether certain events did or did not
de.fine bus functional models which are used to define the happen. An event can either be a Boolean combination of
environment of the design under verification (DUV) and signals at a single time or it can be a sequence of events
are programmed to interact with the DUV over time., For example, on a USB interface a certain
sequence of signals may indicate that a start of packet is
The idea of testbench tools and languages is to provide seen or that a USB transaction has completed correctly.
an convenient way for verification personnel to build a These are temporal events which can be monitored and
testbench quickly and at the level a programmer can recorded. Monitors provide ways to measure simulation
understand. A key feature of these tools is to generate input coverage. There are many ways to measure coverage. For
stimulus of the followjng ‘sorts: directed, random and example, code coverage measures which lines of RTL code
constrained. Directed simulation is the oldest way of have been covered during simulation. FSM coverage
generating simulations. Verification personnel would read measures which states of an Finite State Machine the
the written specification and then devise a specific design has visited and which state transitions the FSM have
sequence of inputs to the DUV in order to see whether the been observed. For any designated set of internal signals,
DUV responded to the simulati6n properly. This process is one can measure which pattems have occurred in
sometimes called spec tagging. It is very human-intensive simulation. Of course, not all patterns are reachable starting
and therefore expensive. Furthermore, directed simulation from the initial state so it is desirable to have a way to
only exercises.only a very thin set of design behaviors. approximate the reachable set and measure coverage
Directed random simulation is similar to directed relative to the approximation.
simulation except that certain fields, such as parts of an
instruction or data word of a transaction are randomized to Sequences of temporal events can be specified by
provide a more robust set of input stimulus. There are two temporal formulas. As mentioned earlier, there are various
advantages of random simulation over directed simulation. competing temporal assertion languages for expressing
The first is that hugely more stimulus can be generated by temporal formulas such as Open Vera Assertions (OVA),
one verification engineer, hence it is more cost-effective, Property Specification Language (PSL), and so forth.
and second, it has been discovered that many more These languages are used both for simulation monitors, for
interesting behaviors of a D W are observed by random fonnal verification properties to prove and for DUV
simulation and, hence design hugs are found sooner. environment assumptions -- either for simulation or formal
verification. In a later section, we will discuss systems that
A generalization of directed random generation is do a11 of the above things by sharing information.
constrained random simulation. In this case parts are
2 Hardware Emulation Verification The important thing to understand is that formal
assertion verification tools, that is, model checkers must
In a certain sense, hardware emulation is much like torally analyze the design. When a model checker says a
simulation only thousands of times faster. Because it is so property fails, it must produce a simulation trace from the
much faster, the bottleneck is to create test vectors fast initial state showing the failure. When it declares that a
enough to keep the emulator busy. If the test vectors are property is tme, the model checker is guaranteeing that no
generated by a host computer and then shipped into the valid simulation from the initial state can show that the
emulator, the bandwidth of the connection is the limiting property fails. That is why further simulation for this
factor for hardware emulation. The key is to generate property is not needed. Formal Verification is the only
enough work for the hardware emulator to keep it busy. approach to verification that can totally determine the
This can be done for full chip microprocessor emulation by correctness of a property. However, model checkers have
downloading software actually into the emulator and then historically suffered from the problem that they cannot
running programs, such as booting UNIX. handle really large designs well.

Another approach is to actually put the generation The main reason that model checkers have improved is
program itself in the emulator. Since another paper of this the rise of really good SAT programs from universities in
conference addresses this issue, we will not go into that the last few years, GRASP, CHAFF, SATO, and Berkmin to
here. Another method to keep an emulator busy is to do "in name a few. There are quite a large number of
circuit" emulation. At Motorola we did this with printer commercially available model checkers of various flavors.
driver controllers and with audio chips. The point is that So far there has still not been a huge commercial success
hardware emulators can he connected directly to an with model checking. Partly that is because the use of
application. such as a printer, and used to actually drive the assertions and constraints is not entirely routine in design
intended application. All this happens before the chip is verification. In a sense, the use of assertions and constraints
manufactured. is a paradigm change. Traditionally, using a golden model
has been more common. However, standard bus protocols,
3 Formal Verification Technology for example, USB, AMBA, SATA, RIO and so forth, has
facilitated the use of assertions. Standard bus interface
Clearly the most successful formal verification macrocells can be purchased from CAD Vendors.
technology is Boolean equivalence checking at the gate and
RT level of integration. There are at least two good The key ingredients needed to use model checking are
commercial equivalence checkers. In addition, there are a (1) the design to be verified, the D W , (2) an initial statc or
few niche programs to extract switch level models to gate/ set of initial states of the design, (3) one or more properties
RTL models for the purpose of equivalence checking. to be proven or disproved and (4) a formal representation of
However, since these programs are sensitive to switch level the environment of the design, that is, what the design
design style, large semiconductor companies usually have interacts with. The design is generally given by
their own programs for this purpose. Memory verification synthesizable Verilog orVHDL. Getting a good initial state
from switch-level models is handled by several commercial tums out to he a little troublesome. My experience is that
tools such as Innologic. The problem with memories is that for many blocks, designers do not know all the state bits of
typically traditional logic checkers don't handle them well an initial state. However, they generally do know how to set
because of the number of memory cells in the design. All the design to a good initial state by either asserting a reset
memory verification tools use Symbolic simulation, which signal or by introducing a synchronizing sequence to drive
was developed by Randall Bryant. the design into a good state. Both of these mechanisms can
be used to capture an initial state.
There have been great advances in formal assertion
verification tools (that is, model checkers) in the last five The most difficult problem is capturing 'an
years. The primary technology used in those tools are environment for the D W , The environment must, in
Binary Decision Diagrams (BDDs), Boolean satisfaction practice be synthesizable because the tool must creatc a
algorithms (SAT), ATPG algorithms (which are very formal model of the environment. There are various ways
similar to SAT algorithms), symbolic simulation and of doing this but none of these ways is really automatic,
various forms of abstraction refinement. There is still a lot they require human intelligence to understand how the
of academic work on model checking. environment responds, reacts and influences the D W .
Recently, an effective way has been found to create an
environment -- temporal assertions. One can essentially

3
define an environment by monitors (that is, assertions) )
which define the correctness of the interaction of the D W a s ~ rc-e-epindex-setup:
t FheFl\(e~epinde~setup);
and its environment. While defining the environment asselt c-e-epindea-in: check(e-epindex-in);
assert c-e-setup-ack: check(c_seluppck);
assenions correctly is not at all trivial, it is has been found
easier than building an environment in Verilog or VHDL
)
that defines the environment.
The simplest constraints involve only input signals.
4 Assertions and Constraints: A Synergy of For example, a constraint to express that inputs A, B and C
Technologies are one-hot is expressed by the purely combinational
Verilog formula:
An imponant aspect of environment assertions --
sometimes called constraints _-is that they can be reused in O+A+Bi€ = 1;
several ways. Constraints can he used to monitor
interactions between the D W and its true environment In this case, the inputs of the design, which determine the
during full chip simulation. They can be used to generate “next” state, may depend combinationally upon the current
simulations of the D W and they can also be used in formal signds of the design but only on the current signals in the
verification as we just described. Notice that flipping from design, not past signals. A more complex formula involves
monitor to generator (which is the same as flipping proof state of the DUV or a monitor:
obligation to assumption) enables assume/guarantee
methodology. That is to say, a constraint assertion can he (addr-state != ‘ADDR-IDLE) -> 1s-b;
used as an assumption about the environment of the DUV
when verifyin$ properties of the D W or generating In this case signals from the design or from an
simulation vectors. When the DUV is connected to its true auxilialy FSM monitor are use‘d to decide what the next
ewironniem, the sariie constraints can monitor the inputs to the design will be. Temporal property languages
interaction of the true environment with the D W in can also he used to capture these constraints implicitly.
simulation or can be used as a proof obligation on the Temporal properties.are compiled into monitors with “fail”
combined, environment plus O W , in formal verification. or “success” signals. In either case, explicit FSMs monitors
The multiple role of constraints and assertions means that or temporal constraints, the effect is to keep track of the
inforination can be gathered once from designers and used history on the interaction with the design and its
in many different ways. environment in order to decide what the set of next
allowable inputs are. The technical aspects of the semantics
The rollowing is an cxaniple USB assertion expressed and implementation of constraints can be found in
in thc OVA language. When a token packet issued by the [Kaufmann98].
host controller is accepted by the USB controller (DUT),
check that the content ofthe epindex register is correct. 5 A Few New Problems, New Technologies
The dpindcx[4:0] register fonnat is High level design and verification has been a goal of.
(~~~~.m~~ciion_cndpoii~t[;:O],tranraction~dircctlon)
the semiconductor design community for quite a while. In
uhrri. :
tnnsacfm_sndpoint==
the past, research has focused on high level language
!phy_~dst.l_cerrcnt[2 :O],phy~mdata_prcr[ 151) expansibility, simulation and synthesis. SystemC, for
tiaiisastion_dir~ciioll==0 if(pkt_typs ==(SETUP OR OUT)) examples, has been around for a number of years and has
== 1 if(p!.-t_type == IN) some dedicated adherents. However, most design houses
still use RTL models as the golden model of a design. At
module D\V-usbd [ the same time, those same companies define models in C or
clock poscdgc refclk ! Ctt- to give to their customers. This allows the customer to
w e n t ~ - ~ ~ I I , ~ ~ X _ S ifI ((usb_cl,k.token_plrt;t;lcccptld)
I U ~ : &&
use software models to develop driver programs for ‘their
(usb~chk.m_sctop_p~)) then ff I (usbZapp_cpindex==
chips before they actually have the hardware. It also allows
~ubhl.tok~~cl,ndp, I’hO) ):
cvsnt c_cpindexjn:
semiconductor companies to keep in touch with their
if ((ush-shli.tolren_p~it-lcccpled)&& (wi_chkmln_plt)) customers and show progress as the chip is being
then #I (osb2app-epindex == !osh_chlr.toli~en_endp,l’bl)): developed.
event e_cpindcx_out:I f ( ( o b _ F h k . t o k e n _ p k l ~ ~ ~ ~ ~ p
&&ted)
(ush_cbk.m-~utglrt)) I h a # I (urb2app_cpindex == However, one thing. that is lacking is a way to
lurb_chk.tok~nmdp,t’bO)): automatically and definitively compare the C/C++ models

4
(or SystemC or SpecC or. ..) with the RTL models. Intl. Conf. on Application of Concurrency to System
Equivalence checking technology succeeds to keep all Design, Aizu Japan, pp.8-15, 1998
models from RTL to gate to switch to transistor in
agreement. There is no such commercial tools thai works at [LahiriOl] S. Lahiri, C. Pixley, K. Albin, “Experience
higher levels, such as a transaction model of a design. So with Term Level Modeling and Yerification of the MCORE
high-level to RTL Verification is not a reality yet. Of Microprocessor Core”, IEEE High-Level Design
course, it is very appealing to verify assertions at the high Validation and Test Workshop Proceedings (HLDVT), pp.
level and then be sure that the verification holds also for the 109-114, November 2001.
RT level.
[Pixley961 C. Pixley, N. Strader, W.C. Bruce, J. Park,
This problem is similar to the problem of comparing M. Kaufmann, K. Shultz, M. Burns, J. Kumar, J. Yuan, J.
Instruction Set Architecture (ISA) models to RTL models. Nguyen, “Commercial Design Verification: Methodology
At Motorola, we did an experiment to compare an ISA and Tools”, Intemational Test Conference 1996.
model to a pipeline model of a small microprocessor. The
experiment used the uninterpreted function approach [Pixley901 C.Pixley, “A Coniputational Theoly und
pioneered by Burch and Dill and Randall Bryant. Our Implementation of Sequential Hurdware Equivalence”,
results were reported in [LahiriOl]. Since that time the tools CAV’90 DIMACS series, vo1.3 (also DIMACS Tech.
for using ininterpreted functions have been greatly Report 90-31), Ed. R. Kurshan and E. Clarke, ACM, June
improved in the EUCLID system <http://www- 1990.
Z.cs.cmu.edu/-uclidb from CMU.
[Yuan’99] J. Yuan, K. Shultz, C. Pixley, H. Miller, A.
Another technology that would be very useful is to Aziz, “Modeling Design Constraints and Biasing in
automatically and efficiently perform sequential Simulation Using BDDs”, Intl. Conf. on Comp. Aided
equivalence. A solution to this problem might impact Design (ICCAD), pp. 584-589, Nov. 1999.
synthesis which currently does not do much sequential
optimization. There is hope that techniques being [ShimimOZ] K. Shimizu, D.L. Dill, “Deriving a
developed in Professor Sakallah’s group at U. Michigan Simulation Input Generator and a Coverage Metric From a
and techniques from Professor K-T Cheng at U.C. Santa Formal Specification”, DAC, June, 2002.
Barbard might provide a solution to sequential equivalence.
[Iyer03] M. A. Iyer, “RACE: A Word-LevelATPG-Bused
6 Conclusions Constraints Solving Syslem for Smart Random Simulation”,
Proceedings of the International Test Conference,Sept.
Functional verification remains an unsolved problem. 2003 (to appear)
However, the last five years have shown progress on
several fronts: simulation (the rise of testbench tools and
assertioniconstmint based verification), emulation (putting
entire testhenches on an emulator) and formal verification
(SAT algorithms and bounded model checking) and
synergy (:constraint based verification) which allows
sharing among all three technologies.

7 References
[Kaufmann98] M. Kaufmann, A. Martin, C. Pixley,
”Design Constraints In Symbolic Model Checking”,
’ Computer-Aided Verification, pp. 477-487, 1998.

[Pixley981 J. Kumar, C. Pixley, “Logic and/imctional