W H I T E P A P E R

The Four Pillars of

Assertion-Based Verification
Ping Yeung, Ph.D.
Principal Engineer
Design Verification and Test Division
0-In Verification Business Unit
Mentor Graphics Corporation
www. ment or. com
Authors Biography
Ping Yeung, Ph.D. is a Principal Engineer of the DVT 0-In Business Unit at Mentor Graphics,
Corporation. At 0-In Design Automation, Inc., Dr. Yeung was part of the core R&D team that
developed and introduced ABV technology to the industry. Dr. Yeung has over 15 years applica-
tion, marketing, and product development experience in the EDA industry, including positions
at 0-In, GenRad, Mentor Graphics, and Synopsys. He holds a Ph.D. from the University of
Edinburgh and three patents in assertion and formal verification.
Abstract
In this paper, we introduce Assertion-based Verification (ABV) and its four pillars of methodology.
These are fundamental technologies and methodologies that make the ABV process successful.
Each pillar targets a different phase of the overall design process; and each targets its own users
and objectives. The four pillars are:
Pillar 1: Automatic Assertion Check
Pillar 2: Static Formal Verification
Pillar 3: Simulation with Assertions
Pillar 4: Dynamic Formal Verification
The Four Pillars of Assertion-Based Verification 1
I. Introduction
System-on-chip (SoC) designs are becoming more complex for example, networking designs
need to handle more levels of protocol stack; communication designs must process more data at
faster line speeds; and graphics designs need to compute more sophisticated algorithms in hard-
ware so functional verification is becoming the dominant task in the integrated circuit (IC)
development process.
The design effort for complex ASICs has been able to scale linearly, by increasing design
reuse and adopting well-architected platform-based design approaches. Unfortunately, func-
tional verification has not benefited much from this approach
1,2
. As the number of functional
blocks in a SoC design increases, the amount of dependence, concurrency and interactions
increases exponentially. This problem was apparent when we worked recently with a customer
to verify a next-generation cellular platform
3
. Also, as the number of protocol layers increases,
exercising the deeply buried behaviors has become more difficult and it is harder to observe
many functionality issues. This problem was experienced by our customers who are transi-
tioning PCI/PCI-X based products to the multi-layer PCI-Express interface.
Functional verification is a critical and time-consuming task in any ASIC design schedule.
The ability to discover and diagnose deeply-buried design flaws is critical for design success.
Traditional simulation-based functional verification (using end-to-end tests) is good at validat-
ing baseline functionality however, it has been proven to be unreliable for detecting a lot
of corner-case design issues. The reasons why simulation alone cannot achieve a sufficient
level of robustness include:
The specification may not be complete (usually, it describes only the normal operating
behavior and omits abnormal behavior).
It is hard to set up all specified operations strictly from the chip inputs.
It is hard to check all specified behavior strictly from the chip outputs.
It is hard to locate the sources of bugs exhibited at the chip outputs.
Certain types of bug behaviors may not propagate all the way to the chip outputs.
Certain types of implementation errors are difficult to detect using functional tests.
Many directed tests are tailored specifically for one design architecture. Hence, they are sensitive
to design changes and they become ineffective, without being noticed. Additionally, implementation
errors are difficult to detect with normal functional tests. For example, consider problems resulting
from internal buffer overflow with unacknowledged transactions, incorrect arbitration under
extreme load conditions, and so on. Since verification engineers are unaware of implementation
details, these types of corner-case behaviors in the implementation will most likely be untested.
The more critical functional verification is to the overall development process, the more motivated
project teams are to find new and innovative ways to perform verification effectively and thoroughly.
As a result, many developers are curious about Assertion-Based Verification (ABV). However,
2 The Four Pillars of Assertion-Based Verification

what is ABV? What are the ABV methodologies? How can ABV be deployed successfully?
What are its returns?
In this paper, we describe the four basic techniques and methodologies for assertion-based
verification and how they can be deployed to accelerate the discovery and diagnosis of
design flaws during the verification process.
II. Assertion-Based Verification
The only way to advance significantly beyond traditional simulation-based verification is to
increase the observability and the controllability of the design during the verification process.
We can do this by using assertions and formal verification techniques in a process called asser-
tion-based verification (ABV). Assertions capture the design intent. By embedding them in a
design and having them monitor design activities, they improve the observability of the verifi-
cation process. Formal verification analyzes the RTL structure of a design. By characterizing
the internal nature of a design, formal verification augments controllability. Formal verification
can be used with or wihout simulation vectors. It targets corner-case behavior directly. When a
potential violation of an assertion exists, formal verification can show the scenarios in which
the violation can happen.
To build on top of the current simulation and testbench methodology, we introduce the four pillars
of assertion-based verification. These are the fundamental technologies and methodologies that
make ABV successful. Each pillar targets a different phase of the design process. Each has its
targeted users and objectives.
The Four Pillars of Assertion-Based Verification 3
Assertion-Based Verification
Simulation and Testbench Methodologies
A
u
t
o
m
a
t
i
c

