Functional Verification Methodology

Of a 32-bit RISC Microprocessor

Zhenyu Gu' Zhiyi Yu Bo Shen Qiunling Zhung
ASIC & System State Key Lab,
Fudan University, Shanghai, 200433, China

Abstract: With the increasing complexity of based verification is to select the propel strategy to
Microprocessor, the verification of the design becomes generate the testhenches.
. more and more important. This paper presented a
simulation-based functional verification methodology to The efficiency is low by using pseudo-random
validate a 32-hit RISC microprocessor (named as FDU32 generating method [6], as it generates a lot of redundant
below). In the paper, pseudo-random generating and testhenches. However, in spite of high focus and efficiency
pipeline-focus generating are used as the main method to by using pipeline-focus generating method [8,9], it does
generate testbenches. Besides, the whole verification not guarantee the reliability of the verification fox it could
environment is set up to improve the automation and not verify the non-pipeline case.
efficiency of the process. In addition, code coverage Considering the difficulty of achieving both high
analysis is used to guarantee the quality of the verification. efficiency and high reliability with a single verification
method alone, this paper presented a novel verification
Key words: RISC, functional verification, pipeline hazard, strategy that combines pseudo-random and pipeline-focus
pseudo-random, code coverage generating method, while the hand-write generating
method and the code coverage analysis is used as the
I. Introduction complement. In this way, both the high efficiency and the
high reliability can he ensured.
With the development of VLSI technology, more and
more microprocessors, with complicated structures and FDU32 is used as an example of the functional
verification under the corresponding verification
powerful functions, caE be implemented on a single chip. It
brings about a lot of troubles to the functional Verification environment (see as section 3). FDU32 is a 32-bit RISC
microprocessor compatible with ARM7 instruction set,
of the microprocessors.
which has 32-bit address bus and 32-bit data bus. FDU32
Now there are two major methods for the functional adopts a 5-stage pipeline structure: IF (Instruction Fetch),
verification of microprocessors, one is formal verification ID (Instruction Decode), EXE (Execute), MEM (Memory
[7], the other is simulation-based verification [6,8,9]. Operation), and WB (Write Back).
However, the formal verification has not yet available for The second pan gives a comparison between the
the functional verification of commercial products, the different verifica;ion strategies presented in this paper with
simulation-based method is still the prime method at other strategies; in section 3, the corresponding verification
present. environment is described; section 4 shows the verification
result of FDU32; ;n the last, the paper comes to a
Simulation-based functional verification applies conclusion.
testhenches to stimulate a design and a reference model
respectively, and the validity of the design can be known 11. Verification Strategy
by comparing the result. The key problem of simulation- Usually, in:,order to evaluate a verification strategy, a
processor model has to be set up first.
. .
* Corresponding author, Email: -

0-7803-7547-5/021$17.0002002 IEEE
1454
 A. Processor Model B. Comparison of Different Verification Strategy
The main factor considered in the processor modeling is In this section, the comparison between the efficiency of
that whether the model can be used universally. In other different generating methods is presented, including
words, the model should have the main character required pseudo-random generating, pipeline-focus generating, and
by the verification strategy while ignoring the details like combination of these two.
addressing range, and so on.
In the pipeline, each stage can b treated as an 1 , . . . . . . , .
09
,*.*'
independent function block named as pipeline unit. *+**
08
Consequently, the pipeline states can be defined as the
combination of these pipeline units, and a processor with
k-stage pipeline and n kinds of instructioiis has (n+l)'
pipeline states.
The instruction set of processor can be divided into four
kinds of instruction: DTI (Data Transformation Instruction),
DO1 (Data Operation Instruction), PCI (Program Control
I
- Instruction), and NOP (No Processing Instruction). I r m ZC! rm m srm m rn m m 1 m

Therefore, a 5-stage pipeline processor model has 5'=3125

pipeline states. Figl, Coverage of pipeline state for pseudo-random and
A 5-stage pipeline structure will naturally result in pipeline-focus generating method
pipeline hazards. Pipeline hazards [I] are the conflicts
caused hy using system resource like general register. Figure 1 demonstrates the coverage of pipeline states for
There are three classes of hazards: structure hazards, data pseudo-random generating method and pipeline-focus
hazards, and control hazards. The structure hazards arise generating method. Obviously, the pipelinefocus
when different instructions access to the same resource at generating method can cover all pipeline states in a
the same time; the data hazards arise when different relatively short time. Put it ano$er ;#ay, its efficiency is
instructions access to the same resource in an incorrect high.
order; and the contfol hazards can be viewed as a special
data hazards on the PC (Progam Counter).
with^ the description above, Equation ( I ) [8] can he
defined, which includes all kinds of pipeline hazards. In
Equation (I), H represents a set of instructions that will
result in pipeline hazards. I1 and i2 represent different
kinds of instructions, while sl and s2 represent the pipeline

:y, , F i
states held by the responsive instructions.
H=((sl, i l , s2, i2) I (il, SI) and(i2, s2) represent
instructions in different pipeline states) ( I ) t Rmdm
-- ~ ~ a mpieilns
~ d ~ m
According to Equation (I), MATLAB is applied to do PI , , ,

some statistical analysis., The result shows that the 0 111oammbmammmam¶nIm

