Previous Section Next Section

5.1 Basic Concepts of Generation

Generation is the process that automates the selection of values for fields and variables (data items). During the generation phase, the entire tree of instances under the struct sys is generated. Data values are assigned to all fields. In Figure 5-1 below, values will be generated for fields in instances driver1, checker1, receiver1, data1, protocol1, error1, and collect1 in a depth-first manner.

Figure 5-1. Generation Hierarchy

graphics/05fig01.gif

Constraints are directives that influence the behavior of the generator. They are struct members that influence the generation of values for data items within the struct and its sub-tree. There are two basic types of constraints:

  1. Value constraints restrict the range of possible values that the generator produces for data items, and they constrain the relationship between multiple items.

  2. Order constraints influence the sequence in which data items are generated. Generation order is important because it affects the distribution of values and the success of generation.

Both value and order constraints can be hard or soft:

You can define constraints in many ways:

By default, generation takes place before the simulator is invoked. However, you can generate values for particular struct instances, fields, or variables during simulation with on-the-fly generation.

5.1.1 Need for Constraints

If stimulus is applied using completely random values, the results will not be meaningful. Constraints are needed because a large part of the design is exercised only by stimuli that have specific legal relationships between the fields. These legal relationships are set by the design specification and the test plan.

Figure 5-2 shows that when a design is presented with an illegally constructed data object, it will typically discard it without involving most of the logic in the design. Our verification goal is to exercise the entire design, so we need to make sure that most data objects meet the requirements to "cross the wall" to the majority of the logic. These requirements can be expressed as necessary relationships between object field values.

Figure 5-2. Applying Constrained Objects on a Design

graphics/05fig02.gif

5.1.2 Examples of Constraints

Examples of constraints in a verification system are as follows:

5.1.3 Generic Constraint Solver

A generic constraint solver collects all the constraints in the e code at any level of hierarchy, resolves these constraints, and generates the data for all structs within the struct sys hierarchy. Figure 5-3 shows how a constraint solver is provided as a part of Specman Elite. A data object is a struct that represents one test vector. A port object represents the interfaces that drive the data object on to the DUT. The system config object holds system level information. Specman Elite takes the constraints from all these objects and solves them to assign valid values to the fields in the various instances.

Figure 5-3. Generic Constraint Solver

graphics/05fig03.gif

5.1.4 Generation Mechanism

For each field in the verification environment, the generator tries to satisfy all constraints that are specified. If a solution to the constraints is found, a value is randomly picked from the range of legal solutions and assigned to the generated field. If such a solution is not found, a contradiction error is displayed. This process is done for each field in the environment. Figure 5-4 shows the decision chart for generation of values for fields.

Figure 5-4. Generation Decision Chart

graphics/05fig04.gif

5.1.5 Directed-Random Simulation

The e language allows a verification engineer to have full control of the values generated for the fields during simulation. If the values are constrained to very narrowly defined values, it is a directed test. If the values are completely unconstrained, it is a random test. If the values are constrained to a range, then it is a directed-random test. As more constraints are added, the simulation becomes more directed. Thus, an engineer can exert full control over the simulation by constraining stimulus generation and environment variables appropriately. Table 5-1 shows the different simulation scenarios for a 32-bit address field.

Table 5-1. Directed-Random Testing

Test Type

Example

Description

Random

address: uint(bits:32);

No constraint on address field. Random testing.

Directed-random

keep address in [1000..2000];

Address is constrained to a range of values. Value within the range is chosen randomly. Directed-random testing.

Directed

keep address == 1200;

Address is constrained to a specific value. Directed testing.

Previous Section Next Section