Differences

This shows you the differences between two versions of the page.

--- asic:timing:constraints [2023/11/18 21:03] – created rajit
+++ asic:timing:constraints [2024/03/21 17:36] (current) – rajit
@@ Line 3: / Line 3: @@
 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'' [[language:langs:spec#timing_constraints|body]].
+Consider the timing fork described below.
+<code act>
+spec {
+  timing a+ : b- < c+
+}
+</code>
+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.
+When identifying paths from one timing graph vertex to another,  Cyclone will only traverse //unticked// edges. So, for the example above, path searching will stop when it encounters a ticked edge. There are also cases when this may be insufficient, and the paths of interest must have exactly one ticked edge on them.  The following example shows this scenario:
+<code act>
+spec {
+  timing a+ : b*- < c+
+}
+</code>
+Here, the paths considered from ''a+'' to ''b-'' must have exactly one tick on them, while the paths from ''a+'' to ''c+'' have no ticks on them. (The asterisk can appear on ''b'', ''c'', or both.)