A
s
s
e
r
t
i
o
n

C
h
e
c
k
S
i
m
u
l
a
t
i
o
n

w
i
t
h
A
s
s
e
r
t
i
o
n
s
D
y
n
a
m
i
c

F
o
r
m
a
l
V
e
r
i
f
i
c
a
t
i
o
n
S
t
a
t
i
c

F
o
r
m
a
l
V
e
r
i
f
i
c
a
t
i
o
n
III. Pillars of ABV
The four pillars of assertion-based verification are:
Pillar 1: Automatic Assertion Check
A set of pre-defined assertion rules is applied to the RTL code of the design to target common
netlist problems and design flaws. Whereas the traditional lint tools analyze the syntax and
semantics of RTL code, automatic assertion check synthesizes the design and employs formal
methods to analyze the internal structures of the design. No input is required from users. Many
common design flaws are detected quickly and easily with this methodology.
Pillar 2: Static Formal Verification
Designers add assertions to their code to capture design intent and to annotate their assump-
tions. As they do so, they get immediate feedback with static formal verification. Exhaustive
formal verification analyzes the assertions in a design determining whether they are true, false
or indeterminate. This analysis is static, which means analysis starts from a single unique state.
In many cases, the state after reset is used, so no testbench or simulation is required. However,
the initial state can also be derived from simulation. Static formal verification is usually per-
formed at the block level.
Pillar 3: Simulation with Assertions
User-specified assertions (and assertions promoted from automatic assertion checking) are
simulated with the design and the test environment. They passively monitor activities inside the
design and on the interfaces to ensure the design is working correctly. Whenever an assertion is
violated, it is reported immediately. The problem need not be propagated to the output ports for
it to be detected by the testbench. At the same time, the assertions collect coverage and statistics
information, which reflect how completely simulation exercises the functionality of the design.
Pillar 4: Dynamic Formal Verification
Formal verification analyzes the designs assertions and determines whether each is true, false or
indeterminate. Whereas static verification starts from a single state, dynamic formal verification
runs concurrently with simulation and leverages all simulation vectors. It identifies states close
to the assertions and performs local formal analysis about them. Dynamic formal verification
takes advantage of the design knowledge encapsulated in the simulation vectors to explore new
behaviors in the design instead of simply duplicating activities already performed by simula-
tion. Dynamic formal verification fills the gap between static formal verification and simulation.
4 The Four Pillars of Assertion-Based Verification

IV. ABV Processes
Assertion-based verification enables the design and verification team to work closely together
through the following processes.
Design for Verification
With intimate design knowledge, designers can capture design intent and assumptions with
assertions
15
. Embedded assertions capture design problems locally well before bug scenarios
propagate to the output ports. Leveraging existing regression environments provide better
observability into the design. With assertions, hard-to-verify logic and critical-coverage points
are identified. They help audit the quality of the testbenches and hence, identify holes in the
regression environment.
Coverage-Driven Verification
Coverage-driven verification is a methodology for verification closure. It improves verification
environments with directed-random stimulus generation. But if the coverage metric is weak
(such as code coverage alone) the verification specialist might get a false sense of security.
One commonly-asked question is: How good is the generated stimulus that tests the key func-
tionality of the design? To answer this question, it is important to augment the base coverage
metric with a measure of the coverage attained by the assertions (which represent the key
functionality of the design). Critical-coverage points, cause-and-effect implications, protocol
transaction coverage, and so on are good components of such an extended metric.
The Four Pillars of Assertion-Based Verification 5
High-level Specification
Verification Regression
Test Plan
Environment
Directed Tests
Design Spec
Architecture
Functional
Blocks
Divide-and-Conquer Verification
After the chip architecture is defined, internal interfaces and on-chip buses are finalized. At this
point, the testplan calls for the creation of interface protocol monitors. These monitors enable
each functional block to be verified individually, ensuring each does not violate its interface
protocol specification. These monitors can be leveraged as interface constraints, which are used
by static and dynamic formal verification to harden the functional blocks which is espe-
cially important for functional blocks that exhibit behavior hard to verify at the chip level.
Structural Verification
Simulation-based regression verifies end-to-end behavior well. However, many of todays
designs have implementation-specific structures that cannot be verified effectively with
simulation alone. One interesting example is the verification of asynchronous clock-domain
crossing (CDC) metastability effects. Simulating all the CDC signals to ensure a design has
no metastability problems is difficult. Fortunately, structural netlist analysis can ensure all
CDC signals are synchronized correctly.
V. Assertions
Assertions are vital to increasing both the observability and the controllability of a design.
Assertions capture knowledge about how a design should operate. Each assertion specifies
both legal and illegal behavior of a circuit structure (which can be an RTL element, an inter-
face, a controller, etc.) inside the design. There are two kinds of assertions: language-based
assertions and library-based assertions.
Good overviews of these assertions can be found in these books
15,16
. Other important charac-
teristics of these assertions are summarized in the table below:
Language-Based Assertions
Language-based assertions are written in a property description language with concise syntax
and clearly defined formal semantics. Two of the important ones are: Accelleras Property
Specification Language (PSL)
20
and the SystemVerilog (SV) Assertion
21
. Language-based
assertions are very flexible and capture the properties precisely.
Assertion Language Library In-line In-context External
VHDL assert yes language language
SV Assertion yes language language module binding
PSL yes comment module binding
OVL yes instantiate hierarchically
0-In Checkers yes comment comment module binding
6 The Four Pillars of Assertion-Based Verification

