Familiarise yourself with Workcraft interface to learn its common features that are available for all plugins.
This plugin is intended for capturing, simulation and verification of Signal Transition Graphs (STGs), that is a special kind of Petri nets whose transitions are associated with signal events.
In order to create an STG model choose File→Create work… menu item and in the New work dialogue select Signal Transition Graph as the model type.
To capture an STG you just put its nodes (places, dummies and signal transitions) on the editor pane and connect them by means of arcs.
Creation of places is similar to that of Petri net plugin, by using the place generator – just click the editor panel in the position you want a new place to appear. However, the creation of transitions is a bit more complicated as there are two classes of transitions in this plugin with their respective node generator tools:
-respectively after the signal name). This tool can also be activated by pressing T.
Three types of signal transitions are supported denoting the input, output and internal events. By default a rising phase of an output signal is created (usually the automatically generated name is
out+ - see Naming of transitions for details) when you click the editor panel. This behaviour can be changed by holding Ctrl and/or Shift keys while creating a signal transition as follows:
The automatic naming for the signal transitions is as follows. A transition is given
out prefix depending on the type of the signal it represents – input or output respectively. Then a numerical suffix is added to the name, starting from
0. If a transition of the same signal already exists, then its type is checked to match the intended type of a newly created transition. If there is a mismatch (e.g. we want to create an output transition
out+ but a transition of an input signal exists that has an ambiguous name
out-) then the numerical suffix
0 is added to the transition name, making it
out0-. If the name
out0 is also taken by another signal type, a dummy or a place, then the suffix is incremented until a new transition of intended type can be created without causing a conflict.
Note that in order to distinguish transitions of the same signal and the same polarity they are assigned instance numbers that are separated from the label by
/ symbol. Therefore two rising transitions of a signal
out have different instance number, e.g.
1 and their full names are
out+/1 respectively. The instance numbers are automatically generated to be unique among transitions of the same phase and of the same signal. Usually the instance numbers do not need to be changed and therefore, for simplicity, they are even hidden in the editor panel. However, the instance number of a transition can be seen and altered if necessary in the property editor.
The automatically generated names for the dummies start from
dum0 and the numerical suffix is incremented for each next dummy. Note that dummies also can have the instance numbers (e.g.
dum/2 are essentially different transitions). However, it is usually more convenient to distinguish the dummies by their name main portion of their names (e.g.
The internal signals are less frequently used and therefore their is no key combination for them. Instead you need to create an output (or input) transition first, then rename it and finally change its signal type in the property editor. Note that renaming of the transition before changing its type is important as otherwise all transitions with the same signal name will change their type.
If no model elements are selected, then the property editor shows the attributes of the whole model. In case of STG these are the names and types of all the signals. This is the good place to change the signals' names, so that all transitions of a renamed signal see the modification.
The STG transitions can be easily recognised by their color. By default the input transitions are red, output - blue, internal - green and dummies are black. This color scheme can be changed in the global preferences under the Common→Signal leaf of the settings tree (accessible via Edit→Preferences… menu item).
There are two types of arcs in STG plugin:
When either of the connection tools is active you can connect places and transitions by first clicking the source node and then the destination node. This will create a straight line connection between the source and the destination nodes. You can also create a polyline connection by clicking the editor panel in the positions of intermediate points, before clicking the destination node.
If you hold Ctrl then the destination node becomes a source for the next arc making it easier to form a sequence of connected nodes.
Note that STG places cannot be connected to each other – if you attempt to connect two places, then a warning will be issued that connections is not valid. However, unlike Petri nets, the STG transitions can be connected to each other without an explicit place in between. This shorthand notation is used when a place has a single transition in its preset and a single transition in its postset. For simplicity such an implicit place is hidden and a directed arc is drawn directly between two transitions.
Read-arcs can only connect places with transitions – if you attempt to connect two places or two transitions with a read-arc, then a warning about invalid connection will be issued. The semantics of a read-arc is that transition reads the marking of the place without consuming its tokens. Note the difference to a pair of consuming and producing arcs between the places and the transition (the former takes the token, and the latter puts it back into the place).
For editing the model activate the selection tool . All the standard editing features (select, drag-and-drop, delete, copy, undo, group, etc.) work the same - see generic help on Selection controls and Property editor for details. The only new feature is double clicking on a place:
The attributes of an implicit place, e.g. the number of tokens or its capacity, can be modified in the property editor of a corresponding arc connecting two transitions. The signal name, phase and instance number of a transition can be changed in the property editor when the transition is selected.
Similar to all the other models, textual comments can be created by activating the tool and clicking the editor panel in the position you want to put the text. Double-click on the note box to edit its text label in-place or do it through the property editor panel when the note is selected.
For simulation of an STG model activate the simulation tool . The enabled transition are highlighted and can be fired by clicking them. The simulation tool controls provide the means for analysis and navigation through the simulation trace, see generic help on Simulation controls for details.
Note that the simulation controls are extended with the signal state table (at the bottom of Tool controls). The Signal column of the table lists all the signals of the STG while the State column captures the current state of each signal. The state of a signal is determined only by the phase of its last transition in the simulation trace. If the last was the signal's rising transition, then the state is
1; if it was a falling transition, then the state is
0. If no transition of a signal has happened yet, then its state is considered unknown and is denoted by a question mark
?. If a signal is excited (i.e. its transition is currently enabled) then its current state is in emphasised by bold font (
In addition to the standard simulation controls, the STG simulator has a generator of trace diagram . It converts the simulation trace into a Digital Timing Diagram – a collection of signal waveforms with causality arcs between signal events. The visibility and color of signals in the timing diagram are defined in Visible and Color columns of the signal state table. The order of signal waveforms are also defined in this table by rearranging (drag-and-drop) the signal rows.
The timing diagram is built for the main simulation trace – Trace column. If the Trace is empty then the timing diagram generator will suggest to use Branch simulation results instead.
A number of STG properties can be verified via Verification menu:
Most of these are reachability properties, i.e. verify the if a “violating” state is reachable, In this case the the verified property is not satisfied and a trace (or a family of traces) leading to the violation is reported. The trace can be passed to the simulation tool (by clicking the Play button) for playback and analysis of the reasons leading to the violation.
Checking for encoding conflicts (Complete State Coding [MPSat] and Unique State Coding [MPSat]) also provides the interface for visualisation of the cores of the encoding conflicts. This feature is demonstrated below for an STG of an A2D controller.
A user can choose between two types of visualisation in the Tool controls panel:
The STG specification can be synthesised into Boolean equations by using Petrify or MPSat as backend tools:
These synthesis options are available under the Synthesis menu:
Here is an example of complex gate synthesis of our example by Petrify. The synthesis result in Verilog format is reported in the Output tab. This Verilog netlist also is automatically converted into a Digital Circuit model.
In case of this example the complex gate implementation is just a buffer between the input in and the output out pins.