Specman 9.2 Preview: Named Constraints

[Preface: all features in the 9.2 preview series are in Beta now. We invite you to sign-up for the beta program and give this feature a test drive!]

[Team Specman welcomes Reuven Naveh from Specman R&D to introduce “his” new feature.]

Abstract
In Specman 9.2 we are extending the syntax of constraint declaration in a struct to support a user defined name and a string message in case the constraint cannot be fulfilled. In effect, we are adding the ability to “name a constraint” to expedite the constraint analysis and debug process, as well as make the code easier to read and reuse.

Problem Statement
One way to think of generation constraints is that constraints are used to express properties of entities in a model. As such, the domain meaning of a constraint could be useful in understanding the code and debugging any generation issues. However there is no way to express such domain semantics in the code, as constraint declarations currently consist of just the boolean expressions that are associated with a property. Moreover, unlike properties expressed with methods and events, constraint properties of a struct cannot be overridden in later extensions or in subtypes. This is unfortunate, as abstract and default definition for a given constraint property (to be later refined) is a powerful way to supply interface between verification service and user.

“Named Constraints” Solution Overview
In Specman 9.2 we are extending the syntax of constraint declaration in a struct to support a name and a string message in case the constraint cannot be fulfilled. Later extensions of the struct or when/like subtypes can then override the constraint by associating a different boolean expression with the same constraint name. The name would also serve to identify the constraint in the development environment (data/class browsers, gen debugger, collect gen, etc.).

To make this feature as easy to use as possible, the extended syntax and semantics for named constraints is perfectly consistent with the definition of other named struct members such as methods and events. In particular, named constraints are in complete analogy to expect/assume struct members, as both declare either an anonymous or a named property of a struct as an expression, optionally with a message for the case it does not hold. Additionally, just like with expects, when the property is named it can later be overridden in extensions or subtypes.

The Official Syntax Definition
The syntax of constraint struct member definition is augmented to allow for names and error declarations.

keep [<name> is [only]] <constraint-definition>
                [else error(<exp>,...)]

keep <name> is undefined [else error(<exp>,...)]

keep <name> is empty [else error(<exp>,...)]

<name> is any legal identifier used to identify the constraint for reference in extensions and in different tools of the development environment.

<constraint-definition> is the body of the constraint – typically a boolean expression or a composition of constraint definitions in a for each or all of constructs.

The error construct takes any number of parameters of any type (<exp>), and concatenates the string representations of their values.

Notes:

• The use of names/error messages in constraints will only be supported in IntelliGen. In particular, the solver directives gen before and gen_before_subtype(<exp>) (which are not handled in IntelliGen) cannot be named or have error messages attached to them (and cannot figure inside all-of and for-each constructs).

• Backward compatibiliy with PGEN: the legacy “Pgen” generator will handle named constraints just like any other constraint, and will simply ignore the “undefined” and “empty” definitions.

• Since named constraints are considered to be struct members by Specman, neither that name nor the error message can be attached to constraint definitions inside a gen keeping action, or inside compound constraint expressions, such as keep for each, keep all-of (the entire block can be named).

Here are a few use examples of named constraints in action:

struct packet {
    addr: unit (bits: 16);
    data: list of byte;

    keep address_range is soft addr in [0..9];

    keep data_size is undefined else error("Bad data size");

    keep data_pattern is for each in data {
      it != 0 and it != 7;
    } else error("Cannot generate data for ",me);

    keep data_size is only all of {
     data.size() > 10;
     data.size() < 20;
    };
};

 

Named Contraints Semantics & General Behavior
Names and error messages will not change the effect of a given constraint on the generation processes, or any other semantic aspect of a program. User defined error messages are issued upon solver failure.

Constraint Overriding
Every named constraint must have exactly one actual definition per struct type. Trying to generate an instance of a struct type for which a constraint was left undefined results in an error (if the constraint used the “empty” declaration, no error will be issued). An initial definition of a constraint in a struct type may be overridden in like and when subtypes or in later extensions of the same struct any number of times using the is only modifier.

The semantics of constraint overriding is identical to overriding of other extendable struct members, such as methods: a constraint can be rewritten in different when subtypes (even if they are not contradictory), and the latest entity which is valid to the generated subtype will be chosen. It follows that the variables of a constraint depend on every when-determinant under which this constraint is rewritten. Relations contrary to this (either uni-directional or bi-directional) will lead to ICFS and will be reported in the “gen lint –i" report. The following example helps illustrate the rules for constraint overriding.

 

struct packet {
  size: [big, small];
   addr: uint (bits: 16);
     keep address_range is addr in [5..13];--#1.1
     data: list of byte;
     keep data_size is undefined;--#2.1

struct regular_packet like packet {
  when big regular_packet {
    keep data_size is data.size() > 8;--#2.2
    keep address_range is addr < 10;--#1.2
  }
}

extend regular_packet {
  corrupt: bool;
    when corrupt packet {
     keep data_size is data.size() == 0;--#2.3
  };
};

struct special_packet like packet {
  keep data_size is data.size() < 50;--#2.4
};

 

For the following subtypes of packet:

big FALSE’corrupted regular_packet: constraints #1.2 and #2.2 will be enforced.
big TRUE’corrupted regular_packet: constraints #1.2 and #2.3 will be enforced.
small TRUE’corrupted regular_packet: constraints #1.1 and #2.3 will be enforced.
special_packet: constraints #1.1 and #2.4 will be enforced

Any attempt to generate a different subtype (packet, or small FALSE’corrupted regular_packet) results in an error, because the data_size constraint is left undefined.

 

“Named Constraints” In The Typical Debug Flow
The user can trace and debug named constraints using the following procedures:

Show constraints: the “show constraints” command will show all constraints of all layers, including those which are known to be overridden by other constraints.

Source command: this command applies to named constraints as it does to any other named struct member. In particular, behaves the same as with expects/assumes.

Gen debugger: when the Gen Debugger shows the constraints of a CFS, only those constraints which were not overridden (either statically or dynamically) will be shown to the user. The information regarding the “name” of the constraint will be available to the user.

 

I hope you find this feature helpfulin your daily work, and I invite you to send me any questions or feedback by posting a comment below, or relayed via Team Specman.

 

Happy Coding!

Reuven Naveh
Specman R&D