This is an old revision of the document!
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.
Note that timing analysis requires that the design has been mapped to cells.
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.
Which edges should be ticked?
This is probably the most confusing aspect of building a correct timing graph for asynchronous circuits. What follows are some rules of thumb that should help you with this process. Note that if you are using our logic synthesis tools, they automatically tick the appropriate edges in the timing graph, so this section need not concern you. However, if you are generating your own asynchronous design via some alternate approach, then you will need to develop a strategy for ticking the appropriate edges in the timing graph.
Control logic
Let's consider a simple example of a handshake protocol between two processes shown below.
In this example, the handshake starts with the request going high (req+). This means that the ticked edge would be from ack- to req+, since the ith transition of ack- results in the (i+1)th transition of req+. Alternatively, the process might reset with req high (e.g. if the process P1 begins with a token on its output). In this case, the timing graph would have a different edge ticked as shown below.
Basically the first transition that occurs when reset is released tends to have its input edges ticked. Ticks are a bit fungible; if all the inbound edges to a vertex in the timing graph are ticked, that is equivalent (from a timing analysis perspective) to adding a tick to all the outbound edges from the vertex (and eliminating the inbound ticks). While in general an edge could have multiple ticks, Cyclone restricts its attention to timing graphs where each edge has at most one tick. (This can be worked around easily if needed.)