processor model has 2366 pipeline states, which can cause
the pipeline hazards, namely 75 percent of the total Fig. Coverage of pipeline state for a wmbination of
pipeline states. Hence, the processor model is appropriate pseudc-random and pipeline-focus generating method
for the analysis of the effect of pipeline-focus generating
method.

1455
 However, pseudo-random generating method. still need need to be verified, and the amount of the testbenches is
to verify some non-pipeline-hazards which the pipeline- naturally bigger than that of first step, where both pseudo-
focus generating method can not verify. From figure 2, it random and pipeline-focus generating methods are applied
.shows that, the combination method produces a higher to verify the system. In the final stage, the handwrite
coverage and eficiency than using a single method. method is used to verify the comer case, and through the
code coverage analysis the uncovered code.is pointed'out.

-. 111. Verification Environment

^~-.-
*A' -
07
System Config
06

0.5
04

ai $
I

00 ,w w n am 4w 5nl sm, 7w twl ran 1 m

Fig3. Coverage of processor state (including pipeline and

non-pipeline state) for a combination of hand-write and
Compiler
. .
During the functional verification of the processor, to
verify the nqn-pipeline states with
. . auto-generating-method
is : difticuh, sometimes even impossible, for example.
arbitrating the propriety of different interruptions. ,As a
result, handwrite method has to be applied. The difference
between figure 2 and figure 3 is that the coverage shown in
figure 2 is the pipeline state coverage while the coverage
shown in figure 3 includes both non-pipeline and pipeline
states.
A-satisfied result could not be achieved w$h any single
technique to generate the testbeiiches. Therefore, in order
lo have the best efficiency and reliability of the functional
verification, different testbenchgenerating techniques have
to be employed during different stages.
C. Combination Verification Strategy
Based on the analysis above, this paper proposes a
Fig4. Verification environment
bottom-up, verification strategy, which has. three stages: at ~.
the beginning of the verification, the purpose is to verify ,Depending on the verification strategy,. an environment
the. basic function of each . module, and not many (shown .in figure 4), has been set up t.o implement the
testbenches are needed. Therefore, the handwrite method strategy. A command file is created to define the initial
,Em be used, which has a good focus. In the second stage, state and some control information. According to this file,
the overall function and the interfaces between the blocks the verification environment adopts the responsive method

1456
to generate the testhenches; the environment uses the V. Conclusion
compiler to compile the assemble program into the This paper presents a simulation-based functional
executive code. Then this code will stimulate both the RTL verification methodology of 32-bit RISC microprocessor.
level design and the C module; the environment will Through the verification result and FPGA verification
produce a result tile through which circuit designer could result of the FDU32, it is clear that by using the
learn whether the design is correct or not. combination-generating technique (including pipeline-
In addition, with the time-to-market limiting and the focus generating method and pseudo-random generating
complication of circuit design, it is impossible to exhaust method), the automation and efficiency of the verification
all testbenches during the functional verification. Hence, in process is greatly improved. Moreover, by handwrite-
order to guarantee the reliability of the functional generating method and code coverage analysis, the
verification, code coverage analysis is needed. This reliability of the verification is further enhanced.
method can provide the information of the uncovered code
of the design VI. Reference
D.A. Patterson and J.L. Hennessy, “Computer
. IV. Verification Result of FDU32 Architecture: A Quantitative Approach (Second
According to the verification 5trategy (introduced in Edition)”, MORGAN KAUFMANN, I999
section 2) and the verification environment (set up in W. Stallings, ‘Computer Organization & Architecture:
section 3), FUD32 was verified. Design for Performance (Fourth Edition)”,
PRENTICE HALL, I997
ARM7TDMI Data Sheet, ARM DDI 0029E,
Advanced RISC Machines Ltd (ARM) I995
ARM’ITDMI-S Technical Reference Manual, ARM
DDI 0084F, Advanced,RISC Machines Ltd (ARM)
2000
0 10 20 30 40 50 J. Bergeron, “Writing Testbenches-Functional
Verification of HDL Models”, KLUCYER
Figs, Bug-percentage found by different
ACADEMIC PUBLISHERS, 2000
testbench-generating methods.
S . Taylor and M. Quinn, “‘FunctionalVerification of a
Figure 5 indicates the bug percentage found by different Multiple-issue, Out-of-Order, Supencalar Alpha
testbench generating method. 38.9 percent bug is found by Processor-The DEC Alpha 21264 Microprocessor”,
pipeline-focus generating method, and 33.3 percent by IEEE Digital Automation Conference, pp.638-643,
pseudo-random generating method. In total, 72.2 percent I998
bug is found by auto-generating methods. V.A. Patankar, A. Jain and R.E. Bryant, “Formal
In view of the verification result above, code coverage Verification of an ARM processor”, IEEE I2lh
analysis is carried out to complement the verification, after Intevnational Conference on YLSI Design, pp.282-
which 14.3 percent bug is founded, including all the bugs 287. 1999
found by different testbench generating method. H. Iwashita, T. akata, and F. Hirose, “Behavioral
Later, during the FPGA verification of FDU32, little Design and Test Assistance for Pipelined Processors”,
design bug is founded, which reinforce the eficiency and IEEE The First Asian Test Symposium, p p . 8 - I i 1992
reliability of verification strategy proposed in this paper. H. Iwashita, S. Kowatari, T. Nakata, et al, “Automatic
Program Generator for Simulation-Based Processor
Verification”, Proceedings of ICCAD pp.298-303.
1994

1457