Signal Transition Graph plugin

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:

• – signal transition generator
  – a tool for creating signal transitions with their rising and falling phases (denoted by + and - respectively after the signal name). This tool can also be activated by pressing T.
• – dummy transition generator
  – a tool for creating dummy transitions that do not belong to any signal and do not have rising or falling phase, but rather are used to simplify the structure of the STG. This tool can also be activated by pressing D.

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:

• Ctrl - create a falling phase of an output signal (usually out-).
• Shift - create a rising phase of an input signal (usually in+).
• Ctrl+Shift - create a falling phase of an input signal (usually in-).

The internal signals are less frequently used and therefore there 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:

• producing/consuming arcs – these can be created with the tool for directed connections ;
• read-arcs – these can be created with the tool for undirected connections .

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 the 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:

• Double-click on an empty place to mark it with a token.
• Double-click a place marked with a token to remove the token.
• If a place has more than one token then double-clicking does not have any effect.

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 the simulation of an STG model activate the simulation tool . The enabled transitions 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 (1, 0, or ?).

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 is also defined in this table by rearranging (drag-and-drop) the signal rows.

A number of STG properties can be verified via Verification menu:

• Complete State Coding [MPSat] - verify the STG has Complete State Coding (CSC).
• Consistency [MPSat] - verify that STG signals are consistent (rising and falling transitions of the same signal alternate in all possible traces).
• Deadlock [MPSat] - verify if the STG is deadlock-free.
• Normalcy [MPSat] - check the normalcy property of the STG.
• Output persistency (without dummies) [MPSat] - verify the output signals of the STG are persistent (once enabled they do not get disabled until fired).
• Conformation (without dummies) [MPSat]… - check if this STG conforms to its environment STG (to be chosen in the file selection window).
• Unique State Coding [MPSat] - verify the STG has Unique State Coding (USC).
• Custom properties [MPSat]… - custom properties can be verified through formulation a reachability analysis problem using Reach language in a specialised MPSat configuration window.

Most of these are reachability properties, i.e. verify the if a “violating” state is reachable, In this case 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:

• Show selected core – individual cores in a selected set of cores are highlighted in distinct colours (see the example on the right). This feature can be useful for detailed analysis of the encoding conflicts to make an informed decision on how to manually resolve them.
• Show core density map – the darker shades denote the higher density of the overlapping cores (example on the left). Usually, it is advantageous to insert new signals in the areas where most cores overlap, thus eliminating more conflicts by a single signal. Note that the number of density map levels can be configured in the Maximum number of encoding core density map levels property of Signal Transition Graph model under Edit→Preferences… menu (5 levels by default).

The STG specification can be synthesised into Boolean equations by using Petrify or MPSat as backend tools:

• Petrify is a tool for the synthesis of Petri nets and asynchronous controllers. It explicitly enumerates all states reachable by the specification, encodes them with the vectors of signal values and derives the Boolean equations for the output signals. The full state space exploration limits the applicability of this tool to relatively compact asynchronous controllers (up to few dozens of signals). Apart from logic synthesis, Petrify is also capable of hazard-free decomposition and technology mapping of its solution into the library of available gates.

• MPSat is a model checking and synthesis system that uses Petri net unfoldings as a means to avoid the explicit representation of the specification state space. It relies on SAT solver for the synthesis and verification tasks. MPSat does not (fully) support decomposition and technology mapping yet. On the other hand, MPSat enables verification of several predefined model properties (deadlock, CSC, USC, normalcy) and provides a Reach language to verify custom properties.

These synthesis options are available under the Synthesis menu:

• Complex gate [MPSat] - synthesise the STG in complex gates using MPSat backend tool.
• Complex gate [Petrify] - synthesise the STG in complex gates using Petrify backend tool.
• Generalised C-element [MPSat] - synthesise the STG in generalised C-elements using MPSat backend tool.
• Generalised C-element [Petrify] - synthesise the STG in generalised C-elements using Petrify backend tool.
• Standard C-element [MPSat] - synthesise the STG in standard C-elements using MPSat backend tool.
• Technology mapping [MPSat] - synthesise the STG for a library of available gates using MPSat backend tool.
• Technology mapping [Petrify] - synthesise the STG for a library of available gates using Petrify backend tool. The library of gates can be specified in the under Models→Digital Circuit leaf of the global preferences tree (available via Edit→Preferences menu).

Here is an example of a 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.