Functional Verification Methodology

1
Functional Verification Methodology of a 32-bit
RISC Microprocessor (2002)
2
Outline

• Introduction
• Verification Strategy
• Verification Environment
• Results for FDU32

3
Introduction

• Development of VLSI technology and design of
  more µps with
• complicated structures that can be implemented
  on a single chip
• result in a lot of problems for Functional
  Verification (FV) of the
• µps.

• 2 major methods for FV of µps
• Formal Verification that has not yet available
  for commercial products
• Simulation-based Verification that is still prime
  method

• Method 2 applies TBs to a design and a reference
  model. Thus, selection of the proper strategy to
  generate TBs is important.

4
Introduction (cont.)

• In Simulation-based Verification for µps, TBs can
  be generated by using
• Pseudo-random method -gt efficiency is low
  (redundant TBs)
• Pipeline-focus method -gt reliability is low since
  it could not verify the non-pipeline cases

• This paper presents a verification strategy that
  combines
• pseudo-random and pipeline-focus generating
  methods.
• In this way, both the high efficiency and the
  high reliability
• can be ensured.

• FDU32 is used for this verification strategy
  that is a 32-bit RISC
• µp compatible with ARM7 instruction set which
  has 32-bit addr
• and data bus with a 5-stage pipeline
  (IF,ID,EXE,MEM,WB).

5

• Introduction
• Verification Strategy
• Verification Environment
• Results for FDU32

6
Verification Strategy

• In order to evaluate a verification strategy, the
  processor model has to be setup first.

• Processor Model
• Its better that the processor model be a
  model that can be used generally.
• Thus, the details such as addressing range
  have to be ignored.
• In the pipeline, each stage can be treated as
  an independent
• functional block named as pipeline unit.

• Pipeline States
• A processor with k-stage pipeline and n
  kinds of instructions
• has states.

7
Verification Strategy (cont.)

• Kinds of Instructions
• 1. DTI (Data Transformation Instructions)
• 2. DOI (Data Operation Instructions)
• 3. PCI (Program Control Instructions)
• 4. NOP (No Operation)
• Thus, a 5-stage pipeline processor model has
  states.

• A 5-stage pipeline structure will result in
  pipeline hazards.

• H(s1,i1,s2,i2) (i1,s1),(i2,s2) represent
  Inst. in diff. pipeline states

• By using MATLAB simulation it can be shown that
  2366 states
• can cause the pipeline hazards. Thus, the
  processor model is
• appropriate for the analysis of pipeline-focus
  generating method.

8
Verification Strategy (cont.)

• Comparison of Different Verification Strategies
• Efficiency of pipeline-focus is high, but it
  can not verify some non-
• pipeline hazards.

Fig. 2 Coverage of pipeline states for a
combination of two methods
Fig. 1 Coverage of pipeline states
for pseudo-random and pipeline focus methods
9
Verification Strategy (cont.)

• To verify the non-pipeline states with
  auto-generating method
• is difficult, sometimes even impossible, for
  example arbitrating
• the propriety of different interruptions.
  Thus
• Handwrite method has to be applied

• To have the best efficiency and
• reliability of the FV, different TB
• generating techniques have to be
• employed during different stages.

Fig. 3 Coverage of processor states (including
Pipeline and non-pipeline states) for a
combination of handwrite and auto-generating
methods
10
Verification Strategy (cont.)

• Combined Verification Strategies
• The 3-stage bottom-up verification strategy
• First step
• At the beginning of the verification, the
  purpose is to
• verify the basic function of each module,
  and not many
• TBs are needed. Thus, the handwrite method
  which has
• a good focus can be used.

11
Verification Strategy (cont.)
Second step The overall function and the
interfaces between the blocks are verified.
Both pseudo-random and pipeline-focus
methods are used. The amount of the TBs is bigger
than that of first step.
Third step The handwrite method is used to
verify the corner cases, and through the
code coverage analysis the uncovered
code is pointed out.
12

• Introduction
• Verification Strategy
• Verification Environment
• Results for FDU32

13
Verification Environment

• Depending on the verification
• strategy, an environment has
• been setup to implement the
• strategy (Fig. 4)

• A command file is created to
• define the initial state and some
• control information.

• Because of time-to-market
• limitation and complication of
• circuit design, its impossible to
• create the exhaustive TBs. Hence,
• in order to guarantee the reliability
• of the FV, code coverage analysis
• is needed.

Fig. 4 Verification environment
14

• Introduction
• Verification Strategy
• Verification Environment
• Results for FDU32

15
Results for FDU32

• According to verification strategy and
  verification environment,
• FDU32 was verified.

• 38.9 of bugs was found by
• pipeline-focus method and
• 33.3 by pseudo-random
• method, in total 72.2.

• Code coverage analysis was
• carried-out to complete the
• verification.

Fig. 5 The bug percentage found by different
TB generating methods

• During FPGA verification, little design bugs was
  found which
• reinforce the efficiency and reliability of
  the proposed VS.

16
Results for FDU32

• Conclusion
• Using a combined technique including
  pipeline-focus generating
• method and pseudo-random generating method,
  leads to great
• improvement on the automation and efficiency of
  the verification
• process.
• Using the handwrite generating method and code
  coverage
• analysis, leads to further enhancement of the
  reliability of the
• verification.

17
Any Question?