Tuesday, April 14, 2009
specman elite e-language supports creation of Bus Functional Module (BFM)
Specman elite e-language supports the creation of Bus Functional Module , Popularly known as BFM.
In order to construct BFM targeting the DUT (Design Under Test), we need to use e-language Temporal Expressions using the concept of TCM ( Time Consuming Methods).
The TCM is similar to Methods , but supported with the events and other Temporal related expressions like wait, sync...
The Initial TCM needs to be started to execute the defined functionality ( which in turn may call / start other dependent TCM's).
e.g
<'
unit packet_bfm_u {
// definition of fields
// Declaration of TCM
packet_gen() @clk_rise is {
// Apply the packet generation functionality
} ; // end of TCM def
run() is also {
// start the TCM
start packet_gen();
};
'>
In order to construct BFM targeting the DUT (Design Under Test), we need to use e-language Temporal Expressions using the concept of TCM ( Time Consuming Methods).
The TCM is similar to Methods , but supported with the events and other Temporal related expressions like wait, sync...
The Initial TCM needs to be started to execute the defined functionality ( which in turn may call / start other dependent TCM's).
e.g
<'
unit packet_bfm_u {
// definition of fields
// Declaration of TCM
packet_gen() @clk_rise is {
// Apply the packet generation functionality
} ; // end of TCM def
run() is also {
// start the TCM
start packet_gen();
};
'>
Sunday, April 12, 2009
Advantage of using Specman Elite stimulus variation feature
The Specman elite e-language stimulus Variation concept mainly helps in,
· Reusability
· Maintainability
· Extendibility
An Approach to Creating SUBTYPES using e-language:
Consider a Network Packet example having address, length, data as its fields and using the defined fileds need to calculate parity . The defined Network Packet may be either GOOD or BAD.
Whenever the packet is of type GOOD assign the parity calculated to parity field and if the packet is of type BAD then do not assign the parity to the parity field.
In order to achieve the required condition, we need to create a subtype using when inheritance.
Following are the steps to be taken while creating subtypes.
· Define a new enumerated type (i.e. Good and Bad)
· Define a field on enumerated type in the struct to represent various subtypes.
· Write a when block and add struct members in the when block that correspond to properties of the specific subtypes.
filename : packet.e
<’
---- Declaration of enumerated types
type packet_kind_t: [Good, Bad];
struct packet_s {
pkt_Kind: packet_kind_t;
Address : uint (bits: 2);
Length : uint (bits: 6);
Data : list of byte;
Keep data. size () = = length;
Parity : byte;
---- User Method for calculating parity Value
Parity_calc () : byte is {
----- User Actions Needs to be entered for calculating parity;
};
--- Subtype creation
When Good ‘pkt_kind packet_s {
Keep parity = = parity_calc ();
};
When Bad ‘pkt_kind packet_s {
Keep parity! = Parity_calc ();
};
};
‘> ---- End of struct
filename : packet_top.e
<'
import packet.e;
extend sys {
packet : packet_s ;
};
'>
filename : packet_test.e
<'
import packet_top.e;
// For Writing Test cases using constraint use the extend feature supported by e-language
extend packet_s {
// Apply the Constraints Required
keep soft pkt_kind == GOOD;
keep soft length == 10;
keep soft Address in [0x1000..0x2000];
};
'>
· Reusability
· Maintainability
· Extendibility
An Approach to Creating SUBTYPES using e-language:
Consider a Network Packet example having address, length, data as its fields and using the defined fileds need to calculate parity . The defined Network Packet may be either GOOD or BAD.
Whenever the packet is of type GOOD assign the parity calculated to parity field and if the packet is of type BAD then do not assign the parity to the parity field.
In order to achieve the required condition, we need to create a subtype using when inheritance.
Following are the steps to be taken while creating subtypes.
· Define a new enumerated type (i.e. Good and Bad)
· Define a field on enumerated type in the struct to represent various subtypes.
· Write a when block and add struct members in the when block that correspond to properties of the specific subtypes.
filename : packet.e
<’
---- Declaration of enumerated types
type packet_kind_t: [Good, Bad];
struct packet_s {
pkt_Kind: packet_kind_t;
Address : uint (bits: 2);
Length : uint (bits: 6);
Data : list of byte;
Keep data. size () = = length;
Parity : byte;
---- User Method for calculating parity Value
Parity_calc () : byte is {
----- User Actions Needs to be entered for calculating parity;
};
--- Subtype creation
When Good ‘pkt_kind packet_s {
Keep parity = = parity_calc ();
};
When Bad ‘pkt_kind packet_s {
Keep parity! = Parity_calc ();
};
};
‘> ---- End of struct
filename : packet_top.e
<'
import packet.e;
extend sys {
packet : packet_s ;
};
'>
filename : packet_test.e
<'
import packet_top.e;
// For Writing Test cases using constraint use the extend feature supported by e-language
extend packet_s {
// Apply the Constraints Required
keep soft pkt_kind == GOOD;
keep soft length == 10;
keep soft Address in [0x1000..0x2000];
};
'>
Saturday, April 11, 2009
Specman elite example for creating subtype packet structure
The below example demonstrates how to generate WR only packet using specman elite e-language without applying the constraints to the enumerated fields declared.
< '
type packet_wr_rd_t : [ WR, RD];
struct packet_s {
packet_wr_rd : packet_wr_rd_t ; // Declaration of the field
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
'>
filename : packet_top.e
<'
extend sys {
// The below assignment make sure that only WR related Packet is generated, which is indirect
// way of applying the constraints
pkt : WR packet_s;
};
'>
< '
type packet_wr_rd_t : [ WR, RD];
struct packet_s {
packet_wr_rd : packet_wr_rd_t ; // Declaration of the field
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
'>
filename : packet_top.e
<'
extend sys {
// The below assignment make sure that only WR related Packet is generated, which is indirect
// way of applying the constraints
pkt : WR packet_s;
};
'>
Friday, April 10, 2009
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
'>
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
'>
Thursday, April 9, 2009
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
};
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];
};
‘>
Wednesday, April 8, 2009
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;
· 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;
Monday, April 6, 2009
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); };
‘>
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); };
‘>
Subscribe to:
Posts (Atom)