Back Annotation and Delay Calculation
Calculating Delays
Scanning Cell Instances Within the Design
Determining the Scope of the Delay Calculation
The first task that you must accomplish within your delay calculation facility is to determine the area of the design where delay calculation should take place. Typically, this involves
finding the module instance at the top of the hierarchical tree that contains all of the cell instances for this calculation. Note that this may encompass the entire design or, in the general case where each hierarchical tree represents a different library or technology type, a subsection of the design.
The most common methods of providing this ‘starting point’ information to the delay calculation process are as follows:
■explicitly in an argument passed to the delay calculation system task call within the Verilog-XL HDL description
■implicitly by the location of the delay calculation system task call within the Verilog-XL HDL description
Explicit method
To determine the starting point for delay calculation from information explicitly provided in the system task call, pass the name of the top-level module instance for the calculation in the call and use acc_handle_tfarg to retrieve a handle to this module instance. This routine returns a handle to the object identified by a system task or function call argument based on the ordered location of the argument in the call’s argument list. Figure 4-7 on page 49 shows a C-language routine fragment that uses this method.
October 2000 |
48 |
Product Version 3.2 |
Back Annotation and Delay Calculation
Calculating Delays
Figure 4-7 Determining delay calculation starting point from information passed in the system task cal
l
static handle dl_process_scope_arg() { 
handle scope = acc_handle_tfarg(1); int arg_type;
Get handle to first argument
if (acc_fetch_type(scope) != accModule) { 
. . .
}
. . .
return (scope);
}
Check if module instance handle
Return handle to module instance
If you use this method, you must set the last field in the veriusertfs entry for the delay calculation system task to a non-zero value. Otherwise, the simulatror reports compilation errors when you pass a module instance name as an argument to the system task call. Refer to the PLI 1.0 User Guide and Reference for complete information on the veriusertfs data structure and its role in defining new system tasks and functions.
Implicit method
To determine the starting point for delay calculation from the location of the system task call, use acc_handle_parent to retrieve a handle to the module instance containing the call. Use the value returned by the PLI interface routine tf_getinstance as a handle to the system task call in order to facilitate this process. Figure 4-8 on page 50 shows a C-language routine fragment that uses this method if no explicit starting point information is passed to the delay calculation system task.
October 2000 |
49 |
Product Version 3.2 |
Back Annotation and Delay Calculation
Calculating Delays
Figure 4-8 Determining delay calculation starting point from the location of the system task call
static handle dl_process_scope_arg()
{
handle scope = acc_handle_tfarg(1); int arg_type;
if (acc_fetch_type(scope) != accModule)
{
/************************************************************/ /** if task argument is null, set scope to invoking module **/ /************************************************************/
arg_type = tf_typep(1);
Get argument type if (arg_type == tf_nullparam)
scope = acc_handle_parent(tf_getinstance());
. . . |
|
Retrieve handle to |
} |
|
system task parent |
|
|
|
. . . |
|
|
return (scope); |
|
Return handle to system |
|
task parent |
|
|
||
|
|
}
In general, the explicit method is preferable to the implicit method, because the explicit method results in a mechanism that supports different delay calculations on different pieces of the same design without the need to bury the system task calls within the description.
Scan Methodology
Dependencies
The algorithm that you use to scan the cell instances within a design depends on the data that is needed to perform the delay calculation for a particular instance. In most technologies, the required data can be extracted from the cell itself, retrieved from some external source or
October 2000 |
50 |
Product Version 3.2 |
Back Annotation and Delay Calculation
Calculating Delays
obtained from the cell instance’s immediate environment within the design. For libraries corresponding to these technologies, you can scan the cell instances randomly, because the required delay calculation data does not imply any order dependency within the calculation process.
For other technologies, however, the calculation of delays for a particular cell instance depends not only on the data mentioned above but also on the delays calculated for other cell instances within the design. In these cases, you must use a more complex algorithm to scan the cell instances in a particular order.
The following section describes the common case in which a random scanning technique can be used. Note that, even in cases where the target technology does not imply any order dependency within the calculation process, it may be desirable to use a different scanning technique. “Load Due to Interconnect Wire” on page 63 describes a method that uses the net names contained in a capacitance back annotation file to scan the design.
Randomly scanning cell instances
To scan cell instances randomly, use acc_next_cell with the handle to the module instance at the top of the desired hierarchy in a C-language while loop construct. Since acc_next_cell scans the entire hierarchy below this module instance, you can process all of the cell instances within this single construct. Figure 4-9 on page 52 shows a C-language routine fragment corresponding to the example design shown in Figure 4-1 on page 44 and Figure 4-4 on page 46 that uses this method to scan all cell instances below the indicated module instance.
October 2000 |
51 |
Product Version 3.2 |