2009 Second International Conference on Information and Computing Science
A Study on the Assertion-Based Verification of Digital IC
Yangyang Li1*, Wuchen Wu1, Ligang Hou1, Hao Cheng2
1 VLSI &System Lab, Beijing University of Technology, Beijing, China
2 Electrical Engineering College, Zhengzhou University, Zhengzhou, China
* wowlyy@hotmail.com
Abstract—Verification plays more and more important role in
complex VLSI design. It has two main challenges: one is to
insure that the input stimulus can control the function spots
inside the design; the other is to insure the errors can be
observed from the design output. This paper presents an easy
approach of assertion-based verification (ABV) method by
dividing it into five steps, through which we embed assertions
in source codes to monitor key functional spots of the design
during simulation. As an application example, a case study of
functional verification for a UART model, using System
Verilog Assertion (SVA), is provided. The studied result shows
that the new method is feasible and can be applied in the
design and verification process to increase the observability of
the design.
Keywords- Observability; Assertion-Based Verification;
System Verilog Assertion; UART
I. INTRODUCTION
In complex IC design, verification takes about 70% of
the design develop time [1]. For even high speed IC design,
this portion is increasing still. Further, in the reuse-based
project, main blocks are recycled by using existing designs,
making more effort being shifted from the design stage to the
verification stage..
In this circumstance, to increase the efficiency of
verification, reducing the time consumption of verification
stage, is therefore crucial to speed the whole development
process up. But, the complexity of the designs makes it
difficult for engineers to recognize all the corner-cases. For
this reason, an effective method, to increase the observability
of the design and to easily find out and diagnose the design
flaws, is keenly needed. Assertion-based verification (ABV)
is such a method, which combines assertion, simulation and
formal techniques to the traditional function verification.
Assertion is used to describe the properties that a design
should hold or should never hold. Some properties with time
requirements are not easy to be described with Verilog, and
usually needs much more lines of codes with VHDL. There
are many standardized assertion languages such as PSL,
SVA [2] and assertion libraries such as OVL, QVL and 0-In
checkers [3], with which the endeavor for describing a
design property becomes much easier and efficient. Recently,
System Verilog Assertion (SVA), as a set of System Verilog
language, has been more extensively used as specification of
assertions within the design, enabling the simulator to check
the assertions during simulation.
978-0-7695-3634-7/09 $25.00 © 2009 IEEE
DOI 10.1109/ICIC.2009.114
II. SIMULATION-BASED SVA VERIFICATION
In the work of [3], the author summarizes seven steps of
formal verification planning process, which are demonstrated
by Harry Foster [4]. While because of the disadvantages of
formal verification, simulation is still the main method to do
functional verification currently. To apply this method in
simulation-based verification, we simply reduce and adjust
this method to five steps as follow:
A. List design interfaces.
B. List the inside functional spots.
C. List verification requirement for interface.
D. Formalize the properties with SVA
E. Define coverage spots
Following the five steps above, we can easily find the
design errors from the waveform window or just from the
log file of the simulation. When it comes to using the SVA to
describe the properties that we care, it is quite easy to debug
those errors. Because every individual assertion has a unique
name, and we usually embed those assertions into different
locations of the source codes. By examine the log file, we
can find both which assertion fails and the exact location of
this assertion in the source codes. The assertion is closed to
where the error occurs, thus we can easily find and debug
this error. Further, assertions usually are just used in
simulation and do not make up hardware resource, therefore
we just add as many assertions as possible into the design.
However, there are some research [5] on synthesis of
assertions and their application in FPGA prototype
verification recently. In these cases, we should only add
assertions when it is necessary. From the perspective of the
whole development flow of a new design, this method
increases the observability of the design therefore reduces
the debug time, and finally increases the possibility of
putting the design into market in advance.
III. CASE STUDY: UART
To investigate this method in real designs, we approach it
in the functional verification for a RTL model of a UART
which is the abbreviation for universal asynchronous
receiver/transmitter. It is a piece of computer hardware that
translates data between parallel and serial forms. UARTs are
25
commonly used in conjunction with other communication
standards. Transmitter reads parallel data from host and
transmits it in serial mode, while receiver examines the data
transmission, including whether data is received in serial
mode, whether the start bit and finish bit are got rid of and
whether the data is stored in parallel mode.
A. List the interface signals
As shown above, Fig. 1depicts the interface signals of the
UART Transmitter which consists of UART Controller, data
register, shift register and count register. In this step of
verification, we consider this design as a “black box”, which
means that we do not care the details about how to realize it,
while just check whether the interface signals accord with
the requirement of the design specification, especially for the
timing requirement. In this case, we check whether the
testbench generates valid stimulus for the Design Under
Verification (DUV).
B. List the inside functional spots.
In this step, we list the verification requirements for the
candidate module: the properties and the features inside the
module which need to be verified. One crucial component
for nearly every design is the control block, which is also
where some vital design errors occur. Thus control block is
what we should devote great effort to verify. In the UART Figure 2. State Transition Graph of Transmitter
transmitter, the control block is implemented by FSM (Finite
State Machine), therefore to examine if the FSM works C. List verification requirement for interface
exactly the same as what the design specification describes is In this step, we list the verification requirements for the
the key step for its functional verification. The general interface signals of the candidate module. As to the UART
verification for a FSM is to assure the transitions between transmitter, we check whether it works well with other
states are correct and follow the timing requirement [6]. Fig. blocks sharing common signals with it. Transmitter is the top
2 shows the state transition graph of UART transmitter. It is module of the design, thus we examine if the testbench
quite convenient to describe the timing requirements with generates valid input stimulus for DUV. To make the UART
SVA. transmitter work correctly, the testbench should provide
Table-1 shows the state transitions that need to be control signals in a proper sequence, as shown in Table 2.
verified. The first row represents the current state, while the This step is significant especially for a complex design
first column indicates the next state. Each check mark with several modules. After the unit level verification, we
indicates a state transition which should be verified. Besides need a system level verification, and that is why we separate
those simple pairs of state transitions, extra checks should this step with step B. Differentiating interface signals’
also be conducted, such as if a complete state transition flow properties from others can make us concentrate our effort on
is performed, which indicates UART Transmitter finishes a checking the coordination of different modules in system
complete data transmit. Or whether the states in the FSM level verification.
always sustain one-hot coding should also be checked.
TABLE I. STATE TRANSITIONS THAT NEED TO BE VERIFIED

