Time Consuming Method (TCM) in specman e-language

TCM's are defined as the methods that have the notion of time, as designated by their sampling event.
· TCM's can be executed over several simulation cycles.
Syntax:
tcm_name([arg: type,...]) [:return-type] @sampling-event is {
---- Required action parameters;
};
TCM’s are attached with sampling_event. The sampling_event fills two functions.
· Implicit sync action at beginning of TCM( must occur before TCM execution begins)
· Default sampling event for TEs in the TCM

Ex: <'
unit port_u {
reset_value: bit;
reset_delay: uint;
reset () @clk is {
---- This indicates the TCM is @sync with clk
reset_value = 0b1;
wait [reset_delay] * cycle;
reset_value = 0b0;
wait [1] * cycle;
};
run() is also {
start reset();
}; };
'>

Declaration of Specman e-language Basic Temporal Expressions

Cadence Specman Elite e-language TE (Temporal Expression), is always associated with a sampling event indicating when the Temporal Expression needs to be evaluated by Specman elite e-language.
1) true(Boolean-exp)@sample-event
The above expression indicates for every Sample-event that the Boolean Expression is true.
2) rise/fall/change (exp)@sample-event
The above expression indicates for every Sample-event that the Expression is rising (falling/change).
3) Cycle @sample-event
The above Expression indicates for every sampling event.
4) [Number] * TE
The above expression indicates the TE’s is repeated for number of times.

Importance Of Using Sampling Events in specman elite e-language

In order to drive / sample signals correctly, there is a need to synchronize with the simulator.
To achieve the above task there is a need to make use of the Specman elite Temporal Language Expression.
The Temporal language of the e-language is the basis for capturing behavior over time for below purpose:
-> To synchronizing with the DUT.
-> In order to develop protocol checkers for automation.
-> In order to develop a Functional coverage for better understanding of the scenarios.

The Temporal Language is mainly built using the below concept:

-> Temporal expressions (TEs)
-> Temporal operators, for defining complex expressions.
-> Event struct members, for defining occurrences of events during the run.
-> Expect struct members, for checking temporal behavior

Accessing / Sampling the DUT signals using specman elite e-language

Specman elite e-language supports in driving or sampling
-> VHDL signals at any hierarchy level
-> Verilog registers and wires at any hierarchy level.
In order to access the DUT we need to use single quotes with '~' to denote top-level module name.
'~/instance HDL path /signal name‘
Ex:
‘~/top_tb/data_in’
Here the top_tb refers to the Top HDL module name and data_in refers to the signal name present in the top_tb module.
-> To Drive a Value from Specman elite e-language to DUT, apply the following mechanism.
‘~/top_tb/reset’ = 1;
-> To Sample a DUT value to Specman elite Variables ( Struct / Unit) , apply the following mechanism.
Packet_u.data_out = ‘~/top_tb/data_out”;

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();
};
'>

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];
};
'>

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;
};
'>