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.

Finally, one can manually specify that a timing edge should be removed from the timing graph

interact> timer:cut a+ b-

This deletes any timing edges from a+ to b- in the timing graph.

Given a cone of combinational logic, it is convenient to be able to compute its timing characteristics. In order to run Cyclone on this type of circuit, we need to introduce a dummy reference clock that is virtually connected to all the primary inputs of the logic. This operation is performed by the following command.

interact> timer:clock 500

This adds a clock with cycle period 500, so that we can proceed with timing the combinational logic cone. (This should produce a timing result that analogous to synchronous static timing analysis.)

In this mode of operation, it can be helpful to find out the names of any nets that have no fan-out; those correspond to the primary outputs of the circuit.

interact> timer:get-fo0

This returns a list of strings, where each string is the name of a net that has zero fanout.

Before running timing analysis, the timing graph can be annotated with parasitics in the SPEF format.

interact> timer:spef "file.spef"

This command reads in the SPEF file file.spef and annotates the timing graph with resistance and capacitance values on the nets.

Sometimes it is useful to be able to add dummy capacitive loads on nets, especially those corresponding to the primary output of the circuit. This can be done as follows:

interact> timer:set-cap "my.net.name" "1.6e-15"

This sets the net capacitance on the specified net name to be 1.6fF. This can be used to ensure that primary outputs have some realistic load when computing delays.

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.)

Timing information is reported in the units from the Liberty file. To get a string that corresponds to the units, use:

interact> echo (timer:time-units)

The timer:time-units command returns a string corresponding to the units of time in all the reports/queries.

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

Another command that is useful in acyclic mode is

interact> timer:info-fo0

This returns a list that contains information about nets that have no fanout. The return value is a list of lists, where each inner list corresponds to information about the zero fanout net. The inner list contains the name of the net (a string), and then M copies of arrival time, required time, arrival slew, and required slew.