In many companies, there is a well-defined flow for handling monitored data items: match the input data to output data (or, match a response to a request), update data, for example latency or the time from request to response, print formatted messages, and so on.
One of the tools used by verification leaders to implement such company methodology and, at the same time, “pave the way” for variations in the flow is the eTemplate. With an e template you can define and implement a value-holder template for monitoring data items in which the same, generic logic applies to different data types.
Following is an example of a simple template that pairs a generic request to its response:
template struct req_res of (<req_item'type>, <res_item'type>) {
request : <req_item'type>;
response : <res_item'type>;
write_formatted_log() is {
message(LOW, “Request - ”, request,
", Response - ", response);
};
};
req_res structs can be instantiated with different types, for example:
unit monitor {
// pairing packets and relevant transfers
!packets_trans : list of req_res of (packet, trans);
// pairing control packets and the result
// status read from DUT
!ctrl_status: list of req_res of (CTRL packet, int);
};
And accessing the lists:
extend monitor {
packet_write(packet : packet) is {
// a new request-response pairing
var cs : req_res of (CTRL packet, int) = new;
cs.add_request(packet);
ctrl_status.add(cs);
};
};
When a new instance of req_res is created, its item fields (request and response) are created with their default values. The default value for scalars is 0 (or, in case of enumerated scalars, the value whose numeric equivalent is 0). And, by definition, the default value for a struct type is NULL.
This introduces a problem. One of the requirements of this template is that the default field values not be NULL. Thus, the challenge is to define the default value when you do not know the type of the item.
As shown in a recent post, e Templates: A Cool Tool, Now Even Cooler, templates can be extended per parameter type. We use this capability to implement the required behavior:
template extend req_res of (<req_item'type>:struct,
<res_item'type>) {
init() is also {
request = new;
};
};
template extend req_res of (<req_item'type>,
<res_item'type>:struct) {
init() is also {
response = new;
};
};
Now, when a new req_res is created, the items created are not NULL.
Efrat Shneydor, Team Specman