Constraining Generation

In this section we are going to see the basic concepts and types of constraints. Generation is the process that automates the selection of values for fields and variables. During the generation phase, the entire tree of instances under the struct 'sys' is generated.

If stimulus are applied using random values, the results are not meaningful. Because a large part of the design is exercised only by stimulus that have a specific legal relationship between the fields. So, each instance of a struct or unit and their fields must be generated in a manner that is compliant with the design specification.

Constraints are struct members that influences the generation values for fields inside the struct and unit. Basically, there are two types of constraints.

• Value constraints - It restricts the range of possible values that the generator produces for data items.
• Order constraints - It influences the sequence in which data items are generated.

Both the above constraints can be of hard or soft. Hard constraints must be met or an error is issued. Soft constraints suggest the default values but can be overridden by hard constraints. By default, generation takes place before the simulator is invoked. However, you can generate values for fields during the simulation with on-the fly generation.

Generation mechanism

For each field in the verification environment, the generator tries to satisfy all the 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 generator field. If such a solution is not found, a contradiction error will be displayed.

Directed random simulation

1. Directed test - The values are constrained to very narrowly defined values.
2. Directed random test - The values are constrained to a range.
3. Random test - The values are un-constrained.
   

Implication constraints set up constraints on fields based on another boolean expression being true. These constraints are specified using => operator. We have already seen this type of constraints in our previous section.

Weighted constraints are soft constraints used to specify the relative probability that a particular value is chosen from the current range of legal values. They are specified using the keyword 'keep soft select'.

The following example shows the different types of test. The basic form of constraint is specified using the keyword 'keep'.

====================================================================

Example of constraint generation

<'
type packet_id : [IN, OUT];

struct constraint_gen
{
pid : packet_id;
dev_add : uint (bits:7); // Random, no constraints on 'dev_add' field
ep_nu : uint(bits:4);
keep ep_nu in [3..5]; // Directed Random
sync : uint(bits:8);
keep sync == 8'hFE; // Directed test

keep pid == IN => dev_add in [1..9]; // Implication constraint

keep soft pid == select
{
30 : IN; // 30/50 probability that IN is selected
20 : OUT; // 20/50 probability that OUT is selected
}; // Note that weights don't have to add up to 100.
}
'>
====================================================================
Order of generation

Specman elite generates all instances instantiated in sys hierarchy. It generates the values of the fields in different instances of the struct in a depth-first order. The default order of generation within a struct is the order in which the fields are defined. However, there are special cases in which the generation order can be changed. In the previous example,

keep pid == IN => dev_add in [1..9]; // Implication constraint

// To work correctly this implication must have pid generated before dev_add

keep gen (pid) before (dev_add);

In this case, the specman elite generates pid field before it generates dev_add. The constraints may be defined in several places including the original struct definition, extension to the struct or other struct definitions using the hierarchical path notations.