Heterogeneous Petri net methodology for the design of complex controllers

D.C. Hendry

Indexing terms: Synchronous controllers, Petri nefs, Synthesis

I 1 Abstract: A controller design methodology based on Petri nets is developed. The semantics of the method, and the algorithm for the construction of an equivalent finite state machine make use of both synchronous and asynchronous marking graphs giving rise to the name 'heterogeneous Petri nets'. The method allows the designer of a controller greater freedom in the use of well struc- tured graphics specifying the controller while the supporting CAD tool ensures an efficient (in the sense of clock-cycle usage) derivation of an equiv- alent finite state machine.

1 Introduction

In the design of digital systems a synchronous controller is one of the central concepts in the subdivision of the overall system into components of manageable complex- ity. The most widely used approach to controller specifi- cation is the finite state machine (FSM) method and variations on that method. As controller design becomes more complex, especially when concurrency is present, the application of these techniques becomes more onerous, requiring new specification techniques to be developed. Extensions of the FSM approach which address these problems are algorithmic state machines [l], state charts [2], communicating FSMs [3] and Petri nets [4-61.

The issue addressed here is the complexity which occurs in the design of a single clock-cycle. This occurs where the specification technique requires that the detailed allocation of controller actions to clock-cycles is given by the designer. In practice, the designer wishes to specify the constraints between actions, and then to have the various actions accomplished in as few clock-cycles as possible. Thus the designer may wish to specify that certain output signals from the controller to a data path unit are to form a given sequence, and that the start of that sequence is to be synchronised with some event occurring in a bus interface unit. Current design tech- niques require the designer to specify such an operation in terms of how the control inputs then give rise to the appropriate signals to the data path, rather than allowing the event to be specified, and that the data path should then be activated as soon as possible after that event has

0 IEE, 1994 Paper 1270E (C2, CE), first received 12th July 1993 and in revised form 7th February 1994 The author is with the Department of Engineering, University of Aberdeen, Fraser Noble Building, Kings College, Aberdeen, AB9 2UE, United Kingdom

I E E Proc.-Comput. Digit. Tech., Vol. 141, No. 5, September 1994

occurred. The controller design technique reported here addresses this problem.

2 Petri net model

Originally devised as a model of asynchronous concur- rent systems [7, 81, Petri nets have been used in the description of controllers for synchronous systems [4-61, where the controller output signals are associated with both places (Moore outputs) and transitions (Mealy outputs). In the synchronous Petri net models used to date, in moving from one marking to the next, the passage of one clock-cycle is asumed. It is this restriction that we wish to remove.

The Petri net model used in this work is as follows. The graph is to be constructed from places and tran- sitions. Two types of transition are employed. Based on the graphics used to denote them these two types of tran- sition are called linear transitions, and rectangular tran- sitions. Places in the graph will be drawn as circles, linear transitions as a line, and rectangular transitions as a box. Places and transitions are connected by directed edges. The output or input transitions of a place may be linear or rectangular. For both types of transitions, input edges arise from places and output edges end on places. No edges connect linear to/from rectangular transitions. The logic inputs to the controller, appear as labels on the edges connecting places to transitions (either type). The control outputs appear in expressions contained within the rectangular transitions. No control outputs are associated with either places or linear transitions. The firing rule for a transition is that all input places must be marked, and any control inputs associated with edges to the transition which is to be fired must be true.

Consider an example (Fig. 1) in which a data path component reads from a data bus using the handshake

avail - avail' 1- c

load=l ack<=l

action'

Fig. 1 Example model with initial marking

293

signals avail and ack. Suppose in this diagram that tokens are initially placed as in Fig. 1. The left-hand token circulates in a wait loop until the control input signal avail goes true. A clock-cycle is required to pass for each time round the wait loop. When avail is true the top centre transition may fire giving a single token which then passes to the central rectangular transition. The firing of the linear transition does not require the passage of a clock-cycle. When the rectangular transition fires the controller output signal load goes true for the duration of that clock-cycle, the output signal ack goes true and stays true after the end of the clock cycle. The left-hand side of the diagram then completes the bus transaction, first waiting with a further wait loop for the avail signal to go false, and when this has occurred ack is then set false. The right-hand side of the diagram provides three control outputs s l , s2 and s3 which dictate the operation of the data path. If the input action is true then s2 and then s3 are activated in successive clock-cycles, otherwise sl is activated in a single clock-cycle.

When described in the FSM formalism this controller has 12 states and 25 edges. Two notations are supported for assigning values to controller outputs. In the centre rectangular transition the statements load = 1 and ack < = 1 appear. All outputs are assigned default values at the beginning of the specification. Within rectangular transitions outputs may be indicated as being at a given logic value for the duration of that clock-cycle using the signal = value notation, or alternatively, an output may be indicated as taking on a given value until another rec- tangular transition changes that value using the signal < = value notation. Certain rectangular transitions do not cause any changes in output signal but are present to indicate the passage of a clock-cycle. Such transitions are annotated with null. These are typically used in wait loops. The right-hand side of the diagram deals with the operation of the data path. This involves either the acti- vation of a signal sl if action is false, or else s2 followed by s3 if action is true.

The model graphics are similar to those used in Refer- ence 9 where the transitions are also divided into two types: the immediate transitions denoted by lines, and the timed transitions denoted by thicker bars. As here, the immediate transitions fire in zero time. The timed tran- sitions, however, fire in a statistically random manner as required for the very different goals of that work, namely performance modelling. The design of controllers is also addressed, among other problems, by Grafcet [lo]. A wide variety of Petri net based models are discussed in Reference 10 and applied to performance modelling and the design of asynchronous controllers. The method of implementing the controllers devised there, however, is by software, or by direct emulation of the Petri net in hardware.

3 Controller derivation

The mechanism for the construction of the controller must be well defined in the sense that it has a sound, preferably mathematical basis, that it is implementable, and perhaps most importantly it should be simple and natural from the point of view of the user of the method-

The mechanism used is that of the marking graph [SI. It is useful to review the differences between a synchro- nous and an asynchronous marking graph. An asynchro- nous marking graph is computed starting from an initial marking of the Petri net. The edges of the marking graph

ology.

294

indicate which transition firing gave rise to the successor marking. Fig. 2 shows a Petri net and its asynchronous and synchronous marking graph.

0 3 d I

a Fig. 2 (I example net

I

b

b asynchronous marking graph for this net c synchronous marking graph lor this ne1

When the synchronous marking graph is constructed (Fig. 2c) the successors to a node in the marking graph may arise from the firing of multiple transitions. In a syn- chronous marking graph there is the idea that two tran- sitions may fire simultaneously, this does not arise in the asynchronous marking graph. Thus in the asynchronous marking graph (Fig. 2b) either transition b or transition c fires, followed by the other. In the synchronous marking graph, in which the firing of transitions is assumed to be tied to a clock-cycle, both transitions may fire simulta- neously, that is, in the same clock-cycle. In general, the node set of the synchronous marking graph is a subset of that of the asynchronous marking graph. The edge set will differ, in that the labels of the edges may now include multiple transition names in the synchronous case, whereas only single transition names will label edges in the asynchronous case. Certain nodes in either marking graph type will have no successors, that is, having reached that state no transition is enabled for any com- bination of the control inputs. Such a node in which no transition is live is termed a dead node.

Informally the algorithm used to construct the con- troller is as follows. Each state of the controller is defined by those rectangular transitions which are to be active during that state, and the status of the output signals. In one clock-cycle a number of rectangular transitions fire synchronously, i.e. their associated control outputs take on the specified value. At the end of the clock-cycle the linear transitions fire asynchronously according to the firing rules of the Petri net and the state of the control inputs. This leads to a new set of rectangular transitions which will be active in the next clock-cycle, i.e. fire syn- chronously in the next clock-cycle. A synchronous marking graph is then constructed, in which the places immediately preceding the rectangular transitions are marked. To compute the successors of a node in this syn- chronous marking graph, asynchronous marking graphs are computed.

The rectangular transitions may be transformed to allow a formulation of the problem in terms of linear transitions only. Each rectangular transition t' is replaced by two linear transitions and two places, as shown in Fig. 3. The input edges to timrr are equal to the input edges of t', and the output edges of titorr are equal to the output edges of t'. Applying such a transform to the availAck example net of Fig. 1 gives Fig. 4 (the partial numbering of places is used later).

IEE Proc.-Comput. Digit. Tech., Vol. 141, No. 5, September 1994

Assume now that an initial marking of the net is given which certainly includes some of the pend places, but no psrolr places. The asynchronous marking graph is then

Fig. 3 Transforming rectangular transitions

- action Fig. 4 Example net ofFig. 1 after transformation

computed. This graph is assumed to be finite (the lack of any output arcs from the P , ~ . , ~ places ensures this in the absence of specification errors). At each stage of the com- putation of this asynchronous marking graph a Boolean expression is built which represents the state of the control inputs required for that marking to occur. From the resulting asynchronous marking graph only the dead markings are retained. The initial marking defines one state of the equivalent FSM, and each of the dead mark- ings defines a next state. The Boolean expression of control inputs gives the input condition required for the transition from the original state to the next state to occur.

Using the numbering of places in Fig. 4, then for an initial marking of place 1 only, the dead nodes of the resulting asynchronous marking graph and their control expressions are (a trailing ’ denotes negation)

Marked places Control expression

4, 9 avail’.action 6, 9 avail.action 4, 8 avail’.action’ 6, 8 avail.action’

For each combination of control inputs there is in this case a single dead marking, a single next state. To con- tinue the computation of the equivalent state machine, any tokens in psra,, places are moved to the corresponding pend places. Controller outputs are updated according to the statements in the original rectangular transitions.

IEE Proc.-Comput. Digit. Tech., Vol. 141, No. 5, September 1994

These new markings are then compared with the current contents of the synchronous marking graph, and if not previously seen, added to the synchronous graph. The process continues with the computation of new asynchro- nous marking graphs.

It may be, however, that a given set of control inputs gives rise to more than one dead marking. This would occur in Fig. 1 if the control input action were omitted from the specification. So one interpretation is that an error in specification has occurred. There are useful Petri net structures, however, where this situation arises that are also attractive for controller specification. Among these is the ADA rendezvous structure. Fig. 5 shows a

w Fig. 5 Net with renderuous construct

description of a system in which two CPUs (central pro- cessing units) share a bus access unit. Associated with the two rectangular transitions would be control outputs which likely move data to or from one of the CPUs to the bus access unit. In effect the bus access unit is willing to rendezvous with either CPU. The forward conflict arises when both CPUs simultaneously, that is in the same clock cycle, require access to the bus access unit. Again the division of time into discrete clock-cycles allows events to be considered as simultaneous, a descrip- tion which is not applicable in a purely asynchronous system. In a FSM description of the problem, the designer would simply decide which of the two CPUs is to have the higher priority. In the current work such a mechanism is supported by allowing the designer to pri- oritise transitions. This priority is then used to discrimi- nate between different dead markings of an asynchronous graph which cannot otherwise be differentiated. If the designer has not supplied priorities to differentiate the two, then an error is reported.

In the absence of such errors the complete synchro- nous marking graph of the Petri net is computed. This provides nodes connected by Boolean expressions of the control inputs, and the required control outputs are with each node. This structure is sufficient to define the equiv- alent FSM. In the supporting software, this description is output in the format of a KISS file suitable for processing by further CAD tools. Notwithstanding the following paragraph, the software does not, and it is not intended to, provide a final mapping to logic. That mapping, which will often include state assignment, is the responsibility of subsequent tools. The software does, however, provide guidance to following synthesis tools.

For large controllers, a state assignment based on techniques similar to those reported in Reference 4, may be computed. In the work reported herein we have found that the computation of the marking graph is not a limi- tation, and so no division into ‘macronets’ is used. Com- puting time is generally short, being a few seconds for useful examples.

295

4 Comparison with other techniques

The competing techniques to this methodology are state charts [Z]. and communicating FSMs [SI. The three techniques, heterogeneous Petri nets, state charts and communicating FSMs will now be compared under the three headings of: concurrency and synchronisation, modularity and clock-cycle optimisation.

4.1 Concurrency and synchronisation All three techniques address the Cartesian product com- plexity in essentially the same fashion. Using state charts the AND decomposition allows a superstate to be con- structed from a number of orthogonal subsystems. Like- wise communicating FSMs may describe a system as a number of individual FSMs. With Petri nets these con- structs can be directly mapped and the ‘control point’ in each submachine indicated by the position of a token.

Differences between the three methods are apparent, however, when synchronisation between the components of the controller is considered. Given that this issue was instrumental in the conception of Petri nets it is not sur- prising that the heterogeneous Petri nets should be the most developed. Examples of synchronisation between processes using the Petri net method are given in Refer- ences 8 and 10. For the synchronisation of processes using the state chart method it is necessary to use the state names as conditions on the transitions, as in Fig. 6.

fork operotion Frm join operotion

-1

Fig. 6 Process synchronisation with statecharts

A similar situation arises with communicating FSMs (see Fig. 7) again state names are used in the condition neces- sary for a transition to occur.

The representations given in Figs. 6 and 7 commit an additional clock-cycle to that control step. To avoid such an additional clock-cycle the designer would be required to interweave the synchronisation construct with what- ever steps follow, so losing any mnemonic value in the graphics. In this respect heterogeneous Petri nets are superior to their competitors. With heterogeneous Petri nets, fork and join can always use the same representa- tion with linear transitions which do not commit the designer to a wasted clock-cycle.

4.2 Modularity Modularity is supported by all three methods to some extent. The state chart method provides the most nota- tional constructs for modularity and useful semantic functions. A single transition line for example may be used to indicate that any of a number of states are to be excited to enter (or re-enter) another state of the design.

With the heterogeneous Petri net method the linear transitions can be freely used to connect any number of subnets in the desired manner, since the linear transitions do not then incur a performance penalty. Other authors in a different context [4] have used the ‘superplace’ nota- tion to impose a hierarchical structure on Petri nets, Global exit of superplaces is not, however, directly sup- ported. Any superplace which requires such a mechanism must be internally crafted to provide the necessary tran- sitions. This is eased by the use of prioritised transitions as described above for the resolution of forward conflicts.

The communicating FSM method could also be said to support modularisation, by the simple expedient of dividing individual FSMs into sections and labelling these as subcomponents. It is the least satisfactory from this viewpoint, however, since such a division may, of necessity, incur additional clock-cycles.

4.3 Clock cycle optimisation As controllers become more complex it is increasingly difficult and/or time consuming for the designer to effi- ciently utilise all clock-cycles. Fig. 8 illustrates the point,

11’ I1

Y a

Fig. 8 a Section of net representing 0, I or 2 clock-cycles b FSM representation

b

Fig. 7

296

Process synchronisation with communicating F S M s

comparing the heterogeneous Petri net method with the FSM method.

The heterogeneous Petri net method (Fig. 8 4 illus- trates the decision process based on the control inputs i l and i2 in a natural manner. The given section of a heter- ogeneous Petri net when executed will require zero clock- cycles if il = i2 = 1, one clock cycle if one of i l or i2 equals 0 (but not both), and two clock cycles if

I E E Proc.-Comput. Digit. Tech., Vol. 141, No. 5 , September 1994

il = i2 = 0. The FSM representation of (nearly) the same controller shows how it is necessary for the designer to compute the combinations of inputs which give rise to different next states to obtain an equally efficient imple- mentation. The FSM diagram in Fig. 8 is not equivalent to the Petri net diagram since it requires at least one clock-cycle to execute, compared to a minimum of zero clock-cycles for the Petri net.

Both the state chart and the communicating FSM method require the designer to specify at this clock-cycle by clock-cycle level, restricting the designer’s freedom to structure the specification. At the same time as providing the designer with a higher level of specification, the heter- ogeneous Petri net method still allows the designer detailed control Gver clock-cycle behaviour where it is required. The null rectangular transitions can be used to provide this where necessary. Thus if a data path requires that signals are held for certain number of clock-cycles this can be achieved through the use of the signal < =value notation and the use of null.

5 Conclusions

The heterogeneous Petri net method for controller spe- cification provides a useful technique capable of address- ing the most pressing problems faced by designers of controllers for complex systems. This is achieved with the minimum of syntactical constructs. Graphical representa- tions with good mnemonic value are provided. Since the technique is based on the well understood, and well defined, asynchronous and synchronous marking graphs a well defined mathematical foundation is provided for automation. The CAD tool constructed as part of this

work is computationally efficient and can also provide useful guidance on state code assignment for subsequent synthesis tools.

6 References

1 CLARE, C.: ‘Designing logic systems using state machines’ (McGraw Hill, Maidenhead, UK, 1972)

2 DRUSINSKY, D., and HAREL, D.: ‘Using statecharts for hard- ware description and synthesis’, IEEE Trans., 1989, C A D 4 (7), pp. mx-xni

3 BELHADJ, H., GERBAUX, L., BERTRAND, M.C., and SAUCIER, G.: ‘Specification and synthesis of communicating finite state machines’. Proceedings IFIP Workshop on Control Domi- nated Synthesis from a Register Transfer Level Description, Grenoble, 1992, pp. 50-59

4 AMROUN, A., and BOLTON, M.: ‘Synthesis of controllers from Petri net descriptions and application of ELLA. Proceedings of the IMEC-IFIP International Workshop on Applied Formal Methods for Correct VLSI Design, 1989, pp. 57-74

5 AUGIN, M., BOERI, F., and ANDRE, C.: ‘Systematic method of realisation of interpreted Petri nets’, Digital Processes, 1980, 6, (1&2), pp. 55-67

6 PARDEY, J., and BOLTON, M.: ‘Parallel controller synthesis for concurrent data paths’. Proceedings IFIP Workshop on Control Dominated Synthesis from a Register Transfer Level Description, Grenoble, 1992, pp. 16-19

7 PETRI, C.: ‘Fundamentals of a theory of asynchronous information flow’. Information Processing 62, Proceedings of the 1962 IFIP Congress, North Holland, Amsterdam, pp. 386-390

8 PETERSON, J.L.: ‘Petri net theory and the modelling of systems’ (Prentice Hall, Englewood Cliffs, NJ, 1981)

9 MARSAN, M.A., CONTE, G., and BALBO, G.: ‘A class of gener- alised stochastic Petri nets for the performance evaluation of multi- processor systems’, ACM Trans. Comput. Syst., 1984, 2, (2), pp. 93-122

10 DAVID, R., and ALLA, H.: ‘Petri nets and Grafcet’ (Prentice Hall, Englewood Cliffs, NJ, 1992)

I E E Proc.-Compui. Digit. Tech., Vol. 141, No. 5 , September I994 297