The assertion language, PSL, is design-language neutral; supports both VHDL and Verilog. It
is well suited for capturing temporal properties. SystemVerilog Assertion can only be used with
SystemVerilog code. However, users can leverage the procedural description of SystemVerilog
to capture complex hardware structures. Complex assertions and protocol monitors can be built
with both assertion languages however, users must learn and master the language first.
Library-Based Assertions
Library-based assertions overcome the learning curve presented by language-based assertions.
Library-based assertions capture commonly-used assertions in a library format. Several asser-
tion libraries are available: Open Verification Library (OVL)
22
from Accellera, SystemVerilog
Assertion Library from Synopsys and the CheckerWare library from 0-In
23
.
The OVL library is the most basic with about 30 elements. Synopsys offers a SystemVerilog
implementation of the OVL library with additional elements and enhancements it has roughly
50 elements. The 0-In CheckerWare library is the most comprehensive with about 70 elements.
It offers complex assertions that check many functional elements (such as scoreboard processes,
data integrity cases, arbitration schemes and clock-domain crossing protocols). It is the only
library that offers comprehensive coverage information with its assertions, which is essential
for performing coverage-driven verification.
Example
This simple example illustrates the different assertion approaches. The same assertion is
expressed in English and in code.
Assertion in English:
The DMA buffer should not overflow.
(i.e., when it is full, write should not happen)
Assertion in Verilog:
//synopsys translate_off
always @(posedge dma_clk) begin
if (fifo_full && fifo_write)
$display("DMA buffer overflow at time %d",$time);
end
//synopsys translate_on
Assertion in VHDL:
process (dma_clk) begin
if dma_clk'event and dma_clk = '1' then
assert not (fifo_full and fifo_write)
report "DMA buffer overflow" severity FAILURE;
end if;
end process;
The Four Pillars of Assertion-Based Verification 7
Assertion in SystemVerilog:
property dma_buffer_overflow;
@(posedge dma_clk)
not (fifo_full && fifo_write);
endproperty
assert property (dma_buffer_overflow);
Assertion in PSL:
property dma_buffer_overflow =
never ( fifo_full and fifo_write) @ (posedge dma_clk);
assert dma_buffer_overflow;
OVL Assertion:
dma_buffer_overflow assert_fifo_index
#(4, 16) // severity level, depth
(dma_clk, dma_rst, push, pop);
CheckerWare Assertion:
/* 0in fifo enq push deq pop depth 16 -severity 4
-name dma_buffer_overflow */
VI. Pillar 1: Automatic Assertion Check
Design for verification begins when RTL code is first created to implement the design ele-
ments. For maximum value, designers should perform automatic assertion check as they are
developing the RTL code. Whereas the traditional lint tools analyze the syntax and semantics
of the design code, automatic assertion check synthesizes the design and employs formal meth-
ods to analyze the internal structures. Many common design mistakes such as combinational
feedback loops, case semantics problems, synthesis-to-simulation mismatch problems and so
on can be found quickly with this methodology.
8 The Four Pillars of Assertion-Based Verification
Automatic
Assertion
Check
Some examples
Block-level checks:
Arithmetic overflow
Clock used as data
Case semantic error
Deadlock state
Unreachable state
Unreachable block
Index out of range
Chip-level checks:
Bus content
Combinational feedback loop
Incorrect clock-domain crossing
Missing synchronizer
Multiple driven net
Stuck at register
Structural analysis with pre-defined assertion rules
In addition, certain design structures such as clock-domain synchronization structures, bus
structures, finite state machines and so on are difficult to verify with simulation alone.
Automatic assertion check can recognize these structures. Sophisticated design rules
12
are
checked without using simulation, which is typically complicated and can easily be overlooked
by designers.
Common Issues Found
One common issue is design failure from asynchronous clock-domain crossing (CDC) problems.
Automatic assertion check can identify the CDC signals in the design. It then checks for the
absence of synchronization flops, incorrect combinational logic in the CDC path, reconvergence
of CDC signals and so on. Besides automatic checks, assertions are generated for simulation.
These promoted assertions ensure CDC signals are stable when they cross clock domains and
they are sampled correctly by the receiving registers
13
.
With coverage-based verification, the quality of the simulation suites is measured with respect
to simulation coverage. However in the RTL code, unused logic, stuck-at logic, unreachable
blocks and unreachable states distort the coverage metrics. Automatic assertion check identifies
such dead code, so that RTL models can be augmented before they are checked in for functional
simulation.
User Experience
One design team
4
reported that normal lint tools were not able to check all forms of CDC vio-
lations especially reconvergence errors with CDC signals. Traditionally, such problems were
found occasionally with timing simulation on the gate-level netlist and tracking down the prob-
lems took hours. With automatic assertion checks, reconvergence problems were detected early
in the design cycle. The team readily located the offending logic, fixed the synchronization and
re-ran CDC analysis to verify that the errors were fixed correctly.
Potential bus connection
Dead-end state Incorrect CDC crossing
(due to combinational logic)
ST0 ST1
data_a
clock_a
sel_a sel_b
clock_a
data_b
clock_b
clock domain A clock domain B
ST2
logic
The Four Pillars of Assertion-Based Verification 9
Summary
Benefits:
The assertion rules are pre-defined; the process is fully automated
Any violation represents a deviation from known good design practices
Best used for:
Block level before the RTL code is checked in
Chip level after integration
Designs with multiple asynchronous clock domains
Not good for:
Coding style and syntax checking (language-based lint tools are more suitable)
VII. Pillar 2: Static Formal Verification
Designers add assertions to their code in order to capture design intent and annotate their
assumptions. As they do so, they can get immediate feedback by running static formal verifica-
tion. Typically this step is performed at the block level, without devising any simulation vectors.
Formal verification synthesizes the block into an internal representation. By understanding the
internal structure of the design, formal analysis reports whether or not each of the assertions in
the design is satisfied. This analysis gives the designer unbiased feedback on the integrity of
their design. Static formal verification uses mathematical techniques to prove some assertions
true (given a set of assumptions) and other assertions false (by discovering counterexamples).
A proof means that static formal verification has exhaustively explored all possible behavior
with respect to the assertion and has determined it cannot be violated. A counterexample shows
the circumstances under which the assertion is not satisfied.
10 The Four Pillars of Assertion-Based Verification
Static
Formal
Verification
Static
Formal
Verification
Block A Block B
Static Formal Verification of user-defined assertions
The Four Pillars of Assertion-Based Verification 11
Each counterexample can be displayed in a waveform viewer. After understanding the circum-
stances, the designer corrects the RTL code (or determines the counterexample represents an
exceptional case not handled by the design). Using this methodology, a block can be verified
sufficiently before it is integrated into the system-level simulation environment.
Common Issues Found
Based on our users experiences, the most common bugs found with this methodology are related
to arbitration schemes, resource sharing, allocation and de-allocation of buses, interconnections,
buffers and memories in the designs.
Complex control logic is involved. For instance, in a multi-layer AMBAarchitecture, there is one
arbiter for each AHB bus, so exercising all possible combinations of request using simulation is
inefficient. But, formal verification can verify exhaustively that the arbiter does perform the spec-
ified arbitration scheme (by analyzing the internal structure of the design). Formal verification is
the right approach for this hot spot. In addition, once the arbiter is formally verified, the design
team no longer needs to worry about it in simulation. Alternatively, AMBAuses a central multi-
plexer interconnection scheme. By this scheme, a central decoder controls the multiplexor
which selects the slave that is involved in the transfer. Only one bus master is communicating
with one slave at any time. The logic involved in the AMBAinterconnection scheme is not com-
plex, however it is tedious to verify all possibilities one-by-one with simulation. By focusing on
the assertions, formal verification especially static formal verification can detect potentials
for resource conflict. If one is found, formal verification shows a waveform of the involved sig-
nals, such as HGrant, HSel and Haddress signals. In addition, formal verification ensures the
address decoder and memory map will generate the correct HSel signals for the slaves.
User Experience
Several arbitration scheme violations were found in multiple projects
11
. In one project, the AHB
bus arbiter implements a programmable priority arbitration scheme. However, the arbiter was
giving the grant to a wrong request under a certain complex combination of corner-cases. The
bus master was granted when the slave was not ready. Hence, the grant was sometimes given to
a different master first. When the original master requested again after the slave was ready, it
was not given the grant at the correct time.
In microprocessor designs, each one-hot multiplexer is usually implemented with pass transis-
tors connecting separate input signals to a common output. Two-pass transistors must never be
enabled at the same time; otherwise the resulting current could damage the chip. Since a single
multi-million gate design can have tens of thousands of one-hot multiplexers, static formal ver-
ification is the only viable solution. As a tape-out criterion, a company
10
uses it to prove that
the select lines for all the pass transistors are always mutually exclusive.
Summary
Benefits:
Exhaustive formal analysis is performed on the concerned areas of the design
Verification can be done at the block level, independent of the simulation environment
Best used for:
Arbiters, controllers, complex control logic and IP blocks
Potential areas of conflict, such as resource sharing, allocation and de-allocation of buses,
interconnections, buffers and memories in the design
Not good for:
Interface logic (as constraints are required to define the legal inputs)
Structures with long latency, such as Ethernet MAC interface, elastic buffers, etc.
VIII. Pillar 3: Simulation with Assertions
Assertion-based verification leverages the existing simulation environment. When running
with functional simulation, assertions monitor activities inside the design and on the interfaces.
Whenever an assertion is violated, it is reported immediately. The problem need not be propa-
gated to the output ports for it to be detected by the testbench. Hence, assertions improve the
observability of the design. High degree of observability simplifies bug triage and allows
the cause of any violation to be isolated easily.
The verification team creates directed tests based on a high-level specification of the design.
In most cases, these tests do not stress the corner-cases and the critical structures of the design
sufficiently. With assertions, designers can identify hard-to-verify logic and critical coverage
points inside the design. During simulation, these assertions serve as coverage monitors: they
collect statistics and coverage information ensuring the concerned areas are well stimulated.
They supply an important component of the metric for coverage-driven verification. To quote
one project manager: Assertions provide a way for designers to tell their verification team
what they are worrying about and where potential logic problems are.
12 The Four Pillars of Assertion-Based Verification
Simulation with Assertion Checkers
S
t
i
m
u
l
u
s