State CURRENT STATES

Transitions
Others Idle Waiting Sending
N
E Others √
X
T
Idle √
S
T
Waiting √
A
Figure 1. Interface signals of UART transmitter T
E √
Sending
S

26
 TABLE II. INTERFACE SIGNALS’ FEATURES TO BE VERIFIED E. Define coverage spots
In this step, we define properties as functional coverage
Signals and their features spots. By using this method, we can analyze the assertion
Interface coverage as an indicator of the functional coverage.
Features Typically, there are two functions of assertion: one is serving
Relevant signals Expected features
as checker for a specific function; the other is being used for
Byte_ready=1 no less than one statistic analysis for coverage. To demonstrate this, take the
1 UART for example. We define all the properties mentioned
Byte_ready, reset cycle after reset is released
T_byte=1 no less than one cycle above as coverage spots. An example of how to describe an
2
T_byte, Byte_ready
later when Byte_ready is assertion and how to define it as a coverage spot is illustrated
asserted as Fig. 3.
When Load_xmt_datareg is We can check whether the transitions between pairs of
3 Load_XMT_datareg asserted, data_bus must hold
Data_bus valid data states are correct, and can also get the information
concerning how many of these state transitions are
4 … … conducted. In fact, this is also a kind of FSM coverage
analysis. By analyzing the coverage report, we can judge
D. Formalize the properties with SVA whether the verification is sufficient. Fig. 4 is the example of
run log file, according to the run time option of the
In this step, we convert each of the natural language
simulation process, the message shows the location, design
requirements into a set of formal properties using either an
scope, start and finish time and some of the coverage
assertion library or an assertion language. We can instantiate
message of the assertion. We can easily find the detailed
assertions from assertion library or express them with
message of the assertion, therefore it is quite easy to find the
assertion language (SVA).
location of an error and debug it. After defining assertion
In the latter case, we describe the functions to be verified
coverage spots, we can get the statistic analysis of every
with the combination of several logic events which can be
assertion, such as the number of over all attempts, matches,
described using SVA key word “sequence”. The simplest
vacuous matches, and fails.
logic event is a change on the value of a signal; a logic event
Fig. 5 shows part of the coverage report of the simulation
can also be a change on the value of a Boolean expression.
of UART. The simulation is terminated when every assertion
Then, we use the key word “property” to represent complex
has been matched for once. In fact, we can change the finish
behaviors of a specific function. Property is the unit being
time as, for example, when every assertion has been matched
verified during simulation, and the key word “assert” is used
for two times or more to make the verification more reliable
to check the property. Fig. 3 illustrate a complete SVA
and more completed.
checker, verifying if by given valid control signals sequences,
current state switches form “waiting” to “sending”, then
keeps as “sending” for nine clock cycles and finally stays at
the state “idle”.

