WAIT element

The posts from this series so far have discussed some standard gates, such as buffers, inverters , AND-/OR-gates and C-elements, as well as discussing the concepts translation tool, and various concepts required for this.

Now, we can discuss some slightly more complicated devices which can be specified using concepts. In this post, it will be a WAIT element.

Background

Asynchronous circuits are used to work in conjunction with circuits whose signals may be non-persistent. This means that they may switch from high to low and back quickly, and at non-regular intervals.

The problem with this is that it is not garunteed that an input signal transition can cause an effect transition, a signal transition depending on this input, to transition immediately, and sometimes, we may not be interested in the state of this signal at a certain point, and we want to stop this signal causing changes in the asynchronous circuit until it is necessary.

This is where the WAIT element comes in. This allows us to do two things:

  1. Filter a non-persistant input signal in or out, depending on when we are interested in its state.

  2. When we are interested in it’s state, we can wait for it to transition high and latch this, capturing it and passing it into the asynchronous circuit as a persistant signal.

So how do we do that?

WAIT specification

WAIT element schematic

This is the symbol for a WAIT element. There are three sigals involved:

sig - This is the input signal, a non-persistant signal, which we may want to filter, or to capture.

san - The output signal, which is persistant.

ctrl - Is another input which determines what mode the element is in. High will mean that it is in WAIT mode, awaiting sig going high, which will set san high in this mode, latching this. Low means that it is in dormant mode. It enters this state after san goes high, and this blocks changes in ` sig` from affecting this circuit.

Immediatley from this information, we can define the interface:

interface = inputs [sig, ctrl] <> outputs [san]

Next, let’s discuss their interactions. As said in the signal descriptions, as soon as sig goes high, san is set high. We can describe this in concepts as:

outputHigh = sig+ ~> san+

What about the mode? Well, as stated, for san to go high, sig must be high, and the element must be in WAIT mode, or when ctrl is high. Once san does go high, the element enters dormant mode, so ctrl becomes low. Following the access to the resource being used, san will go low once again, allowing the element to enter WAIT mode once again. In concepts, this can be:

modeSelect = ctrl+ ~> san+ <> san+ ~> ctrl- <> ctrl- ~> san- <> san- ~>ctrl+

You may recognise the patter of this concepts, it is infact a Handshake. Thus we can reuse the pre-defined Handshake concept instead of this:

modeSelect = handshake ctrl san

Finally, we need to thin of initial states. Since we are awaiting sig to go high, we can safely state that this will initially be low. Since san follows sig as soon as it is detected to be high, we can also assume san is initially low. The WAIT element itself should start in the dormant mode, until resources start getting access requests so we can also state that ctrl is initially low:

initial = initialise0 [sig, san, ctrl]

So let’s compile these concepts for a single specification, to be translated by the tool:

waitElement sig san ctrl = outputHigh <> modeSelect <> interface <> initial
	where
		outputHigh = sig+ ~> san+
		modeSelect = handshake ctrl san
		interface = inputs [sig, ctrl] <> outputs [san]
		initial = initialise0 [sig, san, ctrl]

Translated, we find the following STG:

translated WAIT element STG

This isn’t too revealing, but simulations prove that it works as expected. Let’s resynthesize it and find a nicer layout.

resynthesized translated WAIT element STG

This reveals exactly how we discussed the design, with the handshake and the sig and san interaction.

A note

This STG will not necessarily verify correctly. Ideally, when ctrl is high, and the input, sig, goes high, san will immediatley go high. Only after this however, will sig go low. However, because sig is non-persistant, this means that sig can go high, and then low again before san transitions high. Realistically, there is some delay for san to transition, which means it may miss the change in sig

To fix this issue, we add a dummy transition. A dummy transition is not related to a signal, but can be used to show the low to high transition of sig, giving san time to transition. This gives us the following STG:

WAIT element STG with dummy signal

ε is the dummy transition here. When sig+ occurs, it will cause this transition to occur, and then san+ can occur following this, after the delay.

Dummy transitions are not yet implemented in the tool, but can be implemented in future.

Finally

This post has featured an entirely different gate to those we have used before, but using the same concepts we have been using all along. What’s more is this can be included in the tool as a standard, and it’s been designed quite easily.

Concepts are proving to make specifying the behaviours of many different gates and scenarios with differing uses simple, when broken down into a set of simple to understand concepts based on signal-, protocol- or gate-level concepts, allowing users to choose how they like to think of the designs, and work in this way.

Next up, a related gate, the WAITX element. This takes the WAIT element and provides some greater functions.

These can be tried in the tool, availble from https://github.com/tuura/concepts, and also built into Workcraft. The concepts given in these posts will work with the tool, with one change. We use a+ and a- in these posts for clarity, however, the tool is written in Haskell, which does not support post-fix notation. Therefore, when referring to signal transitions, please use rise a and fall a for high and low transitions respectively.