G
e
n
e
r
a
t
i
o
n
R
e
s
p
o
n
s
e

C
h
e
c
k
i
n
g
For example, an arbiter checker reports the number of requests and grants:
Arbiter checker coverage statistics
240:Requests and Grants
120:Requests
120:Grants
1:Fastest Grant Time (in cycles)
1:Slowest Grant Time (in cycles)
1:Maximum Requests Outstanding
0:Current Requests Outstanding
2:Requests Asserted
00101:Requests Asserted Bitmap
2:Grants Asserted
00101:Grants Asserted Bitmap
An AHB target protocol monitor reports the number of {read, write, busy, idle} transfers, the
burst types and the number of {okay, error, retry, split} responses.
AHB target monitor coverage statistics
361:Total Transfers
71:Read Transfers
77:Write Transfers
213:IDLE Transfers
0:BUSY Transfers
340:OKAY Responses
20:ERROR Responses
0:RETRY Responses
0:SPLIT Responses
17:SINGLE Burst Type
31:INCR Burst Type
34:WRAP4 Burst Type
18:INCR4 Burst Type
0:WRAP8 Burst Type
16:INCR8 Burst Type
0:WRAP16 Burst Type
32:INCR16 Burst Type
90:Byte (8 Bits) Transfer Size
18:Half Word (16 Bits) Transfer Size
40:Word (32 Bits) Transfer Size
With this information, the verification team identifies holes in the test suites and audits the
completeness of their regression environment.
The Four Pillars of Assertion-Based Verification 13
Common Issues Found
The most common issues found with this methodology are inter-module communication and
interfaces compliance problems. When design teams first integrate all the blocks for chip-level
simulation, the blocks may fail to talk to each other. The main cause of these problems is:
designers understand the interface specifications differently from the verification team. Even
when the specification is understood correctly, assumptions made by each designer might con-
tradict each other. However, when the interface specification is captured with assertions, they
become an executable reference. When used with simulation, they pinpoint modules that cause
any protocol violation.
Alternatively, designs with standard interfaces such as AMBA, PCI-Express, Hyper Transport,
DDR SDRAM, etc. can leverage the standard protocol monitors already available from the
vendors, such a
17
. A well-designed protocol monitor also enables users to perform end-to-end
verification. In a bus bridge design, with coverage and statistics information from the protocol
monitors, we can ensure the number of transactions received equals the number of transactions
sent, at both sides of the bridge.
User Experience
Several companies have published their successes using assertions with the coverage-driven
verification methodology
5,6,8
. In general, directed tests are suited for functional verification, but
they often miss corner-case bugs due to complex combinations of events. As presented in these
papers, project teams are moving from directed tests to directed random and fully random veri-
fication environments
5
. High-level verification languages such as Verisitys e
18
or Synopsyss
Vera
19
are used.
But, randomly-generated stimulus presents two shortcomings:
Stimulus might inadvertently focus on one part of the design while overlooking another
A simple mistake in the stimulus generator code can create a huge amount of useless stimulus
(which does not help the coverage goals at all)
To uncover such potential problems, RTL code coverage traditionally was used to provide quality
feedback on the stimulus. Although code coverage is a good base-line measure, it is not sufficient.
Assertions that identify critical coverage points buried deep inside the design provide the best indi-
cators. In
5
, assertions are used as functional coverage monitors. In
6
, coverage information from
assertions is used to create a reactive testbench. In
8
, assertions are used to audit and fine-tune the
stimulus generation process.
Summary
Benefits:
Technology integrates seamlessly with the current simulation environment
Simulation is made more productive with improved observability
14 The Four Pillars of Assertion-Based Verification

