From UML statecharts to FPGA — the HiCoS approach ∗ Grzegorz L Ã abiak University of Zielona G´ora ul. Podg´orna 50, 65-246 Zielona G´ora, Poland
[email protected]
Abstract The author in his research has focused on real time digital controllers which traditionally are designed as finite state machines or Petri nets. Such controllers can be effectively modelled with some subset of UML statecharts and next can directly be implemented in programmable logic devices (for example FPGA). This transformation is being realized by a system known as HiCoS (abbreviation comes from Hierarchical Concurrent System) designed and developed at University of Zielona G´ora by the author.
1
Introduction
One of the main widely understood task of computer programming is to model real world and UML language is assigned to model those program artifacts which represents real world entities. As it is commonly known, UML technology modelling capabilities are not confined to any particular fragment of reality, hence an idea came into existence to use this technology in modelling those aspects which concern with digital circuits design. This approach is especially essential in context of reactive systems modelling, because program objects or components in general have reactive nature. The fundamental destiny of the UML is visualizing, specifying, constructing and documenting the artifacts of a software-intensive system [UML03]. The author undertook the assignment to research application of the UML in digital circuit design. Not each of nine standardized diagrams can equally be applied in proposed design process. The most important are use case diagram, sequential diagram, activity diagram, collaboration diagram and statechart diagrams. Against the background of those four, statechart diagrams appear to be formal and precise enough that in digital controllers design can play role of a behaviour specification medium between human and a computer.
2
Statechart diagrams
The statecharts formalism was developed as a visual formalism for complex systems [Har87]. It is a state-base graphical notation which can be perceived as extension of state transition graph of traditional finite state machine. In comparison with FSM they are enhanced with concurrency, hierarchy and broadcasting mechanism. The big problem with statecharts is semantics. Variety of applications domain caused that many authors proposed its own semantics [vdB94], sometimes differing significantly. Semantics presented in this paper is intended for specifying behaviour of binary digital controllers. ∗ The scientific work is sponsored by State Committee for Scientific Research in the years 2003-2005 as a research project number 4 T11C 006 24
2.1
Syntax and semantics
Not every element of UML statecharts syntax is supported in HiCoS approach. The selection of language characteristic was made based on application domain and technical constrains of programmable logic devices. As a result of those considerations it was assumed that system HiCoS [ÃLab02] is to be dedicated for untimed control systems which operate on binary values. Moreover, the research was divided into two stages delimiting them with modular paradigm. Hence, HiCoS statecharts characterize by hierarchy and concurrency, simple state, composite state, end state, discrete events, actions assigned to state (entry, do, exit), simple transitions, history attribute and logic predicates imposed on transitions. Other very essential issue is allowing to use feedbacks, it means that events generated in a circuits can affects its behaviour. The role of an end state is to prevent from taking away activity from a sequential automaton before the end state became active. Such elements as factored transition paths and time was rejected, whereas others as cross-level and composite transitions, synch states have been shifted to the second stage of the research. Example of statechart is depicted in figure 1, where also AND-OR tree is presented (sometimes called hierarchy tree). s0 s0 s1 s11 s12
H*
t1
s1
s3
s2
t2 t5
s6
s5
s11
t6
entry / e1 t4
t3
t3
s3 t4
s4
t5
s5 t1
t2
s12
s4 states with memory
s6
t6
s2
Figure 1: Statechart diagram and its AND-OR tree.
2.2
Some auxiliary notions
To give a description of a statecharts synthesis in a comprehensible way it is necessary to introduce some auxiliary notions. Because of lack of space explanations will be given by means of examples in a descriptive informal fashion. Formal definitions can be found in [Kar03, L Ã ab01b, L Ã ab01a]. The examples inserted below refer to the diagram from figure 1. path(s1 , s2 ) — path between state s1 and state s2 is a set of states belonging to the path carried between them in hierarchy tree, for example path(s0 , s5 ) = {s0 , s1 , s11 , s3 , s5 } root — is a state located on top of a hierarchy tree, for example root = s0 . encond(ti ) — transition enabling condition, for transition ti to be enabled it is necessary to meet tree requirements: transition source state is active, every subordinate end state (if exist) is active, predicate imposed on transition is fulfilled. For example, let us assume that in figure 1 state s2 is active. Then enabled transition is only t2 .
parent(si ) — directly superordinate state. Every state has a parent state, except for root state. For example parent(s5 ) = s3 . hrc(si ) — is a hierarchy function, which for state si gives set of directly subordinate states, for example hrc(s3 ) = {s5 , s6 }. automaton — is a set of state on the same hierarchy level, which have the same parent state and are in sequential relationships, for example: s5 , s6 . sd — is a default state, this is the state from which automaton starts, eg s1 is a default state. •s , i
s•i — are, respectively, set of directly input and output transitions, eg •s1 = {t2 }, s•1 = {t1 }.
3
Statechart diagrams synthesis
The issue of digital synthesis of statecharts are not frequently present in current literature. The first proposition was contained in the paper [DH89], where statecharts are perceived as a tree of interconnected machines. The machines in particular can be implemented as classic finite state machine. In the next paper dealing with statecharts synthesis Drusinsky [DY91] proposed new original encoding scheme in which configurations of statecharts are coded in transition oriented manner. In [Ram99] Ramesh gave some improvements to Drusinky’s method. However, these approaches still does not allow to uses feedback signals and does not support history attribute and because these concepts were developed before UML technology became known, they does not regard entry, do and exit actions. Those omitted syntax elements are contained in author’s proposal. Yet other approach presented by K. Buchenrieder et al. [BPV96] is based on Application Specific Instruction Processor (ASIP). Finally, most popular synthesis method is implemented in STATEMATE Magnum software [HDL00], where statecharts diagrams are translated into HDL languages (VHDL and Verilog) with the use of such a sequential structures like process or always. The author proposes new state oriented configuration encoding scheme which is based on direct implementation in RTL-VHDL, allows to use history attribute and for which formal methods can easily be adopted [ÃLab01b, Kar03].
3.1
Dynamic characteristics of hardware implementation
Digital controller specified with Statechart and realized as a electronic circuit is meant to work in an environment which prompts the controller by means of events. It is assumed that every event (incoming, outgoing and internal) is bound with discrete time domain. The controller is reacting on set of accessible events in system through firing set of enabled transitions called microstep. Because of feedback, execution of a microstep entails generating farther events and cause firing subsequent microsteps. Events triggered during current microstep does not influence on transitions being realized, but are only allowed to affect behaviour of a controller in next tick of discrete time, that is, in the next microstep. A sequence of subsequently generated microsteps is called a step and additionally it is assumed that during a step no events can come from the outside world. The step is said to be finished when there is no enabled transitions. Figure 2 depicts a step which consists of two simple microsteps. After the step is finished the system is in state STOP. Summarizing, dynamic characteristics of hardware implementation are as follows: • system is synchronous, • system reacts to the set of available events through transition executions, • generated events are accessible to the system during next tick of the clock.
START t1: i / {t1} ACTION entry / entr do / d exit / ext t2: t1 / {t2} STOP
Figure 2: Simple diagram and its waveforms. In figure 2 simply diagram and its waveforms illustrate assumed dynamics features. When transition t1 is fired (T = 350) event t1 is broadcast and becomes available to the system at next instant of discrete time (T = 450). Activity moves from state START to state ACTION. Now transition t2 become enabled. Its source state is active and predicated impose on it (event t1 ) is met. So, at instant of time T = 450 system transforms activity to the state STOP and triggers event t2 , which does not affect any other transition. The step is finished.
3.2
Foundations of hardware implementation
The main assumption of a hardware implementation behaviour described with statecharets diagram is that the systems specified in this way can directly be mapped into programmable logic devices. This means that elements from a diagram (for example states or events) are to be in direct correspondence with resources available in a programmable device — mainly flip-flops and programmable combinatorial logic. Basing on that assumption and taking into account assumed dynamic characteristics, following foundations of hardware implementation has been formulated: • each state is assigned one flip-flop — activity means that state associated with the flip-flop can be active or in case of a state with history attribute is remembered its past activity; activity of state is established on the basis of activity of flip-flops assigned to superordinate states (in sense of hierarchy), • each event is also assigned one flip-flop — activity means occurrence of associated event and is sustained to the next tick of discrete time when the event become available do the system, • based on diagram topography and rules of transition executions, excitation functions are created for each flip-flop in a circuit. Farther statechart diagrams synthesis description is mainly revolving around specification of flip-flop excitation functions of two type: state flip-flops and event flip-flops.
3.3
State flip-flop excitation functions
Every state is assigned one flip-flop. Logic 1 on its output means occurrence of one of two situations:
• activity of state (to whom the flip-flop was assigned), • remembering that the state was most recently active — this takes place in case of states with history attribute. These two circumstances are essentially different. Therefore it is necessary to define the rules which will allow to determine the former and the latter situation in an unambiguous way. As far as activity of a state is concerned, this is realized on the basis of activity of flip-flops assigned to the superordinate states. The state is said to be active when every flip-flop bound with the states belonging to the path (in sense of hierarchy tree) carried from the state to the root state (located on top of a hierarchy) is asserted. Formally activating condition is calculated in the following way: Y activecond(s) = si (1) si ∈path(root,s)
where si is a signal from flip-flop output. Having established a role that flip-flop is to play in a digital circuit it is possible to formulate general assumption regarding its excitation function. This function yields 1 when the state bound with given flip-flop is: • not active and in next iteration will be active, • an active state or is, so called, a recently active state (it can take place in case of state with history attribute) and in next iteration will also be active or recently active. One characteristic feature of these two assumptions is causal relationship which consist in that before state became most recently active it must be prior active. This observation leads to state flip-flop excitation function of following shape: δ(s) = activate(s) + s ∗ inactivate(s) {z } | {z } | a
(2)
b
where a and b, respectively, are: a) activating component (activate): it assumes logic 1 when the state bound with a flip-flop is not active and in next iteration will became active; this corresponds to the situation when directly incoming transitions to the state fires or, in case of default states, the state activated is by directly superordinate state, b) sustaining component: it assumes logic 1 when 1) the state bound with a flip-flop is active (it means that component activate must have been fulfilled before) and in next iteration the state will also be active or 2) in case of the state is attributed history property the state is recently active and in next iteration will also be recently active; factor inactivate assume value 1, when the state loses activity and at the same time is not recently active, this corresponds to the situation when one of some output transitions is fired.
inactivate
δ
Q
D
s
s
activate C
Q
Figure 3: Logic diagram of flip-flop excitation function.
A variable s in equation 2, is a feedback signal and its role is to sustain flip-flop activity since the moment specified by activate component till the moment determined by inactivate factor. The excitation function defined in that way leads to the logic diagram presented in figure 3. Farther descriptions of synthesis rules of state flip-flop excitation function are focused around detailed definition of activating components and inactivating factor. Activate component The conclusion which result from what is stated in point a) is that to form an expression for component activate it is necessary to investigate two cases. • The first case hold when normal state (i.e. not being default state) is examined. Then activation of a such states depends only on transitions which directly come to the state. Formally, it is defined by following equation: X encond(ti ) (3) activate(s) = ti ∈•s
• Second case takes place when comes to the state which is default state. Then activation of such a state depends not only on directly incoming transition, but additionally depends on activity of directly superordinate state. When directly superordinate state become active it means that one of its directly subordinate state must also become active. It is as if activity “comes from above”. Equation which describe this case presents as follows: Y X X δ(si ) ∗ activate(sd ) = encond(ti ) + si (4) t ∈•s
|i
{z
}
a
sj ∈path(root,parent(sd ))
|
si ∈hrc(parent(sd ))
} |
{z
{z
}
c
b
Component a is responsible for activating which comes from directly incoming transition, similarly as it is in previous case (eq. no. 3). Factor b is referring to the activation which is caused by directly superordinate state. This factor is in fact modified activating condition (see eq. no. 1). δ is a flip-flop activating function and as a signal is taken from flip-flop input. This means that factor b represents activity of the parent state in next tick of discrete time. Factor c allows to activate flip-flop only when there is no other active flip-flop. Activity of other flip-flop means that default state flip-flop must not be activated, because the other flip-flop remembers past activity of the other state to whom it is bound with. Inactivate factor This factor is to assume value 1 when the state to whom a flip-flop is bound with is to lose activity and at the same time is not recently active state. The situation arise in consequence of firing some output transitions. The issue is which are these output transitions. This depends both on whether investigated state is an end state or normal state (in this context normal state means not end state) and on a presence of history attribute and also on whether investigated state belongs to the automaton with an end state. The latter case means that transitions of higher levels of hierarchy cannot take activity. First, to put it in an order, let us consider four cases when state is a normal state and has or not history attribute. • state without history attribute belonging to the automaton without an end state: X Y inactivate(s) = encond(ti ) + δ(si ) ti ∈s•
|
{z a
}
si ∈path(root,parent(s))
|
{z
(5)
}
b
Flip-flop is reset by firing of directly outgoing transitions from state s (component a) or by firing output transitions of superordinate states. The latter case, in equation, is represented by negated activity condition of directly superordinate state (component b).
• state without history attribute belonging to the automaton with an end state, • state with history attribute belonging to automaton without an end state, • state with history attribute belonging to automaton with an end state: X inactivate(s) = encond(ti )
(6)
ti ∈s•
In these three cases only directly outgoing transitions can reset flip-flop. This result from semantics and from taken assumption as to what role plays activity of flip-flop. Now there is an end state case left to investigate. An end state can have or not history attribute, so it gives two next situations to analyze: • end state without history Y
inactivate(s) =
δ(si )
si ∈path(root,parent(s))
|
{z
(7)
}
b
An end state must not have directly outgoing transitions, but its activity can be taken by transitions of higher levels of hierarchy (see also eq. no. 5). • end state with history attribute: inactivate(endst) = 0
(8)
Attribution of history property to an end state means that a flip-flop bound with such a state will never be reset, because an end state must not have directly outgoing transitions and reactivating automaton with such a state, as result of firing transition of higher levels of hierarchy, will always cause activating the end state. In general, ascribing history attribute to the automaton with an end state makes no sense and hence is not recommended.
3.4
Event flip-flop excitation functions
Hardware implementation in FPGA structures is based on the assumption that the circuit responds to the set of currently available events in next tick of discrete time. Between an event and a respond to it there is a period of time equal to a period of clock signal. To fulfill this assumption there is a necessity to bound with every place in circuit where event can be triggered one flip-flop. The flip-flop’s assignment is to sustain information about an event for the clock signal period. Basically, there are four possible places where an event can be generated: Transition Firing transition can be assigned broadcasting set of events. Excitation function of such a flip-flop is a simple enabling transition condition: δ(et ) = encond(t)
(9)
Entry action Every state can be assigned an entry action, which is executed when state is being activated. This is, of course, broadcast set of events. Activation of a state takes place when, at given moment of discrete time, state is not active (factor a) and at next instant of time will become active (factor b): Y δ(een ) = activecond(s) ∗ δ(si ) (10) | {z } si ∈path(root,s) a | {z } b
Do action Sometimes called static action is a set of events which are broadcast at every tick of clock signal, as long as state to whom the action is ascribed is active. Therefore, an excitation function boils down to the state flip-flop excitation function (see section 3.3). Exit action This action complements entry action and is being executed when given state is active (factor a) and at next instant of time will lose activity (factor b): Y δ(eex ) = activecond(s) ∗ (11) δ(si ) | {z } si ∈path(root,s) a | {z } b
activate1
inactivate1
D
Q
C
Q
s1
D
Q
C
Q
D
Q
C
Q
e1
s3 + s4
t4
activate3
inactivate3
t2
s2
C
Q
s3
s5 + s6
t3
s3 t4 t5
Q
s1 t1
s5
D
s6
t6
s4 states with memory
t6
activate5
inactivate5
s5
Figure 4: Example of hardware implantation with modified hierarchy tree. Figure 4 depicts a fragment of hardware implementation of the statechart presented in figure 1. In the schematic diagram are presented state flip-flops (s1 , s3 , s5 ) and event flip-flop bound with entry event e1 . It is note worthy that in hardware implementation root state and states directly subordinated to states of type AND (being part of mathematical definition, but not discussed in the paper) like s11 are omitted. This can be done because information contributed by those states is redundant.
4
System HiCoS
System HiCoS [ÃLab02] (see figure 5) automatically converts behaviour described with statecharts into register transfer level. Input model described is in its own textual representation (Statecharts Specification Format) which is equivalent to graphical form, and next is transformed into
Boolean equations. Boolean equations are internally represented by means of BDDs (Binary Decision Diagrams). Next, reachability graph can be built [ÃLab01b] or through RTL-VHDL designed model can be implemented in programmable logic devices. SYSTEM HiCoS Reachability Graph BDD
Boolean Equations BDD
Statecharts SSF
VHDL RTL
FPGA
Figure 5: System HiCos — schematic diagram. Numerous hardware implementations of practical examples and simulation sessions, carried out with the use of HiCoS system, have confirmed that proposed in the paper new method of statecharts synthesis is correct. Table 1 contains properties of four controllers. Garage — controls garage gate and switches on and off light in the garage. TVrm — is a simple TV remote controller which is able to change between two channels and teletext and to switch on and off sound. Reactor — controls chemical process. RIM — is a controller for rotary index machine with three nests. name
#states
#tran.
Garage TVrm Reactor RIM
8 8 20 19
7 8 19 20
#seqential automata 3 4 8 4
#automata with history 0 1 3 0
#hierarchy depth 2 3 3 2
#inputs
#outputs
6 8 10 16
3 5 15 11
Table 1: Properties of controllers. To evaluate synthesis results presented in table 2 it is necessary to give few words of comment. The amount of consumed FPGA resources depends on a few factors. Total number of state flipflops is a sum of a number of local states in a diagram and places where events can be generated. Relations for amount of combinatorial logic consumption are far more complicated. Fundamental factor is a complexity of modelled behaviour, see table 1. Next, rules presented in section 3 play its role. System HiCoS transforms entry behaviour, according to the given rules, where boolean equations are represented by means of BDDs. As it is commonly known, size of binary decision diagram is susceptible to variable ordering. This aspect as well as optimization of logic functions were not investigated in the system. In the end, synthesis and implementation commercial tools (respectively, Leonardo Spectrum and ISE 3.1i by Xilinx ) have its own share in final results. name Garage TVrm Reactor RIM
#IOB 10 14 27 28
#SLICEs 13 11 50 27
%SLICEs 1 1 6.5 3
Max pin delay [ns] 2.1 2.2 3.9 3.7
Table 2: Implementation results for XCV50BG256 device from VIRTEX family.
5
Summary
To assess system HiCoS against the background of the others methodologies it is difficult to carry out simple judgement, because STATEMATE Magnum system [HDL00] and Buchenrieder et al. methods [BPV96] feature completely different approaches. Also, they does not make possible in easy way to conduct symbolic analysis. Only Drusinsky’s method is comparable to the method described by the author, but this method does not take into account history attribute, feedback signals, entry, do and exit actions. Moreover, Drusinski’s methods are protected by patents. Author’s method is free from mentioned drawbacks. Proposed methodology — system HiCoS — can be part of UML technology, where statechart diagrams formally specify behaviour and where use case, collaboration, activity and sequential diagrams support particulars phases of design process: from specification to end user implementation.
References [BPV96] K. Buchenrieder, A. Pyttel, and C. Veith. Mapping statechart models onto an FPGAbased ASIP architecture. In Proc. EURO-DAC ’96, pages 184–189, September 1996. [DH89]
D. Drusinsky and D. Harel. Using Statecharts for Hardware Description and Synthesis. IEEE Transaction on Coputer-Aided Design, 8(7):798–807, July 1989.
[DY91]
D. Drusinsky-Yoresh. A State Assignment Procedure for Single-Block Implementation of State Chart. IEEE Transaction on Coputer-Aided Design, 10(12):1569–1576, December 1991.
[Har87]
D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8:231–274, 1987.
[HDL00] STATEMATE HDL Code Generator Reference Manual. 3 Riverside Drive, Andover, MA 01810 U.S.A., 2000. [Kar03]
A. Karatkevich. Deadlock Analysis in Statecharts. In Forum on specification on Design Languages, September 2003. Accepted for the conference.
[ÃLab01a] G. L Ã abiak. Statecharts Diagram as Linked Hierarchical Sequential Automata. In Proc. of the Fourth Intl. Conference on Computer-Aided Design of Discrete Devices CAD DD-2001, volume 1, pages 38–43, Minsk, Republic of Belarus, 2001. Ã abiak. Symbolic States Exploration of Controllers Specified by Means of State[ÃLab01b] G. L charts. In Proc. of the Intl. Workshop DESDes-01, pages 209–214, Przytok, 2001. [ÃLab02]
G. L Ã abiak. HiCoS - akademicki system do projektowania hierarchicznych wsp´ olbieznych cyfrowych uklad´ow sterowania. In I Krajowa Konferencja Elektroniki, pages 397–402, June 2002.
[Ram99] S. Ramesh. Efficient translation of statecharts to hardware circuits. In Proceedings of Twelfth International Conference On VLSI Design, pages 384–389, January 1999. [UML03] OMG Unified Modeling Languag Specification Version 1.5. OMG, 250 First Avenue, Needham, MA 02494, U.S.A., March 2003. [vdB94] M. von der Beeck. A Comparison of Statecharts Variants. In Proc. of Formal Techniques in real-Time and Fault-Tolerant Systems, Third International Symposium, pages 128–148. Springer-Verlag, September 1994.
