Time consuming methods (TCMs) are e methods that are similar to Verilog tasks and VHDL processes. A TCM is an operational procedure containing actions that define its behavior over time. Simulation time elapses in TCMs. TCMs can execute over multiple cycles and are used to synchronize processes in an e program with processes or events in the DUT.
TCMs can contain actions that consume time, such as wait and sync, and can call other TCMs. Within a single e program, multiple TCMs can execute either in sequence or in parallel, along separate threads. A TCM can also have internal branches, which are multiple action blocks executing concurrently. A TCM can have parameters, local variables, and a return value.
A TCM can be defined only within a struct or unit and an instance of the struct or unit must be created before you can execute the TCM. When a TCM is executed, it can manipulate the fields of that struct instance. The syntax for a TCM is shown below:
method-name ([parameter-list]) [: return-type]@event is {action;...} ;
Table 8-1 describes the components of a TCM definition.
method-name | A legal e name. | |
parameter-list | A list composed of zero or more parameter declarations of the form param-name: [*]param-type separated by commas. The parentheses around the parameter list are required even if the parameter list is empty. | |
param-name | A legal e name. | |
* | When an asterisk is prefixed to a scalar parameter type, the location of the parameter, not its value, is passed. When an asterisk is prefixed to a list or struct type, the method can completely replace the struct or list. | |
param-type | Specifies the parameter type. | |
return-type | For methods that return values, specifies the data type of the return value. | |
@event | Specifies a default sampling event that determines the sampling points of the TCM. This event must be a defined event in e and serves as the default sampling event for the TCM itself as well as for time consuming actions, such as wait, within the TCM body. Other sampling points can also be added within the TCM. | |
action;… | A list of zero or more actions, either time consuming actions or regular actions. |
Example 8-1 illustrates a TCM definition.
Example shows a simple TCM definition <' struct meth { event pclk is rise('~/top/pclk')@sim; //Define event event ready is rise('~/top/ready')@sim; //Define event event init_complete; //Define event init_dut() is empty; //Define empty method (regular method) my_tcm() @pclk is { //Define a TCM called my_tcm(). It becomes //a TCM by virtue of the @pclk sampling event. //A TCM can have constructs that //elapse simulation time. @pclk becomes the //default sampling event of any timing //construct. wait @ready; //Wait until the ~/top/ready HDL signal rises wait [2]; //Wait for two occurrences of @pclk (default //sampling event of the TCM) wait [3] @ready; //Wait for three occurrences of @ready //(Override default sampling event of the //TCM which is @pclk) init_dut(); //Call a regular method emit init_complete; //Manually trigger the init_complete event }; //end of my_tcm() definition }; '>
The following restrictions apply to all TCMs:
Similar to a regular method, a TCM can read or write locally declared variables or fields within the local struct, accept arguments and return a value (implicit result variable), and use fields in other structs using path notation.
The maximum number of parameters you can declare for a TCM is 14. Since a TCM can access all fields in the verification hierarchy using the hierarchical path notation, very few values are passed as arguments to the TCM. Therefore the limit of 14 arguments is not a major limitation. Moreover, it is always possible to work around this restriction by passing a compound parameter such as a struct or a list.
TCMs cannot have variable argument lists. It is possible to work around this restriction by passing a list, which can have variable lengths, or a struct, which can have conditional fields.