sequence s_finish_sending;
##1 ((state==sending) [*9]) ##1 (state==idle);
endsequence
//Define a sequence

property p_finish_sending;
@(posedg Clock)
Figure 4. Part of run log file
(reset_)&&(state==sending)&&($past(state)
==waiting) |-> s_finish_sending;
endproperty
//Define a property

a_finish_sending: assert
property(p_finish_sending);
c_finish_sending: cover
property(p_finish_sending);
//Define a coverage spot

Figure 3. An example of a complete SVA checker Figure 5. Coverage Report

27
 Further, different severity levels can be attached to
assertions. If some assertions fail, according to their severity
levels, different measures are adopted, such as terminating
the simulation or just displaying the fail messages and
keeping on the simulation. Fig. 6 shows the waveforms of
design output, the upward arrows represent assertion success.
IV. CONCLUSION
In this paper, a five-step method is proposed in using
SVA for digital IC verification. The method is then invested
in the functional verification for a UART RTL Verilog
model. During simulation, the corner cases can be easily
checked and the design errors can be obviously exposed
through the simulation output (waveform or log file).
Furthermore, by this approach, the assertion coverage report
can be directly used for functional coverage analysis. The
result shows that the proposed method increases the
observability of design and is feasible for being applied in
both the design process and verification process of RTL
model.
Figure 6. Waveform of Design Output
28
REFERENCES
[1] Avi Ziv, “Cross-product functional coverage measurement with
temporal properities-based assertion”, Proceedings of the Design,
Automation and Test in Europe Conference and Exhibition, IEEE
Comput. Soc, Los Alamitos, CA, USA, 2003, pp.834 - 839
[2] System Verilog, IEEE Standard for System Verilog, IEEE Std. 1800-
2005.
[3] Ping Yeung and Sundaram Subramanian, “Applying Assertion-Based
Formal Verification to Verification Hot Spots”, Mentor Graphics
Technical Library, October 25, 2007
[4] Harry Foster, “Integrating Formal Verification into a Traditional
Flow”, Mentor Graphics White Paper, 2006.
[5] Michael Kantrowitz and Lisa M. Noack, “I’m Done Simulation; Now
What? Verification Coverage Analysis and Correctness Checking of
the DEC chip 21164 Alpha microprocessor”, Proceedings of 33rd
Design Automation Conference, IEEE, Piscataway, NJ, USA, 1996,
pp. 325-330.
[6] Srikanth Vijayaraghavan and Meyyappan Ramanathan, A Practical
Guide for SystemVerilog Assertions. Tsinghua University Press,
Beijing, China, 2006