Best used for:
Standard interfaces, on-chip buses and well-defined interfaces in the design
Deeply buried hard-to-reach logic to ensure sufficient testing is performed
Critical coverage points to guide verification or directed random environments
Not good for:
Code coverage and state machine coverage (coverage tools integrated with the simulators
provide this information with much lower performance overhead)
IX. Pillar 4: Dynamic Formal Verification
To create interesting test scenarios, the verification team embodies much knowledge of the
designs function and expected behavior into the simulation vectors. Dynamic formal verifica-
tion takes advantage of this knowledge and explores new behaviors in the design instead of
simply duplicating activities already performed by simulation.
Dynamic formal verification bridges the gap between formal verification and simulation.
Starting from each simulation cycle, dynamic formal verification uses the internal states gener-
ated by the test vectors and tries to find potential violations of the designs assertions.
For example, suppose at simulation cycle N the FIFO has four entities. Formal analysis will
determine whether or not the FIFO will overflow. However, we do not want formal analysis to
spend too much time at any particular cycle. If the FIFO is full at say 16 cycles later, it is much
easier to overflow it at cycle (N+16).
So instead of performing deep formal analysis at one particular cycle, dynamic formal verifica-
tion skims through the simulation vectors, performing shallow formal analysis. As a result,
dynamic formal verification is good at agitating the design with external events and stress-test-
The Four Pillars of Assertion-Based Verification 15
Dynamic Formal Verification
Dynamic Formal Verification
of Assertion Checkers
ing corner-case behaviors. The process is like introducing randomly-timed stimuli
7
with deter-
ministic guidance from formal analysis. If a violation is discovered, formal analysis provides a
counterexample to the assertion. Since stimulation stimulus is leveraged to find the violation,
the counterexample is part simulation stimulus and part formal stimulus. Although dynamic
formal verification is not completely exhaustive, it can handle large designs (i.e. at the chip-
level). In addition, by providing the corresponding simulation vectors, users can guide or focus
formal analysis on specific concerned areas in their designs.
This methodology has been used extensively to find corner-case bugs that are too deep or com-
plex to reach with static formal verification. Most of the issues found with dynamic formal ver-
ification require a long setup time in simulation. For example, when a linked list manager is
close to filling up all the storage space, back pressure should be generated. However, suppose
the manager is late in asserting the back pressure signal. The next incoming packet will be cor-
rupted when the manager tries to store it. It is impossible for formal verification alone to gener-
ate thousands of packets to fill up the packet memory. However, dynamic formal verification
leverages what simulation has already done and amplifies the test.
Common Issues Found
Dynamic formal verification has been used extensively to verify bus bridge designs (such as
AHB to AHB, AHB to PCI, PCI-Express to PCI-X, and numerous standards to propriety inter-
nal buses). It is impossible to simulate all combinations of incoming and outgoing transactions
with the full range of timing parameters. Normally, functional simulation has verified the
generic read and write transactions extensively. However, for the abnormal transactions such as
abort, and retry, we have seen numerous cases where the bus bridge has failed to function prop-
erly. As a result, the transaction was lost forever.
Dynamic formal verification fills this gap. By leveraging the transactions already performed
by simulation and by understanding the control logic inside the bus bridge, formal verification
ensures the bus bridge understands all incoming transactions correctly. The tool checks the
design to determine whether there is any possibility that a transaction will not be transferred
correctly from one interface to another.
On several occasions, we have noticed insufficient stress testing is done at the transaction level.
For instance:
The AMBA specification states that an ERROR response requires at least two cycles. When
examining the ERROR responses in simulation, we noticed that only 2-cycle error responses
were being performed. As a result, we do not know whether the bus master could handle error
responses that take longer than two cycles.
In a verification environment with a PCI-Express interface, we noticed that considerable
effort was spent building a directed random stimulus generator at the high level. Interestingly,
it assumed that the link initialization and training process is always performed flawlessly.
16 The Four Pillars of Assertion-Based Verification

