Principles of functional verification for digital circuits.

Rancea, Irina ; Sgarciu, Valentin

Abstract: The functional verification in electronic design automation is represented by the process of verifying that the logic design conforms to specification. The paper focuses on logic simulation: stimuli are provided to execute all the line of the HDL code. To accomplish the verification, a test-bench is built to provide scenarios to be checked. The simulation environment consists in: generator (generates inputs), drivers(translate the stimuli provided by the generator into inputs for the design under verification), score-boards database to be checked and different metrics of coverage. The case study presented in the paper uses Specman Elite as software tool for the verification environment and VCS as simulator.

Key words: simulation, verification, digital circuits, coverage plan

1. INTRODUCTION

The functional verification (FV) by its method of logical simulation is the task of verifying the logic before it is built on silicon. The literature offers different approaches for the FV: standard FV using Specman Elite or System Verilog or Vera, eRM Methodology, VMM Methodology. My research is focused on these methodologies and how can be them applied on a specific module. As case study I developed a verification environment at block level for a block called Statistics Engine, using Specman Elite and as verification tool and VCS as simulator. From the view of implementation, Specman Elite is a more stabile tool than System Verilog that is still new and many features from its Reference Manual are not yet supported by the VCS.

2. VERIFICATION METHODOLOGY

2.1 The Division of Verification

The effort for verifying a module is high, this being the reason for a division of it in many parts that are developed in parallel and in the end they will merge to the final scope of verification. There are known three approaches (Verisity 2005):

* Block level verification--realized on a block that represents a component of a complex module. Its scope is to offer a functional circuit, able to execute the expected functionality in the built environment(the environment does not communicate with other blocks; it communicates with abstract versions or models of the neighbor blocks)

* Chip level verification--realized on a chip that is assembled in the final version of logical blocks that represent the entire system. This level can be developed while the process of integration is on progress, so the verification and the design can grow up in parallel. Chip level verification offers a good guarantee that the circuit's functionality has been proved in conditions of an extern environment

* System level verification--realized on the entire system that will be used as final version with also the final version of application by the user

2.2 The Principles of Functional Verification

The process of verification consists in: (Fig. 1) (Meyer 2003)

[FIGURE 1 OMITTED]

* Create test in order to simulate the DUT's behavior

* Checking that the DUT's outputs corresponding to inputs stimuli are in concordance with the specifications of the DUT

* Coverage analysis in order to find out the areas uncovered by the tests

2.2.1 Separating the Verification Environment from Test Base

This separation means that one can modify the base test without to affect the verification environment. The benefits involved by this separation are: (Verisity 1998-2004)

* The verification environment remains stable

* The tests writers only need to know how the tests can be write; no knowledge of the verification environment are needed

* The tests can be developed in parallel

2.2.2 Specification Based Verification

This approach enables capturing the rules included in specifications (design/interface/test plan) and using them in the verification environment. The tasks of the verification are:

2.2.3 Generating Stimuli

One manner to define the set of input combinations for a given device is an n-dimensional space of 2n combinations, where n is the number of DUT input pins. Tests can be classified in:

2. CASE STUDY : << STATISTICS ENGINE << BLOCK

The data flow consists in: (Figure 2.)

[FIGURE 2 OMITTED]

* Command from microcontroller

* Command fetch phase (memory read)

* Execution phase

* Write back & response phase (memory write)

The Microcontroller commands are:

* STORE--the operations allowed: NOP, STORE, AND, OR, XOR, INC & DEC (cause the counter to cap), ADD, SUB, INCX& DECX (cause the counter to wrap).

* LOAD--return data from the memory at the address specified

* STLD--has two forms: STORE/LOAD and LOAD/STORE, Verifications goals: (Verisity 1998-2002; Specman Tutorial 2007)

Interface Protocols (Figure 3. Figure 4. and Figure 5.) Table

[FIGURE 3 OMITTED]

[FIGURE 4 OMITTED]

[FIGURE 5 OMITTED]

* Send all three commands: STORE, LOAD, STLD

* Check the input and output protocol

* Check if the memory initialization has been done

* Check that all the operations in all the format are done correctly (STORE and STLD commands)

* Check the two forms of STLD command

* Check that the block asserts interrupt when necessary

* Check cap/wrap for counters

Verification Environment

[FIGURE 6 OMITTED]

In order to accomplish the verification goals, the following kind of tests have been developed: (Table 3. Test Plan)

3. REFERENCES

Andreas Meyer (2003). Principles of Functional Verification, Publisher Butterworth-Heinemann, ISBN 0750676175

Janick Bergeron (2003), Functional Verification of HDL Models, Publisher Kluwer Academic Publishers, ISBN 1402074018

Specman Verification CookBook 2.0 Review (2007) Available from: http://www.specman-verification.com/ Accessed: 2007-08-03

Specman Tutorial (2007) Available from: http://www.specmanverification.com/tutorial.php? page=specman_tutorial_p1#Introduction Accessed: 2007-08-03

Verisity (1998-2002), e Language Reference Manual Accessed: 2007-08-03 Available from: http://www.ieee1647.org/downloads/prelim_e_lrm.pdf

Verisity, Specman Elite--Testbench Automation (2005) Available from: http://www.verisity.com/products/specman.html Accessed: 2007-08-03

Table 1. Specification based verification

Task Specifications

Generating input stimuli DUT specifications
Writing tests Test plan
Protocol checking DUT specifications or standard bus
 specifications
Coverage Coverage plan

Table 2. Tests classification

Test
Type Advantages Disadvantages

Directed -insure testing of specific -require a lot of resources
Tests area of interest to develop a test-base that
 covers a large input space

Random -can cover a large space of -may require multiple runs to
Tests inputs with limited effort generate specific points of
 interest
 -generates tests that test
 writers may not take into
 considerations

Table 3. Test Plan

 Nr. of
Test Type tests Description

Basic 2 check the memory initialization
Functional 26 check the DUT functionality
Stress 1 load data from the memory reiterated from the
 same address
Random 5 check all the format operation
 foe random operation codes