Previous Section Next Section

1.2 Verification Automation System with e

The e language contains all constructs necessary to support the activities of a complete verification automation system. Currently, the Specman Elite tool from Verisity Design[1] supports the e language. Other tools may support e in the future. Figure 1-3 shows the activities in a typical verification environment.

[1] Specman Elite is a tool that simulates e code standalone or in tandem with an HDL simulator. Please see http://www.verisity.com for details on Specman Elite.

Figure 1-3. Activities in a Verification Environment

graphics/01fig03.gif

The following subsections examine how e assists in each verification activity.

1.2.1 Generation

e automates the generation of stimuli. Test vectors are generated based on the constraints provided by the verification engineer. These constraints are typically derived from the functional and design specifications of the device and help define legal values for stimulus. Further constraints are derived from the test plan and help define specific tests. Figure 1-4 shows how tests are generated based on constraints. When a DUT is presented with an illegally constructed data stimulus, it will typically discard it without involving most of the logic in the design. Our verification goal is to exercise the entire design. Therefore, we need to make sure that most data stimulus items meet the requirements to "cross the wall" to the majority of the logic. These requirements are expressed as necessary relationships between object field values, or in other words as constraints.

Figure 1-4. Constraint-Based Generation

graphics/01fig04.gif

1.2.2 Driving Stimulus

After the test vectors are automatically created in the generation phase described in the previous section, these test vectors must be driven on to the DUT. e allows the drivers in a verification environment to be created in an object oriented manner. This allows maximum reusability. e syntax contains constructs to perform the following functions:

Figure 1-5 shows the components provided by e for driving the DUT.

Figure 1-5. Driving the Stimulus on to the DUT

graphics/01fig05.gif

1.2.3 Collecting Output

After the stimulus is injected into the DUT, output is produced from the DUT. This output must be collected and checked. e allows the receivers in the verification environment to be created in an object oriented manner. This allows maximum reusability. e syntax contains constructs to perform the following functions:

1.2.4 Data Checking

After the output data are received from the DUT, the data must be checked. There are two types of checks that need to be performed.

Data Value Checking

The list of bits received from the DUT must be compared against the expected data. To simplify the comparison, e has constructs that convert a list of bits to an abstract data structure. e also has constructs to aid in the comparison of abstract data structures.

The fields of the expected data structure and the output data structure are compared to determine success or failure.

Temporal Checking

Temporal checks simply mean "timing" checks. These checks ensure that protocol is being followed at each interface of the DUT. For example, if the protocol requires that a grant should follow a request within five clock cycles, this requirement is handled by temporal assertions. Temporal checking constructs are used to build protocol monitors.

Do not confuse temporal checks with the timing analysis of logic circuits, setup and hold delays, etc. Temporal checks are functional/protocol checks, whereas timing analysis of logic circuits contains checks in terms of setup and hold times.

Figure 1-6 shows two types of checks that need to be performed on the data.

Figure 1-6. Data Checking

graphics/01fig06.gif

The data checking method described in this section is just one example of a verification automation system. Another method that is very prevalent in central processing unit (CPU) verification is to use a reference model to check the output of the DUT. Both the CPU and the reference model are simulated in parallel and their outputs and register states are compared for equality.

1.2.5 Coverage Measurement

Functional coverage results tell the verification engineer if the test plan goals have been met. There are three types of functional coverage:

Basic Item Coverage

This coverage tells the engineer if all legal values of an interesting variable have been covered.

Transition Item Coverage

This coverage is used for state machines which form the control logic for any design. This coverage tells the engineer if all legal transitions of a state machine have been covered.

Cross Coverage

This coverage allows the engineer to examine the cross product of two or more basic or transition items to check if all interesting combinations of basic and transition items have been covered.

e contains constructs to specify all the above coverage items.

Code coverage is usually performed in addition to functional coverage. e provides a way of connecting to code coverage tools.

Previous Section Next Section