Printer Friendly

Principles of functional verification for digital circuits.

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


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.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)


* 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:


The data flow consists in: (Figure 2.)


* 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




* 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


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


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: Accessed: 2007-08-03

Specman Tutorial (2007) Available from: page=specman_tutorial_p1#Introduction Accessed: 2007-08-03

Verisity (1998-2002), e Language Reference Manual Accessed: 2007-08-03 Available from:

Verisity, Specman Elite--Testbench Automation (2005) Available from: 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
Coverage Coverage plan

Table 2. Tests classification

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
 -generates tests that test
 writers may not take into

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
COPYRIGHT 2007 DAAAM International Vienna
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2007 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Rancea, Irina; Sgarciu, Valentin
Publication:Annals of DAAAM & Proceedings
Article Type:Technical report
Geographic Code:4EUAU
Date:Jan 1, 2007
Previous Article:Repairing of gear box with welding in the Kosovamont.
Next Article:Freedom of manufacturing by parallel batch production technical and economical advantages for microsystems.

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |