Static Timing and Power Analysis

ACT includes a static timing and power analysis engine called Cyclone. Cyclone takes an ACT design along with a Liberty file as well as (optional) parasitics to estimate the performance of the circuit, as well as to check any timing constraints required for correct operation.

Asynchronous circuits contain cycles of gates. How do we time them? The following provides more detail on how static timing analysis for asynchronous circuits works. Please read this before proceeding, as it will explain the terminology used as well as what the interact commands below are for.

• Timing model and graph
• Cell library and characterization
• Timing constraints

Note that timing analysis requires that the design has been mapped to cells, and these cells have been characterized using extensive circuit simulations that are summarized in a Liberty file.

Make sure interact was built with the timer compiled in. An easy way to see this is to run help timer:. If the timer is built-in, then a number of commands will be displayed. If you see no commands, then your version does not have the timing engine. In addition, a dynamically loaded library is needed to use the timer. This can be read in using:

interact> load-scm "timer.scm"

The following two commands are used to read in the Liberty (.lib) files for the cells in the design. The timer uses a Liberty file handle to refer to one complete set of characterized cells (at one corner). If your Liberty files are split into say one file per cell, then they can be merged into a single file handle using the commands below.

There are two ways to create a timing graph:

1. When the design is fully specified in ACT and production rules are specified using cells that are auto-extracted by the ACT tools (e.g. using the ckt:cell-map command), the timing arcs from each cell are computed from the production rules directly. These arcs are checked against the .lib file, and an error is reported if the timing arc is missing from the .lib.
2. When the design has user-specified cells/black box cells, then ACT assumes that timing arcs could potentially relate any input pin of the cell to any output pin, and the arcs are computed based on those specified in the .lib file.

Delays and transition times are added to the timing graph using information in the .lib file. If you are making your own cells, the ACT tools also include xcell, a cell library characterizer.

Most of the time, a timing graph can be created directly using a combination of the ACT files and the Liberty file that contains the cell library information. In what follows, we assume your design has been read in to interact and is ready for timing analysis. A common sequence of commands for this is something like the following:

interact> load-scm "timer.scm"
interact> act:read "design.act"
interact> act:merge "cells.act"
interact> act:expand
interact> act:top "toplevel"
interact> ckt:cell-map

(The timer requires the design to be mapped to a set of cells.)

Next, we must read in the Liberty file(s) we are using. In the example, I assume that the Liberty file is called mylib.lib.

interact> define tlib (timer:lib-read "mylib.lib")

The library handle returned by the timer:lib-read command has been assigned to the variable tlib, for use when initializing the timer.

To build the timing graph and initialize the timer, use:

interact> timer:init tlib

Notice that we have passed in the handle corresponding to the Liberty file mylib.lib.

Sometimes it is useful to be able to edit the timing graph constructed by ACT. This can happen if, for example, the default timing graph generation algorithm doesn't produce the correct timing graph, or is too conservative. Also, this can occur if the ACT design doesn't include all the timing constraints or all the ticked edges.

In the simple example earlier, timer:init built the timing graph using ACT and the Liberty file. In order to modify the timing graph and introduce new constraint checks, the timer initialization can be broken down into two steps: (i) constructing a timing graph using the ACT specification only; and (ii) incorporating timing arc information from the Liberty file. Between steps (i) and (ii), additional commands can be used to modify the timing graph.

To build the timing graph, use:

interact> timer:build-graph

Once the timing graph exists, we can introduce additional ticked edges as follows:

interact> timer:tick a+ b-

This looks for a timing arc/edge from a+ to b- , and ensures that the edge is ticked.

New timing constraints can also be introduced:

interact> timer:add-constraint a+ b- c+

This command introduces a timing fork with a+ as the root, b- as the fast tine of the fork, and c+ as the slow tine of the fork.

At this point the timer can be run using:

interact> timer:run

timer:run returns a list containing two values:

• The cycle period p for the circuit, and
• The unfolding factor M.

(For details about what this means, please read the timing introduction.)

Once the run command is complete, a number of queries can be used to interrogate the computed timing. To see the critical cycle in the design, use

interact> timer:crit

Timing information for a net can be viewed using

interact> timer:info a.b.signal