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.
The following subsections examine how e assists in each verification activity.
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.
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:
Interface with the simulator (Verilog, VHDL, SystemC, proprietary HDL simulator, hardware accelerator, or in-circuit emulator[2] )
[2] Though e is capable of interfacing with any software or hardware simulator, Verilog and VHDL simulators are covered in this book.
Coordinate all procedural code that drives the DUT
Conform to input protocol for DUT
Convert abstract data structures into a list of bits
Drive the bits onto the DUT
Figure 1-5 shows the components provided by e for driving the DUT.
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:
Interface with the simulator (Verilog or VHDL or SystemC or proprietary HDL simulator or hardware accelerator or in-circuit emulator)
Recognize the output protocol for DUT
Receive the bits from the DUT
Coordinate all procedural code that receives data from the DUT
Convert a list of bits into an abstract data structure for 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.
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 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.
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.
Functional coverage results tell the verification engineer if the test plan goals have been met. There are three types of functional coverage:
This coverage tells the engineer if all legal values of an interesting variable have been covered.
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.
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.