Back Annotation and Delay Calculation

Creating a Back Annotator

Figure 2-1 Connecting a new Verilog HDL system task or system function to your C routines using the veriusertfs data structure

C source file

See the PLI 1.0 User Guide and Reference for further information on creating new system tasks and functions and linking your application with the simulator.

PLI Access Routines

The PLI contains a complete set of access routines you can use in your C-language routines to retrieve from the Veritool data structure the information you need to perform delay calculation. Also included in this set are routines that you can call to modify the timing information within the data structure, a capability necessary for both delay back annotation and delay calculation facilities.

The access routines are provided in object code form with the Veritool release and are included by default in the link script created by vconfig. Use the access routines in the same manner that you use other C-language library routines—simply call them in your C-language source code.

Back Annotation and Delay Calculation

Creating a Back Annotator

The access routines are object-oriented. They perform many different functions on objects within the design. One routine can be used to perform a single operation on different types of objects.

Most of the access routines utilize an object handle, which is a data type defined in the access routine include file acc_user.h. It is a pointer to an object within the design.

Access Routine Families

All access routines begin with the string acc_ and are named descriptively so as to indicate the type of operation they perform. For documentation purposes, they may be divided into the following routine ‘families’:

■FETCH routines—return information about an object (for example, hierarchical name, delay values).

■HANDLE routines—return a handle to an object given the name of the object or an associated object.

■MODIFY routines—modify an object’s timing information.

■NEXT routines—access all objects of a given type (can be limited to a specific scope).

■UTILITY routines—perform operations based on other access routines, configure the operation of other access routines, and perform initialization or cleanup functions.

The access routines can only retrieve and modify information related to structural design objects such as modules, gates, switches and nets and their associated timing constructs. It is not possible to access information about behavioral constructs within the design.

Required UTILITY Routines

You call the following UTILITY routines in a facility that uses the access routines:

■acc_initialize

■acc_configure with accDevelopmentVersion

■acc_close

The routine acc_initialize initializes the access routines; you must call this routine before you call any other access routines. If you do not call acc_initialize first, subsequent access routine calls may produce unpredictable results.

Back Annotation and Delay Calculation

Creating a Back Annotator

Immediately after the call to acc_initialize, specify a call to acc_configure with arguments accDevelopmentVersion and the version number of the access routines under which you are developing your facility. The call to acc_configure guarantees compatibility of your facility with future versions of the access routines. You will need to modify your routines for new versions only if you want to take advantage of new access routine functionality.

The routine acc_close frees any internal memory allocated by the access routines. Call acc_close just before returning from your facility. Note that acc_close does not free memory that you implicitly allocate with calls to acc_collect; use acc_free to free this memory.

Access to Timing Information

Use access routines from the FETCH and MODIFY families to retrieve and change nonbehavioral timing information within a design. The non-behavioral timing information includes the following Verilog HDL constructs:

■gate, switch and user-defined primitive (UDP) delays

■module path delays

■timing checks

The routines acc_append_delays and acc_replace_delays add to or replace the delays for an object, respectively, and the routine acc_fetch_delays retrieves the delays for an object. These routines take various numbers of arguments, depending on the type of delay you are accessing and, for path delays, the configuration of the routines as set by acc_configure. Figure 2-2 on page 16 summarizes the operation of these routines based on these factors.

Figure 2-2 Summary of access routines that modify timing information

For

acc_append_delays, acc_replace_delays. and acc_fetch_delays write:

■MOS switches

Back Annotation and Delay Calculation

Creating a Back Annotator

Use the routines acc_append_pulsere, acc_replace_pulsere and acc_set_pulsere to modify the pulse control values for path delays. Use the routine acc_fetch_pulsere to retrieve the current pulse control values for path delays. Except for acc_set_pulsere, these routines take various numbers of arguments, as set by acc_configure.

The routine acc_set_pulsere sets the pulse control values for a path delay based on two input percentages that define the three pulse control regions and the current delay values associated with the path.

All of the access routines that manipulate timing information interpret timing data in the timescale of the current module (for example, the timescale of the module that contains the primitive to which delays are being added).

Identifying Cells and Manipulating Cell Definition Data

The PLI provides a set of access routines that allow you to identify cell instances within a design and retrieve and manipulate the associated cell definition data (see “What Is a Cell?” on page 8 for information on defining cell modules). By using these routines, you can process those module instances that represent cells while ignoring module instances that simply provide hierarchy to a design.

The routine acc_next_cell returns a handle to the next cell instance in a specific hierarchy of a design. This routine does not go ‘inside’ cells during its search; if a cell contains an instance of another cell, acc_next_cell returns a handle to the top-most (containing) cell instance. Use acc_next_cell to scan all cells in a particular section of a design. Use the more general acc_next_child to scan all module instances in a particular hierarchy.