Differences

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

--- help:mutex:protocol [2024/12/16 16:00] – [Can MUTEX reliably follow the late protocol?] victor
+++ help:mutex:protocol [2026/05/26 16:14] (current) – [Arbitration protocols] victor
@@ Line 5: / Line 5: @@
 Related information:
   * [[wp>Metastability_(electronics)|Metastability]]
-  * [[a2a/start|Analog-to-asynchronous elements]] (handling poorly behaving signals (e.g. glitchy or from analog circuitry)
+  * [[a2a/start|Analog-to-asynchronous elements]] (handling poorly behaving signals, e.g. glitchy or from analog circuitry)
 ===== Early vs late arbitration protocols =====
@@ Line 26: / Line 26: @@
 One can observe that the early protocol can execute every trace that the late protocol can execute, but not vice versa: E.g. the trace ''<color red>r1+</color> <color red>r2+</color> <color blue>g1+</color> <color red>r1-</color> <color blue>g2+</color>'' is possible in the early protocol but impossible in the late protocol. At the end of this trace ''<color blue>g1</color>=<color blue>g2</color>=1'', i.e. both grants are high, whereas the grants are guaranteed to be mutually exclusive in the late protocol.
-From the point of view of circuit design, the arbiter is usually implemented using a (pre-designed) MUTEX cell, and one has to design a circuit around it, or more precisely, an STG which is then synthesised in a circuit. In other words, an asynchronous designer does not design a MUTEX cell (it is provided as a basic cell), but designs an STG that has to interface a MUTEX cell. Hence, the designer can, //conceptually//, factor out the MUTEX into the environment and design an STG using, e.g., the early or late protocol shown above.
+From the point of view of circuit design, the arbiter is usually implemented using a (pre-designed) MUTEX cell, and one has to design a circuit around it, or more precisely, an STG which is then synthesised in a circuit. In other words, an asynchronous designer does not design a MUTEX cell (it is provided as a basic cell), but designs an STG that has to interface to a MUTEX cell. Hence, the designer can, //conceptually//, factor out the MUTEX into the environment and design an STG using, e.g., the early or late protocol shown above.
 The early protocol is more permissive, i.e. it places strictly fewer requirements on the MUTEX implementation, in particular it does not require the grants to be mutually exclusive. This means that an STG designed with the early protocol is strictly more robust -- the synthesised circuit will be able to cope with the grants being not mutually exclusive. On the other hand, a circuit synthesised from an STG designed with the late protocol may malfunction if in the physical implementation the grants are not mutually exclusive.
-Hence, there are two possible way to design a robust circuit (assuming MUTEX follows at least early protocol in either case):
+Hence, there are two possible ways to design a robust circuit (assuming MUTEX follows at least early protocol in either case):
   * make sure that MUTEX follows not just early but also late protocol, and design the circuit using either early or late protocol;
   * design the circuit using early protocol.
@@ Line 64: / Line 64: @@
 Given all the above consideration, the early protocol should be preferred unless there are strong reasons to use the late protocol (e.g. legacy design), in which case extra care should be taken to make sure the late protocol is followed.
+===== MUTEX support in Workcraft =====
+The traditional method of factoring out MUTEX into the environment (so the MUTEX grants are inputs to the STG) is considered obsolete in Workcraft flow, for the reasons it does not allow the features described below. Instead, MUTEXes are now treated as part of the circuit and specified in the STG so that their grants are outputs or internal signals. The place representing the choice between the grants should be tagged as a MUTEX place in the Property Editor (verification of output-persistence will fail if you forget to do that, as the grants disable each other; also, if the grants are declared as input signals, an error will be reported during the verification of the MUTEX protocol). The protocol is a property of the MUTEX place, and by default it is early, but can be changed to late by the user (who is then responsible for the outfall; the key is that the default is the safer protocol, and turning on the less safe late protocol is not tacit, the user has to actively do it). The visual representations of early and late MUTEX places is shown in the above STGs -- note that they look differently from each other and from non-MUTEX places.
+The verification and synthesis would recognise MUTEX places and treat them specially:
+  * the choice between grants (which are now internal or output signals) does not cause violation of output-persistence;
+  * arbitration protocol (of the type corresponding to the type of the MUTEX place) is verified for each MUTEX place;
+  * synthesis automatically adds MUTEX cells to the netlist (with the equations corresponding to the protocol).