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

===== Timing  =====

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.

   * [[asic:timing:graph|Timing model and graph]]
   * [[asic:timing:cells|Cell library and characterization]]
   * [[asic:timing:constraints|Timing constraints]]

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

==== Loading the timer ====

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:
<code>
interact> load-scm "timer.scm"
</code>

==== Reading in Liberty files ====

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.

^ Command ^ Meaning  ^
| timer:lib-read <file>  | This reads in the specified file name as a ''.lib'' Liberty file, which contains delay and power information for the cells used in the design. This returns a handle to the Liberty file, used in other timing commands to refer to the ''.lib''.  |
| timer:lib-merge <lib> <file>  | If your ''.lib'' file is split into multiple files (e.g. for different groups of cells), then this command can be used to combine them into one handle. ''<lib>'' is a valid Liberty file handle, and ''<file>'' is the new Liberty file to be merged into the file handle.  |


==== Creating the timing graph ====

There are two ways to create a timing graph:
   - 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''.
   - 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 [[asic:timing:xcell:start|xcell]], a cell library characterizer.

=== TIming graph using ACT and Liberty files ===

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:
<code>
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
</code>
(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''. 
<code>
interact> define tlib (timer:lib-read "mylib.lib")
</code>
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:
<code>
interact> timer:init tlib
</code>
Notice that we have passed in the handle corresponding to the Liberty file ''mylib.lib''.

=== Scripting changes to the timing graph ===

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:
<code>
interact> timer:build-graph
</code>

Once the timing graph exists, we can introduce additional ticked edges as follows:
<code>
interact> timer:tick a+ b-
</code>
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:
<code>
interact> timer:add-constraint a+ b- c+
</code>
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.


^ Command ^ Meaning  ^
| timer:build-graph | Construct a timing graph from the ACT design only. |
| timer:tick <net1>+/- <net2>+/-  | If the timing edge between the specified net transition exists, then the edge is ticked in the timing graph. |
| timer:add-constraint <root>+/- [*]<fast>[+/-] [*]<slow>[+/-] [margin] | This adds a timing fork. The root of the fork must include a direction (''+'' or ''-''). A timing margin can also be specified. The syntax ''*'' is used to indicate that the event of interest is from the //next iteration// of the circuit relative to the root. |
| timer:init <lh1> <lh2> ... <lhN> | This initializes the timing engine (including creating the timing graph if necessary) using the Liberty file handles <lh1> through <lhN>. Multiple Liberty files are used to specify different corners, etc.  |

==== Running the timer ====


At this point the timer can be run using:
<code>
interact> timer:run
</code>
''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 [[asic:timing:graph|timing introduction]].)

^ Command ^ Meaning  ^
| timer:run  | Runs timing analysis on the design. This command returns a list ''(p M)'', where ''p'' is the cycle period and ''M'' is the unfolding factor. |

==== 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
<code>
interact> timer:crit
</code>

Timing information for a net can be viewed using
<code>
interact> timer:info a.b.signal
</code>

==== Reading in parasitics ====


===== Power =====