User Experience
Many design teams use dynamic formal verification to verify the correctness of bus interfaces
and implementation. With the availability of standard protocol monitors
17
, this can be set up
and done fairly seamlessly. Some of these successes have already been documented in pubic
forums.
In one case, dynamic formal verification was used to verify a DMA controller, which is not
easy to verify exhaustively. DMA channels are allocated/de-allocated dynamically and data
transfers are interleaved among channels. Formal verification found a rare situation where data
in memory is corrupted. The problem occurred when more than one channel finishes their
transfers at the same time. During the de-allocation process, one channels address pointer is
de-allocated twice and the other channels pointer is not de-allocated at all. As a result, when
the same channel is allocated again, corrupted data is transferred. In this design, DMA channels
will never be allocated together because their access is controlled by an arbiter. However, mul-
tiple channels can finish data transfer at the same time. The designer did capture this corner-
case with an assertion. However, it was so difficult to make this happen in simulation that the
assertion was never exercised.
In another project, dynamic formal verification was used to verify an Ethernet MAC interface
4
.
Control logic in the design should control the processing elements so that they have fair and
non-conflicting access to a pool of resources. However, formal analysis uncovered a legal sce-
nario under which certain resources were granted in an incorrect order. When the access order
is wrong, the memory system could be corrupted and the system could hang. This example
highlights the power of dynamic formal verification an Ethernet frame is over 1000 cycles
long. It is inefficient for static formal verification to drive a frame into the design. However,
dynamic formal verification can take advantage of what simulation has done already.
Summary
Benefits:
Dynamic formal verification leverages and amplifies the activities covered by normal simula-
tion runs
By understanding the design, formal analysis finds ways to explore some hard-to-reach corner
cases
Late stage bugs were found with this methodology before tape-out
Best used for:
Control logic for standard interfaces, on-chip bus interfaces, memory interfaces, etc.
Designs with long latency such as: Ethernet MAC, DMA controllers, memory controllers,
bus bridges, etc.
Designs with serial interfaces, such as PCI-Express, SAS, etc.
Not good for:
Datapath and algorithmic verification
The Four Pillars of Assertion-Based Verification 17
X. Conclusion
Assertion-based verification is a shift in verification methodology. Traditional functional verifi-
cation tries to stimulate the design and observe the responses from the outside. As todays
devices become more complex, multi-functional and integrated, observability and controllabili-
ty are so low that pseudo-random simulation can no longer exercise the internals of the device
sufficiently. ABV technologies and methodologies are hence developed to zero in to the struc-
ture of the design.
As a result, the responsibility of verification is also shifting from over-the-wall verification
team to involve designers as well. Design knowledge becomes a critical criterion for successful
functional verification. With assertions, we can detect bugs sooner; with formal verification, we
have more direct control of the verification effort.
The four pillars of ABV help project teams understand the point-of-insertion and hence deploy
ABV methodologies successfully.
Four Pillars of ABV Deployment Methodology
Automatic
Assertion Check
Best used by designers at the block level before checking
in the RTL code
Finds semantic and netlist issues that are difficult to detect with
simulation (e.g. indexing, combo loop, CDC)
Static Formal
Verification
Best used at the block level to verify control logic even before
simulation environment is ready
Find bugs sooner; capture assumptions as constraints;
harden block for unexpected environment
Simulation with
Assertions
Designers add assertions, verification team adds interface
monitors and runs with chip-level regression environment
Ensures regression verifies the concerned areas of the design;
provides coverage feedback to improve verification
Dynamic Formal
Verification
Best used to verify multiple blocks together, blocks with many
interactions and hard-to-reach areas of the design
Leverages chip-level simulation to verify deeply-buried
corner-case behaviors not reached by simulation
18 The Four Pillars of Assertion-Based Verification

