specman elite e-language supports subtype stimulus creation

Specman elite e-language supports the formation of subtype stimulus creation.
In order to achieve we need to use the enumerated define types.
e.g If we want to control the generation of fields w.r.t subtypes, it is better to use enumerated types as a controlling parameters.
Let's have requirements in mind for the Read / Write scenario. We all Know that Address field is common for both Read / Write Transcation, whereas we need to generated write data when we are performing the Write Transcation.
Here is how we control the generation using the specman e-language subtype declaration.
The following example demonstrates , if the enumerate type declared is WR in nature it generates Write Address and Write Data else it only performs Read Transcation.
< '
type packet_wr_rd_t : [ WR, RD];
struct packet_s {
packet_wr_rd : packet_wr_rd_t ; // Declaration of the field
keep soft packet_wr_rd == WR;
Address : byte ; // Common field for both RD / WR
keep soft Address == 0x10;
// Apply the Subtype to control the generation
when WR' packet_s {
wr_data : byte ;
// default value, can be overwritten using testcase
keep soft wr_data == 0x0 ;
}; // end of WR subtype creation.
}; // end of struct definition

'>

specman e-language constraint usage example

Adding a small example for using the constraint feature with the help of specman elite e-language.

file name : packet_def.e
<'
packet_kind_t : [ small, medium, large]

'>
file name : packet.e
<’
struct packet_s {
Addr: uint (bits: 32);
Kind: packet_kind_t;
my_method () is {
// define the actions required e.g parity_calculation
};

// call the above mentioned method in run phase

run() is also {

my_method();

};

}; // end of struct def

'>

file name : packet_top.e

<'

import packet_def.e;

import packet.e;

extend sys {

pkt : packet_s ;

};

'>

// Writing the Top Test case for applying constraints

file name : packet_test.e

<'

import packet_top.e;

extend packet_s {

keep soft Kind = = Small ;

keep soft addr in [10..40];
};
‘>

specman elite possible ways of generating fields

Specman Elite e-language supports three possible ways of generating the fields.

· Random generation

· Directed-Random generation

· Directed generation

Random generation:

The Random generation is not supported by constraints.

Ex: address: int (bits: 32);

Directed-Random generation:

The Directed-Random generation supports the generation by constraining to a range of values. Here, even though the generation is random it is been restricted within the Range of 1000 to 2000 address locations.

Ex: keep address in [0x1000..0x2000];

Directed generation:

The Directed generation supports the generation by constraining to a specific value.Here, the generation of address value is specified to the location of 1245.

Ex: keep address = = 0x1245;


Soft Constraints

For constraints that might need to be overridden, we use soft constraints. Basically, Soft constraints are obeyed if not contradicted by hard constraints.
The last loaded soft constraint prevails if there is a contradiction with other soft constraints.

Syntax :

keep soft Boolean-expression;

Ex: keep soft length = = 64;

· Soft constraints are used to define the default range of values of fields:

Ex: keep soft packet_length in [60..100];

· The test writer has the option to ignore the soft constraint by using predefined method reset_soft().

Ex: keep packet_length.reset_soft ();

· Soft constraints are used to set initial settings for tests

Ex: keep soft errors = = FALSE;

Controlling order of generation using specman e-language

Specman elite e-language generates the fields based on the Order of declaration.
Consider an example, which illustrates the order of generation.

Ex: <’

type packet_kind_t: [Small, Medium, Large];

struct packet_s {

Kind: packet_kind_t;

Address: uint (bits: 32);

keep Kind = = Small => Address < 40; };

‘>

The above example explains that the packet_kind_t (kind) of enumerated type is generated first followed by address.The constraints definition says if the kind is Small in nature then generate address below 40.

Suppose, unknowingly if the address is declared first followed by Kind then the above constraint statement doesn’t hold good.

In order to achieve the same result, add an explicit generation order constraint supported by Specman Elite e-language.

The below example shows the constraints for such Operation.

Syntax:

keep soft gen (control- field) before (control –field);

Ex: <’

type packet_kind_t: [Small, Medium, Large];

struct packet_s {

Address: uint (bits: 32);

Kind: packet_kind_t;

keep Kind = = Small => Addr < 40;

keep soft gen (Kind) before (Address); };

‘>

specman e-language supports constraint random generation

specman e-language supports the concept of constrained random generation.

. Constraints are applied on struct members e.g Fields and methods.

· Constraints are Boolean equations

· Constraints are declarative statements

Specman e-language categories the constrained mechansim as follows :

1) Random Generation without any constraints parameters
2) Directed Random constrained Generation [ e.g from .. to ]
3) Directed constrained Generation

For constraining a Field use the following syntax :
keep Boolean-expression

Ex: struct packet_s {

Length : uint(bits:6);

Address : uint(bits:2);

// application of Directed Constraints Parameter for Length field

keep Length = = 10;

// application of Directed Random Constraints Parameter for Address field

keep Address in [0..2];
};




For constraining elements in a list (array):

keep for each (item) in list_name {

Boolean-expression; };


Ex: Struct packet_driver_s {

Packets : list of packet_s;

// Constraints list for the individual fields

keep for each (pkt) in packets {

pkt.len < 10; }; };



The syntax for implication constraints are given below:

keep Boolean-expr1 => Boolean-expr2;

Ex:

keep size = = SHORT => length < 10;

keep size = = LONG => length > 20;

Or, suppose if we want to constraint using lists:

Ex:

keep for each (pkt) in packet {

index = = 0 => pkt.addr = = 1 and pkt.kind = = GOOD;

index = = 1 => pkt.addr = = 2 and pkt.kind = = BAD; };


Weighted Constraints:

Weighted constraints are used on a specific application. It allows selection weight for value or range of values. In order to achieve a weighted constraint we need to apply a soft control on the distribution of generated values.

syntax: keep soft gen-item = = select {weight: value ;};

Ex: <’

keep soft length = = select {

20:14;

25:10;

10:20; };

‘>

specman e-language usage examples for extending methods

Here i am listing examples of extending methods using specman e-language concept.

Ex : extending using is_also

---> Filename packet.e
<’

struct packet_s {

my_method () is {

out (“I am here”);
};
};

‘>

-------> new file packet_extend.e

<’

import packet.e;

extend packet_s {

my_method () is also {

out("to learn e-language”);
};
};

‘>

when we execute the packet_extend.e we can see finally the output appearing as "I am here to learn e-language".


Ex : extend using is first

---> Filename packet.e

<’

struct packet_s {

my_method () is {

out (“I am here”);
};
};

'>

---> New file : packet_extend.e
<’

import packet_extend.e;

extend packet_s {

my_method () is first {

out (“to learn e-language”);
};
};

'>

when we execute the packet_extend.e we can see finally the output appearing as "to learn e-language i am here".


Ex: extend using is only

---> Filename packet.e

<’

struct packet_s {

my_method () is {

out (“I am here”); }; };

'>

---> New file packet_extend.e

<’

import packet.e;

extend transaction_s {

my_method () is only {

out (“to learn e-language”);
};
};

'>

when we execute the packet_extend.e we can see finally the output appearing as "to learn e-language ", this extend method operator overrules the previous contents of the same method defined.

How to extend methods in e-language

Specman e-language has the built in features to extend the predefined and
user-defined methods in order to have new contents.
The extension can be done in the same file where the original method is declared or in another new file.
Specman e-language supports the following features for extending the methods

a) is first => which means add before the existing e code
b) is also => which means add after the existing e code
c) is only => which means override/replace the existing e code