Previous Section Next Section

11.1 Verification Components

Multiple components make up a verification environment. Figure 11-1 shows the components in a typical verification environment. This section describes how various verification components are built and the e constructs that are needed to build these verification components.

Figure 11-1. Components of a Verification Environment

graphics/11fig01.gif

The information provided in this section is a guideline for creation of verification environments. Actual verification environments will vary slightly depending on the needs of the particular project.

11.1.1 Data Object (Stimulus Generation)

The generation aspect of verification contains data objects. These data objects are structs that represent the abstract form of input stimulus. Data objects can be built with the following e syntax.

11.1.2 Driver Object (Stimulus Driver)

The driver object performs the function of taking the stimulus data object one instance at a time and applying it to the DUT until all stimulus has been applied. Typically, the interface object is similar to an HDL bus functional model. In case of a networking environment, it is also known as a port object. Figure 11-2 shows the typical design of a driver object.

Figure 11-2. Driver Object Design

graphics/11fig02.gif

There can be more than one driver object in the design. Typically, there is one driver object per input interface. If there are multiple input protocols supported by the DUT, each has its own driver object. Here are some characteristics of driver objects:

11.1.3 Receiver Object (Output Receiver)

The receiver object is responsible for collecting the data at the output of the DUT. The receiver object performs the function of taking the raw output data from the DUT based on the output protocol and converting it to an abstract data object for comparison. Typically, the receiver object is similar to an HDL bus functional model. Figure 11-3 shows the typical design of a receiver object.

Figure 11-3. Receiver Object Design

graphics/11fig03.gif

There can be more than one receiver object in the design. Typically, there is one receiver object per output interface. If there are multiple output protocols supported by the DUT, each has its own receiver object. In certain protocols, the driver and the receiver objects might be combined into one object. Here are some characteristics of receiver objects:

11.1.4 Data Checker Object (Expected Value Comparison)

The data_checker object stores expected values for each input data object injected into the DUT. The expected values are computed by applicaion of the transformation algorithm to the input data objects. This transformation algorithm is identical to the one applied to the input stimulus in the DUT. When the receiver object receives one data object, it passes it to the data_checker for comparison against the expected values. Figure 11-4 shows the typical design of a data_checker object.

Figure 11-4. Data Checker Object Design

graphics/11fig04.gif

Data_checker objects may be instantiated in the receiver object. In such cases, there is one data_checker object per receiver object. Here are some characteristics of data_checker objects:

Scoreboarding is a common technique to perform such comparisons. Scoreboarding is a general verification technique. It is not specific only to e-based verification. Figure 11-5 shows a typical scoreboarding methodology that can be developed using e. In Figure 11-5, the data item is added to the scoreboard as soon as it is applied to the input of the DUT. When the output is received, the output is compared to the data item on the scoreboard.

Figure 11-5. Scoreboarding Methodology

graphics/11fig05.gif

11.1.5 Monitor Object (Protocol Checker)

A monitor object checks the input and output timing protocol. Here are some characteristics of a monitor object:

11.1.6 Coverage Object (DUT and e Coverage)

A coverage object sets up coverage tracking on key items in the e code and in the DUT. Some coverage objects can also be embedded in the extension to a driver or receiver object. Here are some characteristics of a coverage object:

11.1.7 Tests

Tests are derived from the test plan. In e, tests are simply extensions of existing struct and unit definitions that impose additional constraints on these objects. Test files are very small and are easy to write and to maintain.

11.1.8 Env Object (Environment)

Often, a verification environment that is designed for a module will be needed at the chip level and at the system level. All verification components discussed in this section should be automatically transported to a different level of verification. Therefore, instead of directly instantiating these components in sys, create an intermediate level of hierarchy called env under sys. All verification components are instantiated under env. Thus, one can transport env to any other level of hierarchy without having to transport each individual verification component. Figure 11-6 shows the hierarchy with the env object.

Figure 11-6. Environment Object Hierarchy

graphics/11fig06.gif

Previous Section Next Section