References
1. Verification Strategies for Integrating 3G Baseband SoC, Yves Mathys, Motorola SPS, DAC 2003.
2. High Level Formal Verification of Next-Generation Microprocessors, Tom Schubert, Intel, DAC 2003.
3. Core-based ASIC at Samsung, Chang Hyun Cho, Samsung Electronics, Keynote Speech, The 2002
International Technical Conference on Circuits/Systems, Computers and Communications.
4. Assertions Enter the Verification Arena, Frank Dresig, Alexander Krebs, Falk Tischer, Dresden Design
Center of AMD, Chip Design Magazine, Dec 2004.
5. Coverage and Assertion-Based Verification Coverage Based DV from Testplan to Tapeout using Random
Generation and RTL Assertions, Carey Kloss, Dean Chao, Cisco Systems, DVCon 2004.
6. An Efficient Reactive Testbench with Bug Identification Structure, Namdo Kim, Byeong Min, Samsung
Electronics, DVCon 2004.
7. Audit Your Design to Assess and Even Reduce the Amount of Random Testing Needed, Dan Joyce, Ray
Harlan, Ramon Enriquez, DVCon 2003.
8. 0-In ABV Success Cases, Mr.Masami Iwamoto, Fujitsu LSI Technology, EDATechnoFair 2003.
9. DVCon04 Trip Report, John Cooley, www.deepchip.com/posts/dvcon04.html
10. Sun System News, Vol 71, Jan 5, 2004, sun.systemnews.com/articles/71/1/hw/11871
11. Assertion-based Verification for ARM-based SoC Design, Ping Yeung, DesignCon East, 2004.
12. Synthesis and Scripting Techniques for Designing Multi-asynchronous Clock Designs, Clifford
Cummings, Synopsys Users Group Conference, San Jose 2001.
13. Using Assertion-based Verification to Verify Clock Domain Crossing Signals, Chris Kwok, Vijay Gupta
and Tai Ly, DVCon 2003.
14. Deep Formal Verification Powers Assertions, Curtis Widdoes and Richard Ho, EEDesign, 18 April, 2002.
15. Assertion-based Design, Harry Foster, Adam Krolnik, David Lacey, Kluwer Academic Publishers, 2003.
16. Using PSL/Sugar with HDL for Formal and Dynamic Verification 2nd Edition, Ben Cohen, Srinivasan
Venkataramanan and Ajeetha Kumari, VhdlCohen Publishing.
17. CheckerWare Monitors, 0-In website: www.0in.com/products_monitors.html
18. Specman Elite, Verisity website: www.verisity.com/products/specman.html
19. VERA Tool, Synopsys website: www.synopsys.com/products/vera/vera.html
20. Property Specification Language (PSL), Accellera, www.eda.org/vfv
21. SystemVerilog, Accellera, www.eda.org/sv
22. Open Verification Library (OVL), Accellera, www.eda.org/ovl
23. Assertion-based Verification V2.2 User Guides, 0-In Design Automation, 2004.
The Four Pillars of Assertion-Based Verification 19
Corporate Headquarters
Mentor Graphics Corporation
8005 S.W. Boeckman Road
Wilsonville, Oregon 97070USA
Phone: 503-685-7000
North American Support Center
Phone: 800-547-4303
Fax: 800-684-1795
Pacific Rim
Mentor Graphics Taiwan
Room 1603, 16F,
International Trade Building
No. 333, Section 1, Keelung Road
Taipei, Taiwan, ROC
Phone: 886-2-27576020
Fax: 886-2-27576027
Europe
Mentor Graphics
Deutschland GmbH
Arnulfstrasse 201
80634 Munich
Germany
Phone: +49.89.57096.0
Fax: +49.89.57096.400
Silicon Valley
Mentor Graphics Corporation
1001 Ridder Park Drive
San Jose, California 95131 USA
Phone: 408-436-1500
Fax: 408-436-1501
Japan
Mentor Graphics Japan Co., Ltd.
Gotenyama Hills
7-35, Kita-Shinagawa 4-chome
Shinagawa-Ku, Tokyo 140
Japan
Phone: 81-3-5488-3030
Fax: 81-3-5488-3031
For more information, call us or visit: www.mentor.com
Copyright 2004 Mentor Graphics Corporation. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient
for internal business purposed only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent the unauthorized use of
this information. Mentor Graphics is a registered trademark of Mentor Graphics Corporation. All other trademarks are the property of their respective owners.
C&A 11-04 TECH6490-w