Signal Transition Graphs (STGs) are domain-specific Petri nets, used for specifying asyn- chronous circuits [19]. The transitions of STGs are solely the event of a signal transi- tioning, either high or low [10][12]. STGs can be used to model the environment that a circuit reacts to, the input signals, the intermediate signal changes within the circuit, in-
ternal signals, and the output signals which are the circuits reaction to the environment,
and conventionally, input, output and internal signals are identified by their colour, red,
blue and green respectively. Each signal can transition either high, indicated by the +
operator, or low, indicated by the −operator.
As STGs are derived from PNs, they feature all of the elements of PNs, including tokens, arcs and read-arcs. Places are also a feature, however in an STG there can be implicit places, which allows tokens to be contained within an arc connecting two transitions. This removes the number of places that a single model contains, which can make for a clearer STG. The choice and merge constructs in a circuit can be indicated in the same way as PNs, but implicit places change how concurrency constructs, fork and join, are indicated.
Figure 2.9 contains the constructs for choice, merge, fork and join in STGs. Free choice (Figure 2.9a) and merge (Figure 2.9b) are very similar to those of PNs, with a place passing a token to only one branch of the system, and a chosen branch returning this
(a) Free choice (b) Merge (c) Fork (d) Join
Figure 2.9: STG constructs for modelling choice and concurrency
token to a place when merging, to be passed onto the next section. Fork (Figure 2.9c) and join (Figure 2.9d) however feature transitions connecting to transitions. In these cases, the places which in a corresponding PN would need to be connected between these transitions, are implied as part of the arcs which connect them. This is shown in the join figure, which contains a token on each arc, both of which being present allows
z+ to fire. For the fork example, once p+ has fired, a token will be available on all
following arcs.
An STG can be used to model a system such as the stopwatch example, as it is derived from PNs, but their usage is aimed at much lower-level specifications for circuits, at signal-level. For STGs we will use the concurrency example, which can be seen in state graph form in Figure 2.2, and PN form in Figure 2.8.
Figure 2.10: A system featuring concurrency in STG form
Figure 2.10 is very similar to the PN form, but without the places this simply shows the causality between signal transitions, one signal transition causing another, and so-on.
The initial state is indicated by the tokens contained by the arcs from x- to both a+
and b+.
If we add in a signal c as before, which is also required to transition concurrently
with a and b for x to transition in the same direction, the result is similar to the PN
Figure 2.11: An STG with 3 concurrent signal transitions
2.3.1
STG design flow
STGs are commonly used for the specification of asynchronous circuits, and as such feature a design flow, taking a specification, verifying this and then synthesizing it for an implementation. In this section, we will discuss the ordering of this design flow, and the tool support available. We will also discuss disadvantages that are faced using this approach.
A specification using STGs is often started with a blank page, and transitions, places and arcs are added in manually as behaviours and interactions of the system being specified are covered. Workcraft is a software suite which provides a GUI for modelling and specifying systems with multiple interpreted graph models, including FSMs, state graphs, PNs and STGs [17][18]. This software can be used to create STGs visually.
Both during and following a specification being prepared, simulation can take place using Workcraft. This aids in the design process, allowing a user to simulate as they create, and can determine where their design does not operate as expected, allowing them to fix errors as they work.
For an STG to be considered correct and usable for synthesis, it needs to satisfy certain properties, which are discussed in Section 4.7. Workcraft also features integrated back-end tools to automatically perform verification, such as MPSAT [20] [21]. MPSAT tests whether a specification satisfies these properties, and can also verify for any custom properties a user chooses. If a system fails verification, this must be fixed in order for the system to be synthesized.
Fixing or debugging these verification errors becomes more difficult the larger an STG becomes. Finding the relevant area can become difficult, with a multitude of transitions, places and arcs interconnected which may need to be changed. This can also make comprehension difficult for a user who did not design this system initially.
mined, through simulation, to work as desired, this specification can then be synthesized. This process determines the Boolean equations which describe the output (and internal) signals as functions of the environment. These functions can then be used to determine a set of logic gates which satisfy the equation, providing a logic gate implementation which can be used in a circuit design.
Using the example from Figure 2.11, we can synthesize this. We start by finding
what causes the output, signal x, to rise. From the STG we can see that this requires
that a+, b+ and c+ have all occurred. Thus, for the output to go high we provide the
boolean function, known as the set function, set : a∧b∧c. For the output to go low,
known as the reset function, we look at the STG and find that this occurs after a-,b-
and c- have all occurred, therefore the reset function will be reset : a∧b∧c.
These functions can then be checked against a library, which contain the set and reset functions of various gates, and is used to map these functions onto existing gates. In this case, the result features at least one C-element. Synthesis can again be performed automatically by some tools, such as MPSAT and Petrify [19], which are integrated into Workcraft. The possible results of this synthesis can be found in Figure 2.12.
The specifications generated by this design flow tend to become monolithic, and any features of one specification which may be useful in future specifications are difficult to identify in a large specification and re-use. Therefore, a future design must again begin with a blank page, which makes future designs slower. While STGs are commonly used for design of asynchronous circuits, the lack of reusability, and the difficulty in compre- hending, editing and debugging specifications can make this design flow undesirable.