| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| help:mutex:protocol [2025/01/13 11:30] – [Can MUTEX reliably follow the late protocol?] victor | help:mutex:protocol [2026/05/26 16:14] (current) – [Arbitration protocols] victor |
|---|
| Related information: | Related information: |
| * [[wp>Metastability_(electronics)|Metastability]] | * [[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 ===== | ===== Early vs late arbitration protocols ===== |
| ===== MUTEX support in Workcraft ===== | ===== MUTEX support in Workcraft ===== |
| |
| The old method of factoring out mutex into the environment (so the mutex grants are inputs to the STG) is considered obsolete, for the reasons it does not allow the features described below. Instead, mutexes should be 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 (verification of output-persistence will fail if you forget to do that, as the grants disable each other). 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 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 synthesis and verification would recognise 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 | * 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 | * 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) | * synthesis automatically adds MUTEX cells to the netlist (with the equations corresponding to the protocol). |
| |
