Previous Section Next Section

2.3 Components of a Verification Environment

A typical e based verification environment contains many different components. Figure 2-3 shows these components.

Figure 2-3. Components of a Verification Environment

graphics/02fig03.gif

Each component shown in Figure 2-3 above is defined as a struct (or a unit as discussed in later chapters).

2.3.1 Data Object

A struct is defined to represent a data object. This represents one test vector or one stimulus item. The data object contains fields that define the stimulus item. Different tests have variations in values of these fields. For example, in a router, the stimulus item could be a single packet. In a video application, the stimulus item could be a single frame. In a microprocessor, the stimulus item could be a single instruction. Specman Elite contains a random stimulus item generator that can automatically generate the value of a stimulus item based on certain constraints.

2.3.2 Test Creation

Tests are simply a set of constraints placed on the generation of the fields in the data object. If there are no constraints, the fields are selected randomly. If the constraints are very restrictive, the test becomes more and more directed. In e, there are no long task-based procedural tests that are very difficult to maintain.

2.3.3 Input Driver

A unit[5] is defined to represent a driver object. The driver object contains an input procedure to take one stimulus item and apply it to the DUT. The procedure must follow the interface protocol expected by the DUT at the input ports. In addition, the driver object also has a master procedure that calls the input procedure multiple times to apply many stimulus items to the DUT. Depending on the number of input interfaces, there may be multiple instances of the input driver.

[5] A unit is very similar to a struct but has some additional capabilities. A unit is used to define a static verification object that does not move through the verification system. A struct is a dynamic object or a data item such as instruction or packet that moves throughout the system. A unit is defined in greater detail in later chapters.

2.3.4 Output Receiver

A unit is defined to represent a receiver object. The receiver object contains a procedure to collect raw output from the DUT and convert it to a data object format. The procedure must follow the interface protocol expected by the DUT at the output ports. The receiver then passes this data object to the data checker to compare it against expected data.

2.3.5 Data Checker

A unit is defined to represent a data checker object. The data checker object gets an output data object from the receiver and compares it against the expected data. The data checker has a procedure to generate and store the expected data object. The data checker may be instantiated in the receiver object depending on the environment. Alternately, the data checker may be a central object instantiated directly under the verification environment.

2.3.6 Protocol Checker

A unit may be defined to represent a protocol checker object. Protocol checkers are monitors built using temporal assertions. The protocol checker object normally contains a set of rules that monitor the protocol at all important input and output interfaces. If the protocol is violated, the protocol checker issues a warning or an error. The declarative syntax of e makes it really simple to write these protocol checkers. The protocol checker can be designed as a centralized object or a distributed object depending on the architecture of the verification environment.

2.3.7 Coverage Analyzer

A unit may be defined to represent a coverage object. A coverage object defines a set of basic, transition, and cross coverage items to monitor upon specific events in the simulation. Coverage statistics are gathered in the coverage object during simulation. After the simulation is finished, a summary of these statistics is displayed. This summary helps the engineer analyze the untested areas and write new tests to cover those areas. The coverage analyzer can be designed as a centralized object or a distributed object depending on the architecture of the verification environment.

2.3.8 Verification Environment

A unit is defined to represent a verification environment object. Typically, all the objects defined above can be directly instantiated in the sys structure. However, it is better to encapsulate the verification environment by instantiating all the above objects under a special verification environment object. Then the verification environment object is instantiated in the sys structure. This makes the entire environment reusable and portable.

Note that all static objects related to the environment are defined as unit. Variable objects such as stimulus items are defined as struct. The difference between structs and units will be covered in later chapters.

Figure 2-4 shows the hierarchy of a typical verification environment. There may be multiple instances of each struct or unit depending on the structure of the design. Note that this hierarchy is separate from the design hierarchy in Verilog or VHDL.

Figure 2-4. e Verification Environment Hierarchy

graphics/02fig04.gif

Figure 2-5 summarizes how an e-based environment is partitioned. Specman Elite provides the constraint solver and the backbone to simulate with the e language. The DUT is simulated in Verilog or VHDL. All environments contain objects such as interface objects and system objects that are static in nature, i.e., they are written once as defined by the specification. Interface objects drive the data onto the DUT interfaces. System objects contain the high-level organization of various interface objects. These objects are declared as unit and are written once per project. Stimulus items are dynamic data objects whose fields might be varied many times in one test. Such data objects are defined as struct. Multiple tests are created by constraining the data object, interface object, and system objects.

Figure 2-5. e Verification Environment Partitioning

graphics/02fig05.gif

The following section discusses a small e example.

Previous Section Next Section