Differences

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

--- language:langs:spec [2023/04/09 19:38]
rajit [Timing constraints]
+++ language:langs:spec [2024/12/19 07:18] (current)
rajit [Exclusive directives]
@@ Line 20: / Line 20: @@
  }
 </code>
-states that the signals ''a'' and ''b'' will not be true (high) simultaneously, and this is guaranteed by the production rules in the circuit.
+states that the signals ''a'' and ''b'' will not be true (high) simultaneously, and this is guaranteed by the production rules in the circuit. Violations of this requirement can be detected by ''actsim'' when it is run with the ''-m'' option.
 To simplify modeling of arbiters that cannot be modeled purely at the digital level of abstraction, we include a specific directive that we call "make exclusive high".
@@ Line 37: / Line 37: @@
 The directive ''rand_init'' is used to let the simulator know that a signal might be undefined on power-up, but will initialize to either 0 or 1 at random. The directive ''hazard'' is used to let the simulator know that a particular signal can have a switching hazard.
-==== Timing constraints ====
+==== Timing directives ====
-Timing constraints in ACT are specified using timing forks. Timing forks are used to specify a point of divergence constraint. The constraint
+There are two types of timing directives: constraints, and tick specifiers on timing edges.
+=== Tick specifiers ===
+Asynchronous circuits oscillate, and each oscillation can be viewed as an iteration of the circuit. For [[asic:timing:graph|timing analysis]], it is important to indicate connections from one iteration to the next---i.e. when a signal transition from the current indication leads to a transition from the next iteration. Such directives can be computed during logic synthesis, and ACT expects all logic synthesis tools to emit these directives along with the gate-level implementation.
+<code act>
+spec {
+   timing a+ -> c-
+ }
+</code>
+This directive says that ''a+'' on a particular iteration directly leads to ''c-'' in the next iteration. (Sometimes these are called //ticked// edges in the timing graph.((S.M. Burns and A.J. Martin. Performance Analysis and Optimization of Asynchronous Circuits. Proc. ARVLSI, 1991.))((Wenmian Hua and Rajit Manohar. Exact Timing Analysis for Asynchronous Systems. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 37(1):203-216 (TCAD), January 2018.))
+=== Timing constraints ===
+Timing constraints in ACT are specified using [[asic:timing:forks|timing forks]]. Timing forks are used to specify a point of divergence relative timing constraint. The constraint
 <code act>
 spec {
@@ Line 64: / Line 78: @@
 This has the same meaning as the earlier fork, except that the tools are provided with a hint that says that it is okay to add delays to correct any violations of this fork.
-Asynchronous circuits oscillate, and each oscillation can be viewed as an iteration of the circuit. For timing analysis, it is important to indicate connections from one iteration to the next---i.e. when a signal transition from the current indication leads to a transition from the next iteration. Such directives can be computed during logic synthesis, and ACT expects all logic synthesis tools to emit these directives along with the gate-level implementation.
-<code act>
-spec {
-   timing a+ -> c-
- }
-</code>
-This directive says that ''a+'' on a particular iteration directly leads to ''c-'' in the next iteration. (Sometimes these are called //ticked// edges in the timing graph.((S.M. Burns and A.J. Martin. Performance Analysis and Optimization of Asynchronous Circuits. Proc. ARVLSI, 1991.))((Wenmian Hua and Rajit Manohar. Exact Timing Analysis for Asynchronous Systems. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 37(1):203-216 (TCAD), January 2018.))
 Finally, timing forks may relate transitions from adjacent iterations.