Timing constraints

Depending on the asynchronous circuit family used, the correct operation of a design may require certain timing constraints to be satisfied. ACT provides a mechanism to specify these timing constraints, and Cyclone can check if the constraints are in fact satisfied using delay information from the timing .lib file and extracted parasitic capacitance/resistance values from an industry standard .spef file.

Constraints are specified using timing forks. Timing forks can be used to specify a wide range of timing constraints; in particular, they can be used to specify relative timing constraints commonly used in asynchronous circuits. They are general enough to be able to specify setup and hold time constraints in clocked circuits as well. Details on how timing forks are specified can be found in the description of the spec body.

Consider the timing fork described below.

spec {
  timing a+ : b- < c+
}

Cyclone searches for paths from a+ to b- and c+ in the timing graph. The fork constraint is satisfied if the slowest path found from a+ to b- is faster than the fastest path found from a+ to c+.

A violation of this fork can be attributed to two different causes:

• A path that should be fast from a+ to b- is in fact too slow, causing it to violate the constraint; or
• A path that should be slow from a+ to c+ is in fact too fast, causing it to violate the constraint.

Both interpretations are valid, and it is up to a designer to determine what action is most appropriate to correct the timing fork violation. A simple option would be to slow down the path that is too fast, but this may lead to a slower cycle period.