A Model-Driven Development Approach to ... - Semantic Scholar

IEEE TRANSACTIONS ON COMPUTERS,

VOL. 57, NO. 10,

OCTOBER 2008

1357

A Model-Driven Development Approach to Mapping UML State Diagrams to Synthesizable VHDL Stephen K. Wood, David H. Akehurst, Oleg Uzenkov, W. Gareth J. Howells, and Klaus D. McDonald-Maier, Senior Member, IEEE Abstract—With the continuing rise in the complexity of embedded systems, there is an emerging need for a higher level modeling environment that facilitates efficient handling of this complexity. The aim here is to produce such a high-level environment using ModelDriven Development (MDD) techniques that map a high-level abstract description of an electronic embedded system into its low-level implementation details. The Unified Modeling Language (UML) is a high-level graphical-based language that is broad enough in scope to model embedded systems hardware circuits. The authors have developed a framework for deriving Very High Speed Integrated Circuit Hardware Description Language (VHDL) code from UML state diagrams and defined a set of rules that enable automated generation of synthesizable VHDL code from UML specifications using MDD techniques. By adopting the techniques and tools described in this paper, the design and implementation of complex state-based systems is greatly simplified. Index Terms—Model-Driven Development (MDD), Unified Modeling Language (UML), VHDL.

Ç 1

INTRODUCTION

A

the design of embedded systems grows ever more complex, we require tools and techniques to aid the developer in managing that complexity. A commonly used technique is to raise the level of the language in which the system can be developed and, recently, there has been a move toward increased use of graphical languages [1], [2]. Object-oriented (OO) modeling has, to date, not been widely employed for the development of embedded systems, perhaps because of a perception that synthesis of OO hardware designs produces inefficient hardware implementations. An alternative approach is to use a standardized high-level design language that includes a notion of object orientation and map this down to a traditional hardware description language (HDL). The Unified Modeling Language (UML) [3] is such a high-level design language and is broad enough in scope to model embedded systems. It is therefore proposed that its use be investigated in a Model-Driven Development (MDD [4]) approach to embedded systems development. The use of such a higher level graphical language has the distinct advantage that it removes complexity from the design S

. S.K. Wood, D.H. Akehurst, and W.G.J. Howells are with the Department of Electronics, University of Kent, Canterbury, Kent, UK CT2 7NZ. E-mail: {S.K. Wood, W.G.J.Howells}@kent.ac.uk, [email protected]. . O. Uzenkov is with Unicore Systems, 60-A Saksaganskogo St., Office 1, Kiev, 01033 Ukraine. E-mail: [email protected]. . K.D. McDonald-Maier is with the Department of Computing and Electronic Systems, University of Essex, Wivenhoe Park, Colchester, CO4 3SQ UK. E-mail: [email protected]. Manuscript received 8 June 2007; revised 31 Oct. 2007; accepted 29 Nov. 2007; published online 22 July 2008. Recommended for acceptance by S.K. Shukla and J.-P. Talpin. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number TCSI-2007-06-0251. Digital Object Identifier no. 10.1109/TC.2008.123. 0018-9340/08/$25.00 ß 2008 IEEE

process and allows a more intuitive method of using graphical representation for the design of the system, which is particularly relevant to state-based systems design. In addition, it allows the design specification to be separated from platform specific description languages, such as SystemC, Very High Speed Integrated Circuit HDL (VHDL) or Verilog, and subsequently facilitates a change of HDL and design technology. The presented methodology is generic and can be applied to any HDL. In order to illustrate the method, the authors have initially targeted VHDL. Several studies have been carried out regarding VHDL code generation from system-level specifications [5], [6], including efforts to address UML [7], [8], [9]. In this work, the MODEASY project team has developed a framework for deriving VHDL specifications from UML state diagrams, a technique used to describe the behavior of a system, and has defined a set of rules that enable automated procedures to generate VHDL code from UML notations. The content of this paper is part of a greater body of work in which these behavior specifications are integrated within larger systems [10]. Using MDD techniques, the authors intend to provide automated support for mapping embedded system designs on to both low-level implementations and system verification toolkits. There is a clear advantage in providing this kind of automated support—namely, that there is a single specification written by the designer, which is used to both verify and implement the system, thus avoiding the significant problem of the introduction of differences between the verified and implemented versions of the system. The specific aims of this work are outlined as follows: 1.

Explore the possibilities of MDD within the embedded systems domain.

Published by the IEEE Computer Society

1358


Propose a mechanism for mapping UML state diagrams to synthesizable VHDL code, using MDD techniques. 3. Demonstrate the use of the resulting tool developed as a proof of concept for automated generation of synthesizable VHDL code from UML notations. The generated VHDL code should be such that it can be fed directly into existing standard Field-Programmable Gate Array (FPGA) or Application-Specific Integrated Circuit (ASIC) design tools, for hardware implementation. The remainder of this paper is organized as follows: Section 2 provides a background summary, with a review of related work on VHDL code generation from system specifications and UML to VHDL transformations. This section also describes an MDD approach to system development and a brief overview of UML and VHDL. Section 3 outlines a specific case study problem to be solved using MDD techniques. In Section 4, a VHDL metamodel is presented, defining the main synthesizable concepts of the language. Section 5 discusses the specialties of this approach to mapping UML state diagrams to VHDL. This section describes techniques used for designing Finite State Machines (FSMs) in VHDL, informal mapping of UML state machine semantics to VHDL, and the way formal transformation rules are defined. It also explains the way in which the transformation implementation is carried out. An example of automated transformation is given in Section 6. Finally, Section 7 draws a conclusion to the work presented. 2.

2

BACKGROUND

As an introduction to the technical sections of this paper, this section provides brief overviews of an MDD approach to system development together with the UML and VHDL design languages on which the work is based. These are followed by details on related work with an investigation into existing approaches to transforming UML state diagrams to VHDL.

2.1 MDD Overview MDD is an approach to software development that focuses on models as the primary artifacts in the development process, with transformations as the primary operation on models, used to map information from one model to another [11]. Model-Driven Architecture (MDA) is a particular variant of the MDD approach by the Object Management Group (OMG), a not-for-profit computer industry specifications consortium. MDA is an initiative to define an approach to system development based on the modeling and automated mapping of models to implementations. The basic MDA pattern involves the definition of a platform-independent model (PIM) and its automated transformation to one or more platform-specific models (PSMs), which are subsequently transformed into the source code. From this perspective, UML can be viewed as a PIM, with VHDL as a PSM. The clear separation between the PIM and PSM models makes it easier to switch to a different HDL, such as Verilog for SystemC, or new implementation technology while reusing the same designs. The ability to transform a

VOL. 57,

NO. 10,

OCTOBER 2008

high-level PIM into a PSM, a model tailored to specify the system in terms of the implementation constructs, raises the level of abstraction at which a developer can work. The model interchange format is based on the XML Metadata Interchange (XMI) standard [12], which makes it easier to share models between applications. The MDA approach is still new and, consequently, there are no standardized transformation techniques that would ensure the generation of code that accurately represents the model. Much of the work carried out on model transformation has been driven by the OMG’s call for proposals on Queries, Views, and Transformations (QVTs) [13], [14]. QVT provides a standard way of describing transformation definitions for model mapping languages. Within MDA, source and target languages are defined through their metamodels. This enables a transformation tool to read, write, and understand models. A metamodel is an explicit model that defines the constructs and rules needed for creating semantic models in a given language. A model is expressed with the help of a language like UML, which emerged as a common foundation for MDA modeling. However, UML is only a notation with no formal semantics attached to the individual diagrams nor is there a formally defined semantics for the integration of the diagrams. Therefore, it has not been possible to apply rigorous automated analysis to verify its behavior or to generate code directly from models [15]. The recent addition of action semantics, compliant with the Action Specification Language (ASL) [16], to UML has led to a creation of executable UML (xUML) profile, which supports the direct execution and verification of UML models that can be directly translated into code. xUML has not yet been established as a standard. OMG has recently issued a request for a proposal for a standardized xUML subset with rigorously defined semantics.

2.2 UML Overview The UML was developed by the OMG as an open standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for modeling other nonsoftware systems. UML is defined [17] as “a family of graphical notations backed by a single metamodel that help in describing and designing software systems, particularly software systems built using the OO style.” The graphical notation is realized through one of a number of diagram types defined for UML, which can be used to create an abstract model of a system, referred to as a UML model. UML 2.0 defines 13 types of diagram, which are divided into three categories that describe static application structure, behavior, and interactions: .

.

Structure diagrams categorize a set of diagrams that depict the elements of a specification that are irrespective of time; these include Class, Component, Composite structure, Deployment, Object, and Package diagrams. Behavior diagrams categorize a set of diagrams that depict behavioral features of a system; these include Activity, State machine, and Use case diagrams.

WOOD ET AL.: A MODEL-DRIVEN DEVELOPMENT APPROACH TO MAPPING UML STATE DIAGRAMS TO SYNTHESIZABLE VHDL

Interaction diagrams are a subset of behavior diagrams that emphasize object interactions using Communication, Interaction overview, Sequence, and Timing diagrams. The abstract syntax of a UML diagram is described using a metamodel, which is defined using a class diagram with classes describing the syntactic components of the UML diagram. As such, a UML diagram can be viewed as an instance of a UML metamodel in the same way in which a set of objects in a system can be considered as an instance of a UML class diagram [15]. In this paper, the authors concentrate on mapping behavioral aspects described by UML 2.0 state diagrams onto a VHDL behavioral specification of an embedded system. A state diagram is a technique to describe the behavior of a system and represents the event-triggered flow of control where objects change state by means of transitions. The UML state machine formalism is an OO variant of statecharts invented by Harel [18]. Harel introduced diagrams that extend traditional state-transition diagrams with a notion of hierarchy and concurrency while extending the notion of actions. .

2.3 VHDL Overview VHDL is an industry standard HDL used to describe the architecture, structure, and behavior of digital electronic systems [19]. Initially conceived as a documentation language, VHDL is particularly suited as a text-based design-entry language for logic circuits to be implemented on FPGAs and ASICs. VHDL allows three levels of design specification: The structural approach describes how the system is decomposed into subsystems and how these subsystems are interconnected. The structural approach can be used to create a low-level description of a circuit (such as a gate-level diagram) or a high-level description (such as a block diagram). 2. The behavioral approach is the highest level of abstraction supported in VHDL, which does not reflect how the design is structured. It permits description of behavior of the circuit by means of high-level language constructs, similar to typical programming language form. 3. The data-flow approach describes the circuit in terms of how data moves through the system (i.e., how information is passed between registers in the circuit). VHDL typically supports mixed-type descriptions. The predominant feature of VHDL is the ability to simulate the design before committing it to manufacturing, allowing designers to quickly compare alternatives and verify the behavior of the system. 1.

2.4 Related Work This section briefly discusses several other projects that have investigated transforming UML state diagrams to VHDL and also graphical entry tools that can generate VHDL from state machine diagrams. There are a number of research studies and commercial tools devoted to VHDL code generation from system-level specifications [2], [5], [6],

1359

[20], [21] and several which specifically address generating VHDL from UML [7], [8], [9], [15]. There are several significant differences between these approaches and the investigation discussed in this paper, which focuses on using complementary MDD techniques and on the development issues specific to electronic embedded systems design. The researchers in [8] undertook an approach to initially translate UML models to a language called SMDL (the language with formal semantics and high-level concepts such as states, queues, and events), which is then compiled into VHDL code; however, they did not use MDD techniques. The approach adopted here, however, attempts to map the high-level concepts as directly as possible to the target language concepts. The authors in [15] have developed a prototype system for generating the VHDL specifications from the UML models. Their approach is similar to the one presented here in that models were transformed using homomorphic mappings between dissimilar structures while preserving metamodel class associations in a way that resembles MDA technique. However, their generated VHDL code is for simulating and verifying the UML models and not for hardware synthesis. The research team in [7] presented a MODCO tool that transforms UML state diagrams directly into synthesizable VHDL using an MDA technique, which uses a similar transformation approach. However, the authors targeted flat state-transition diagrams without covering hierarchy and concurrency and only covered a small subset of UML state diagram constructs. Rhapsody, by Telelogic, is a commercial UML 2.0-based MDD environment for systems and software engineering [1]. It can generate multiple PSMs from one PIM. PIMs are entered using standard UML diagrams. This tool supports code generation only for the selected languages, such as C, C++, and Java. The core support of this tool is the generation of code implementations from structural semantics as well as all the behavioral semantics that can be specified by UML diagrams. Source codes are generated from model artifacts based on generation rules and predefined parameters for each model metaclass. This tool provides model-based testing, offering the ability to specify and run tests based on the specifications in the model, as well as the ability to pinpoint defects from the test results by visualizing points of failure within the model. StateCAD by Xilinx [2] is a commercial graphical entry tool for digital design that allows ideas to be expressed in a natural manner. Xilinx achieves this by making use of their own graphical notation to represent state diagrams as bubble diagrams. StateCAD automatically generates simulatable and synthesizable HDL (VHDL and Verilog) code directly from these state diagrams. It also provides a mechanism to discover syntax errors, bugs, and incomplete portions of state diagrams early in the design cycle, prior to simulation. Once a design is completed, it may be verified, in StateCAD, to make sure it functions as intended. It mainly supports flat state diagrams. Concurrency in the design is supported by having two or more state machines that are interdependent and communicating between each

1360


other, which might become very problematic should one want to add a large number of states. This tool does not support hierarchy (nesting of the states). A significant body of research under the MIC [22] framework targets the support of embedded system design using MDE-related techniques [23], [24]. This work is based on the underlying formalism of Graph Grammars with tool support from the Generic Modeling Environment (GME) [25] and the associated Graph Rewriting and Transformation (GReAT) language [26]. Their approaches to embedded systems design predominantly focus on the use of Domain Specific Languages [25] or a general infrastructure especially suitable for self-adaptive systems [27]. In contrast, the work presented here targets the specific problem of mapping UML state machines to VHDL, also using MDE techniques. From a theoretical perspective, the approach in this paper is similar to the GReAT/GME work; both approaches use the concepts of modeling and transformations to provide the end result tooling. A key difference between the two approaches surrounds the manner of implementing those models and transformations. The GReAT/GME tools are based on the concept of Graph Grammars and specifications require a model and transformation interpreter/engine in order to execute, with a form of C++ code generation for performance improvements. The approach presented here takes a more pragmatic approach and directly implements both the models and transformations in the Java programming language using various programming patterns and, where essential, a very minimal supporting library (see [28]). As such, the approach this paper takes to support model and transformation execution is akin to a compiler. In relation to the specific case study of embedded system support presented here, the embedded system tools of GReAT/GME do not target VHDL. The conceptual models, transformers, and VHDL generators of the case study could be used to build a similar embedded systems support framework using other MDE tools such as GReAT/GME. In conclusion, there are several existing commercial tools that can generate VHDL from state diagrams [2], [20]. Moreover, it appears that it is preferable in their cases to use their own graphical notation rather than generate VHDL from UML state diagram specifications. Research efforts attempt to address this issue [7], [8], [9], [15]. Nevertheless, few involve an MDD methodology, thereby preventing designers from taking advantage of features of the MDD design paradigm, such as portability, reuse, and ease of maintenance. Furthermore, some of these tools have only targeted flat state-transition diagrams without covering hierarchy and concurrency [2], [7], [20]. In this paper, the authors aim to address each of these issues with the aid of an example of VHDL code generation from a UML specification of a hierarchical-based state machine.

3

OVERVIEW

OF THE

PROBLEM

An illustration of how MDD techniques may be used to solve the transformation problem is depicted in Fig. 1. The aim is to compile a UML-based specification of an embedded system into VHDL code, which can be subsequently synthesized for implementation onto an FPGA or ASIC.

VOL. 57,

NO. 10,

OCTOBER 2008

Fig. 1. Overview of the problem.

Ideally, the UML specification should consist of a mixture of Component and State diagrams. The Component diagrams define a configuration of predefined modules and their connectivity. State diagrams facilitate the specification of a state-based behavior for any component whose behavior can be thus expressed; some components will additionally require other mechanisms to define their nonstate-based behavior. However, that issue is out of scope of the example in this paper. The overall problem is broken down into a number of tasks to which different aspects of MDD technology are applied. These tasks are addressed using different MDD techniques as follows: State Diagram Editor. A State Diagram editor is essentially an editor for a Domain-Specific Graphical Language (DSL). Typical graphical language tool/editing support should be provided, enabling a pleasant user experience for entering State Diagram specifications. There are two options to providing a solution to this aspect: either by using an existing UML editing tool and employing a model interchange format (e.g., XMI) to import the specification or building a bespoke DSL. The second of these options has been used in the current solution, although it is planned to enable import from XMI in the future. State Diagram and VHDL Metamodels. The MDD approach to manipulating languages is to use an abstract representation (model) of the language commonly referred to as a metamodel. To specify the metamodel, a set of class diagrams must be developed that capture the abstract concepts of the language and the relationships between them. To subsequently provide tool support for a language model, these class diagrams are used as the basis to provide a repository for expressions or specifications in that language; these are often referred to as “instances” of the language model. The UML state machine metamodel is defined in the standard [3], but, as no standard VHDL metamodel existed, prior to this work, it had to be specified [29]. State Diagram to VHDL Transformation. Using the MDD approach, the primary compilation process is captured in a model transformation that maps concepts from the State Diagram metamodel onto concepts in the VHDL metamodel. Recently, a variety of model transformation techniques and tools have been developed, many based on the OMG’s adopted QVT specification [14]. The specification of the transformation is a complex task, requiring a significant knowledge and understanding of both the source and target model domains. Even with this level of understanding, defining the mapping between corresponding model elements is no trivial task. To overcome these issues, a transformation framework called


1361

TABLE 1 The BNF Syntax of a “Case Statement”

Fig. 2. Excerpt from the VHDL metamodel.

Simple Transformation (SiTra) was developed, as described in [28]. In this case of State Diagram to VHDL Transformation, a direct (Statemachine) model to (VHDL) text transform could be specified. However, the nontrivial nature of the transformation means that a model-to-model transform is more appropriate. VHDL Code. The final stage in the compilation process is the creation of text files that represent the VHDL version of the UML specification. The generated VHDL code is subsequently imported into a commercial synthesis tool for simulation/FPGA implementation. The MDD approach is to make use of a model-to-text transformer; this is commonly supported by the use of a template language, a technique that has also been adopted in this approach.

4

VHDL METAMODEL

VHDL is a text-based language and is defined using a grammar in Backus Naur Form (BNF) [19]. BNF restricts its use to languages that are purely text based. In order to define VHDL in the MDA context, its metamodel has to be defined. A VHDL metamodel has been developed which reflects a subset of VHDL suitable for hardware implementation, full details of which can be found in [29]. An excerpt from the metamodel is shown in Fig. 2. In VHDL, the design of a digital circuit (design entity) is separated into an entity declaration and one or more architecture bodies. An entity declaration models the interface of a circuit in terms of ports, while an architecture body models one possible implementation of the same circuit in terms of concurrent statements. Concurrent statements are used to define interconnected blocks and processes that jointly describe the overall behavior or structure of a design [19]. A process in VHDL represents a single independent sequential process. Sequential statements are used to define algorithms for the execution of a process. An example of how a commonly used sequential statement has been defined within the VHDL metamodel is given next. The first task is to determine the BNF syntax in the form of a template that defines the VHDL statement. This is then modeled as a UML class diagram, which in turn forms part of the VHDL metamodel. The “case statement” allows selection of statements to execute depending on the value of a selection expression. The case statement evaluates the branches in the order they

are written; the first branch that evaluates to true is executed. If none of the branches match, the default branch is executed. The BNF syntax of the “case statement” is given in Table 1. The “case statement” that has been modeled as a UML class diagram is depicted in Fig. 3. The VHDL syntactic category case_statement is mapped to a UML class CaseStatement with a property expression of a type Expression. There must be at least one case_statement_ alternative part in the case_statement. It is mapped to Alternative, which has at least one Choice property (i.e., 1.. multiplicity) and also has a property statement with an optional multiplicity ð Þ, representing sequential_statement syntactic category. As required by the definition, the Alternative class must have an ordered association ({ordered}) with the CaseStatement class since the “case statement” evaluates its branches in the order in which they are written. This example shows how one particular VHDL construct was defined within the VHDL metamodel. The same process was used for the other semantic constructs of the language.

5

MAPPING UML STATE DIAGRAMS

TO

VHDL

In this section, some of the useful techniques for designing FSMs in VHDL are presented. These form the basis for the informal definition of transformation rules that enable automated code generation of synthesizable VHDL code. This leads to the formal specification of the transformation

Fig. 3. UML model of the “case statement.”

1362

rules, with the section concluding with the way in which the actual implementation has been carried out.

5.1

Techniques for Designing Finite State Machines in VHDL Usually, the most important decision to make when designing a state machine to be implemented on an FPGA is what type of state encoding to employ. A poor choice of encoding technique could result in a state machine that uses too much logic or is too slow or both. A highly encoded state assignment will use fewer flip-flops for the state vector. However, additional logic will be required simply to encode and decode the state that can result in inefficient implementation in terms of speed and density. The one-hot encoding style allows the creation of state machine implementations that are more efficient for FPGA architectures [30]. One-hot encoding is usually the preferred method for large FPGA-based state machine implementations. In the one-hot encoding method, only 1 bit of the state vector is asserted for any given state and all other state bits are zero. Thus, if there are n states, then n state flip-flops are required. State decode is simplified since the state bits themselves can be used directly to indicate whether the machine is in a particular state. No additional logic is required. One-hot encoding is the default encoding scheme in many synthesis tools. Some synthesis tools perform better encoding than others, depending on the device architecture and the size of the decode logic. For the current example, the authors decided not to define the encoding style in the code, allowing an external VHDL synthesizer to select the encoding style that results in the lowest gate count. The traditional representation of an FSM incorporates Mealy and Moore machines, where the FSM is divided into the next state decode, state register, and output decode blocks [30]. In a Mealy machine, the output depends on the inputs and the present state. In a Moore machine, the output only depends on the present state. In VHDL, an FSM can be implemented using a one, two, or three-process technique. When an FSM is represented as one process, the sequential and combinational parts are combined together. This makes it of Moore machine type since the Mealy machine is possible only when output decode is separated from the state register block. One of the advantages of this style is that it enforces registered outputs that change on the clock edge of the FSM, making timing of the state machine predictable. Output signals can be assigned from anywhere in the process. This technique makes code easier to understand and trace because it flows sequentially rather than jumping from process to process. When an FSM is represented as two processes, it separates processes for combinational and sequential parts of the state machine. This technique gives a designer good control over the sequential and combinatorial parts and allows for a Mealy machine realization. Using this coding technique results in the most optimal synthesis of the FSM macro. An FSM represented as three processes produces similar results as the two-process technique. One-process FSM reduces a number of signals in the design and makes the maintenance easier. This is the most


VOL. 57,

NO. 10,

OCTOBER 2008

suitable technique for mapping UML state diagrams since it allows access to the next state and other signals from anywhere in the state machine. In VHDL, signals cannot be assigned from different processes since it was not designed to handle signals with multiple drivers. This technique also avoids the need for shared variables. Such shared variables should be avoided without some form of synchronization in synthesizable VHDL code since it can introduce nondeterminism. The state transition logic in the VHDL FSM is described using a case statement or the equivalent if-elsif-else statements. Usually, case statements are better suited for FSM coding since case choices are evaluated in parallel, while ifelsif-else comparisons have an inherent priority [31]. Parallel implementation is more efficient as it produces shorter delay paths. Also, representing FSM using case statements makes code more readable. The default, when others, choice is optional in a case statement; however, it has been used here to add behavior that recovers an FSM if it encounters an illegal state due to some external influence such as an alpha particle hit or a physical defect. To support this in terms of modeling constructs, an adaptation to the UML state diagram semantics could be made by introducing an “Error” pseudostate, which would indicate the state to enter if FSM does encounter an illegal state. In the current example, the authors intend to generate synchronous synthesizable VHDL specifications of the UML state diagrams. A standard UML state machine is asynchronous; therefore, the specification of synchronous state machines is enforced during the mapping to VHDL process. The key feature of synchronous design of a state machine is that state transitions and other changes can only occur on the active edge of a clock. In order to ensure that the circuit is 100 percent synchronous, the circuit reset logic should also be made synchronous. To achieve this, the reset should be checked after an if clk=’1’ and clk’event statement. The coding style of describing the reset is of an if-else priority style with the reset in the if condition and all other combinational logic in the else section. The primary objective of a reset is to force a state machine into a known state. The transitions leaving a given state in a state machine must be all inclusive and mutually exclusive [32]. As a rule, when designing an FSM, one should make sure that all possible input conditions for each state are correctly specified. In VHDL, this is easily achieved and can be guaranteed by using the if-elsif-else construct, which represents conditions of transitions in any given state. All inclusion will be ensured by having an else branch. Most synthesis tools can determine if the if-elsif-else conditions are mutually exclusive and will not create extra logic to build the priority tree.

5.2 Informal Transformation In order to map UML state diagrams to VHDL, the detailed semantics of a UML state machine [3] must be considered, as well as how to map them onto VHDL. The MODEASY transformation tool supports a large subset of all possible constructs in UML state machine. For a full account of the UML constructs supported by the transformation tool, refer


to Appendix A. Each of the supported state machine constructs are transformed to VHDL as follows: State Machine. A state machine in UML is used to describe the behavior of a part of a system. It is mapped to an architecture body and a synchronous reset edge sensitive process statement template in VHDL, which are common to the transformation of all state machines. Events in a VHDL state machine are synchronized by the clock. Region. A region is an orthogonal part of either a composite state or a state machine. It maps to an enumerated type declaration, containing the name of every state in the region. It can also contain a distinguished state final, if a state diagram includes the final state, signifying that the enclosing region is completed. A region is also mapped to a declaration of a signal, which is used for state assignments. Each region in the state machine must have an initial pseudostate. A thread of execution in each region is mapped to a case statement specifying all of the states in the thread. Transitions. State transitions are represented as state signal assignments. Transition indicates a movement from one state to another. Transitions can be guarded by Boolean expressions that are evaluated when an event instance (clock) is dispatched by the state machine. If the guard is true at that time, the transition is enabled; otherwise, it is disabled. A trigger, in this context, does not fire a transition since all events are synchronized, but acts more like a guard. A transition may have an effect associated with it which specifies behavior to be performed when the transition is taken. Triggers, Guards and Effects. A trigger is mapped to an if condition denoting the occurrence of a signal event. The guards of transitions emanating from the state are mapped to an if-elsif-else statement. This ensures that if several guard conditions are true, then only one transition will fire. The priority of the conflicting transitions will be based on the relative position of their guard conditions in the if-elsif-else statement. A state machine will remain in its current state when no transition from the state is enabled; this is because of the synchronous nature of the state machine where all state signals are registered and hold the last assigned values. Transitions without guards are treated as if their guards are always true. Activities. An optional behavior can be associated with a state to be performed whenever the state is entered (entryactivity), exited (exit-activity), or while the state machine is in a particular state (do-activity). Activities are mapped to signal or variable assignments in VHDL. In accordance with the run-to-completion semantics of event processing in UML [3], each assignment must be completed during the next clock cycle to comply with the imposed timing constraints of synchronous state-based behavior. This ensures that an activity has exclusive access to any shared resources at the time of assignment and that a resource remains consistent for any activity associated with a state. Composite States. States can be nested within composite states. The outer enclosing state is called a superstate. The inner states are called substates. Nested state diagrams are represented as nested case statements. Transitions may be made to and from either a superstate or a substate. An

1363

incoming transition that terminates on the outside edge of the composite state represents a transition to the default state in its region. Orthogonal States. States can be broken into several orthogonal state diagrams that run concurrently. Concurrent threads of execution are mapped to several case statements nested inside the case choice of the parent state corresponding to the enclosing orthogonal state. An object from this state model must be in exactly one state from each of the orthogonal regions for as long as the enclosing superstate is active. Conflicting Transitions in a Hierarchical State Machine. The priority of the conflicting transitions in a hierarchical state machine, where more than one state can be active, is based on the relative position in the state hierarchy. By definition, a transition originating from a substate has higher priority than a conflicting transition originating from any of its containing states. In a situation when a transition which has a trigger emanating from a composite state is specified, this principle can be adhered to by making the state machine return to the containing state when a substate transition is taken. Pseudostates. A pseudostate is used to combine and direct state transitions. The following types of pseudostate are supported by the transformation tool: An initial pseudostate represents a source for a single transition to the default state in a region. All initial states are assigned when the state machine is reset. A deep history pseudostate implies that the active state configuration for all levels of the state configuration underneath the composite state is saved when the composite state is exited and restored when the composite state is reentered. The current VHDL FSM representation as a number of nested case statements supports the principle of deep history since state signals are registered and hold the last values. A shallow history pseudostate implies that the active state configuration for only the first level of the state configuration underneath the composite state is saved when the composite state is exited and restored when the composite state is reentered. For the shallow history state, the substate signals must be set to defaults on entering the composite state containing the shallow history state. The fork pseudostate serves to split an incoming transition into two or more transitions terminating on orthogonal target states. This is mapped to state signal assignments, corresponding to entering target states in each region of the orthogonal state. Conversely, the join pseudostate serves to merge several transitions emanating from source states in different orthogonal regions. They are mapped to state signal assignments corresponding to entering a state outside the orthogonal state. The junction pseudostate represents a static conditional branch. It is used to chain together multiple transitions to construct compound transition paths between states. The guards of the transitions emanating from a common junction point are evaluated before transition effects are executed and before the compound transition is taken. A junction is mapped to a nested if-elsif-else statement.

1364


VOL. 57,

NO. 10,

OCTOBER 2008

TABLE 2 Specification of Region2TypeDeclaration Rule

TABLE 3 Specification of Region2SignalDeclaration Rule

The choice pseudostate represents a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step. The choice mapping is represented as a nested if-elsif-else statement. Changes to the semantics of UML specified in the standard [3] have been made necessary for the hardware implementation of a purely synchronous state machine. These changes do not make the mapping specific to VHDL. Ideally, a UML profile would be created, which could be used to ensure that the semantic changes are adhered to. However, due to the small number of semantic changes, they are more easily expressed here via the following list:

draw from a formal foundation of relations and the Object Constraint Language (OCL) [4]. The following example shows how rules have been specified for the UML concept of a region. A region is an orthogonal part of either a composite state or a state machine. A region concept in a UML state diagram maps to an enumerated type declaration in VHDL, containing the name of every state in the region. A region is also mapped to a declaration of a signal, which is used for state assignments. In order to carry out the transformation of the region concept, two rules are needed: The first specifies how a region from the UML state machine diagram is transformed into a type declaration in VHDL, as shown in Table 2. The second specifies how a region is transformed into a VHDL signal declaration, as shown in Table 3. The transformation rules define a unidirectional relation between the source and the target transformation objects, imposing restrictions on the members of this relation. The definition of the Region2TypeDeclaration transformation rule shown in Table 2 contains the source and target language references (reg of type Region and td of type TypeDeclaration correspondingly). The source language condition [reg.subvertex->kindOf(State)->size>0] stipulates that the region must contain at least one state for the transformation to be carried out. A type declaration in VHDL is comprised of an identifier name and its corresponding type definition. The transformation creates a target object derived from these attributes. The property name of the TypeDeclaration object is set simply by retrieving its value from Region’s name attribute, using the variable n. A type definition can be either one of the VHDL predefined types from the IEEE library packages [19] or as an enumerated type whose ancestor has a predefined type. The property typeDefinition of the TypeDeclaration object is set by invoking an additional mapping rule Region2EnumerationDefinition. Fig. 4 shows how the Region2TypeDeclaration rule relates the UML concept of a region to that of a VHDL type declaration from their respective metamodels. The Region2SignalDeclaration rule shown in Table 3 specifies how a region from a UML state machine diagram is transformed into a signal declaration in VHDL. The definition of this transformation rule contains the source and target language reference (reg of type Region and sd of type SignalDeclaration). Once again, the use of this rule is subject to the source language condition [reg.subvertex->kindOf(State)->size>0]. The property name of the SignalDeclaration target object is set, using variable n, by retrieving its value from the

Each region in the state machine must have a single initial pseudostate. 2. All events in a state machine are synchronized by the clock. 3. Transitions in the state machine are triggered by the active edge of a clock. 4. A trigger does not fire a transition, since all events are synchronized, but acts more like a guard. 5. All state activities must be completed during one clock cycle in order for it to be in accordance with the semantics of event processing in UML, which is based on the run-to-completion assumption. 6. A special guard construct “ELSE” supports the “else” transition; however, such a transition must not have a trigger. 7. A state machine will remain in its current state when no transition from the state is enabled. This is because of the synchronous nature of the state machine, where all state signals are registered and hold the last assigned values. 8. The priority of the conflicting transitions originating from the same state is based on the relative position of their guard conditions in the “if statement.” The MARTE profile [33] provides a variant of UML designed specifically for modeling real-time and embedded systems. The state machine part of UML is used directly (as is) within MARTE and thus the mapping to VHDL presented here could be employed in that context. Consideration would need to be given to the extended semantics of time modeling that is present in MARTE; however, this is beyond the scope of this paper. 1.

5.3 Formal Transformation Rules In the current approach, transformation rules are defined using a QVT-like language [34], the semantics of which


Fig. 4. UML region and VHDL type declaration metamodel.

Region’s name attribute and concatenating it with string value “State_.” The signal’s type property is set by invoking the Region2TypeDeclaration rule against the same Region. The same process for mapping source elements to the corresponding target elements was employed for the other transformation rules used in the project.

5.4 Implementation This section describes the MODEASY transformation tool developed as a proposed solution to the problem illustrated in Fig. 1. The MODEASY tool is built on the Eclipse universal tool platform [35], which was purposely designed and built to meet many special requirements, one of which is to support the construction of tools for GUI-based application development. It provides a Graphical Editing Framework (GEF) [36] for creating feature-rich visual editors. The MODEASY state diagram editor is based on GEF and makes use of a common DSL editor that has a generic model of diagrams. Elements in the diagram model are mapped to different symbols in the visual representation. The editor makes available an instance of the generic diagram model that represents the expression drawn. Fig. 5 depicts the state diagram editor within the MODEASY tool.

Fig. 5. Screen shot of the MODEASY tool.

1365

The MODEASY tool makes use of a model transformation technique [37] to translate this instance of the diagram model into an instance of a UML model, conforming to the UML state diagram metamodel. Using the MDD approach, the primary transformation process is captured in a model transformation that maps concepts from the UML state diagram metamodel onto concepts in the VHDL metamodel. The transformation framework used is based on the model transformation approach, described in [28], which uses a small code library as the basis to support the development of a model transformation. This approach makes use of the following two concepts: The Transformer, which is the primary transformation object. This contains a collection of rules and manages the process of transforming source model objects into target model objects. 2. The Rule, which deals with specific detail of how to map an object from a source model into an object of the target model. It also determines if the rule should be applied to a specific source object. This approach includes mechanisms for rule reuse, subtyping of rules, and alternative transformation algorithms and is not constrained by a specific model repository implementation. The final stage in the compilation process is the generation of synthesizable VHDL code that represents the state diagram model. The MDD technique for creating text from models is to make use of model-to-text transformation mechanism. The predominant approach is to use template languages based on OCL expression language [4]. The MODEASY tool makes use of such an OCL-based template language [38] built on top of a custom OCL library [39]. An example specification of the text generation template for VHDL “case statement” is illustrated in Table 4. 1.

1366


TABLE 4 TypeDeclaration Code Generation Template

The text generation template can contain some basic instructions, like loops (foreach), conditions (if), and calls (generate), to other templates to delegate part of the text generation. The VHDL reserved words are depicted here in bold type. This technique proved to be a very simple and effective mechanism for mapping the instances of VHDL metamodel into text files; however, two significant drawbacks relating to text formatting were encountered. First, a compromise must be reached between what would be considered an acceptable layout of a template specification and that of the generated VHDL code. A neatly laid out specification introduces excess white space into the output code, whereas enabling nicely laid out output code requires the template specification to be written in such a way that it becomes virtually unreadable. Second, no practical mechanism for producing nested indenting in the output currently exists within the template language used. Solving these issues would require an additional module to be incorporated into the compilation process, which would ideally be capable of formatting the output code, according to specifiable user preferences. However, these issues are out of scope for the purpose of the example in this paper.

6

CASE STUDY EXAMPLE

This section shows an example of automatic (VHDL) code generation from a UML state diagram model. The system under investigation is the Early Warning System (EWS) adapted from [40]. This section first gives a description of the system and then illustrates how different parts of the EWS specification are transformed from one language (UML state diagrams) into the other (VHDL). The example demonstrates the MDD approach to this transformation, indicating how different transformation rules and model-to-text templates are used in the context of this example system.

VOL. 57,

NO. 10,

OCTOBER 2008

The system description is given as follows: The EWS receives a signal from an external sensor. When the sensor is connected, the EWS processes the signal and checks if the resulting value is within a specified range. If the value is out of range, the system issues a warning message on the operator display by posting an alarm. If the operator does not respond to this warning within a given time interval, the system prints a fault message on a printing facility and stops monitoring the signal. The range limits are set by the operator. The system becomes ready to start monitoring the signal only after the range limits are set. The limits can be redefined after an out-of-range situation has been detected or after the operator has deliberately stopped the monitoring. The UML state diagram of the EWS model is shown in Fig. 6. The main part of the EWS controller behavior is detailed in state St_On. It is an orthogonal composite state with two concurrent regions, Monitoring and Processing. When state St_On is active, the system is in two states simultaneously, each from a different region. Events setup, execute, reset, resume, and power represent commands that can be issued by the operator. When the sensor is connected, the signal connect is set high and the signal value received is compared with the range limit set by the operator. If the resulting value is out of range (i.e., value > limit), the system sets the alarm signal high and, if the operator does not respond to this warning (i.e., time_out is set high), the system asserts the signal print and stops monitoring the signal. The transformation of the specification is described hierarchically, starting with the specification of the EWS component written by the designer as a UML Component Diagram, then by opening up the component and delving into the state machine specification, then subsequently into its substates, down to the low-level detail defined as effects on the transitions and activities on states. The top-level component specification, detailing the input and output ports, is illustrated in Fig. 7. The MDD transformation rules include a rule that maps Components onto a VHDL Entity declaration. This rule is specified and implemented as shown in Table 5. The MODEASY tool applies the rule implementation to the internal representation of the EWS Component (an instance of the UML metamodel class defining the concept of a Component). The result of this application gives an internal representation of a VHDL Entity Declaration with the appropriate name and port definitions. This Entity Declaration object is converted into VHDL text, suitable for input to the VHDL compiler, using a model-to-text transformation template resulting in VHDL code, as indicated in Table 6. The behavior of the EWS component is specified using a UML state machine, as described earlier. This state machine is mapped to a VHDL architecture body. In a manner similar to the Component to Entity mapping, there is a rule specification and its implementation that maps a state machine object into a VHDL architecture body object. The VHDL code for the architecture body is generated using the model-to-text template mechanism and the OCL processor from the template shown in Table 7. The VHDL keywords in the template are emphasized in bold type.


1367

Fig. 6. UML state diagram of the Early Warning System (EWS) model.

The statements that make up the behavior defined by the architecture body come from mapping the details of the state machine into VHDL statements. The statements fit into the VHDL code pattern illustrated in Table 8, which wraps the state machine behavior into a standard VHDL pattern for synchronous behavior that can be reset. In this code pattern, the sigAsses are VHDL signal assignments generated by transformation rules to reset the behavior to the initial state indicated by the state machine. The cases are VHDL case statements that model the behavior of the UML state machine. A thread of execution in each region of the UML state machine is mapped to a case statement that specifies all of the states in that thread. This mapping is specified by the Region2CaseStatement rule, as shown in Table 9. It can be seen here that the rule is only executed in the case when at least one state exists. The case statement is formed from a case expression defined by the signal declaration for the region in which it exists, together with the choice of alternative states and the default “others” state. These attributes are again obtained from the implementation of the rules declared in the “where” clause. The VHDL case statement object is mapped to VHDL text using the model-to-text template previously shown in

Fig. 7. Component specification of EWS.

Table 4. Thus, for the top-level states of the UML state machine, the transformation process generated the VHDL code is indicated in Table 10. The first two elides expand to additional signal assignments that indicate which of the substates should be entered when entering top-level state St_On. The final elide expands to further VHDL case statements that provide the behavior of those substates. The full result of the automatic VHDL code generation for this example, using the transformation techniques outlined in this paper, is shown in Appendix B. This demonstrates the realization of a hierarchal structure TABLE 5 Component2EntityDeclaration Rule and Implementation

1368


TABLE 6 VHDL Entity Declaration for the EWS Component

VOL. 57,

NO. 10,

OCTOBER 2008

TABLE 9 Region2CaseStatement Rule

TABLE 10 VHDL Code Pattern for the EWS Top-Level States

TABLE 7 Architecture Body Model-to-Text Template

TABLE 8 VHDL Process Code Pattern

through nested implementations of the Region2CaseStatement transformation. A full list of all model-to-model transformation rules and associated model-to-text templates can be found in [29].

7

CONCLUSION

The principal aims of this paper have been to explore the possibilities of MDD within the embedded systems domain, together with the presentation of proposals on how these techniques could be used to provide automated generation of synthesizable VHDL code from UML notations. Having compared a number of both existing commercial tools and current research efforts, significant shortcomings in some approaches have been identified. Specifically, development tools that only target a notion of purely “flat” state-transition diagrams, without covering hierarchy and

concurrency [2], [7], [20], present a limitation to the way in which many complex designs may be defined. To address this issue, the authors of this paper have proposed a mechanism that supports hierarchical concepts such as Composite and Orthogonal states. A framework for deriving VHDL specifications from UML state diagrams has been developed and a set of rules has been defined which enable automated generation of synthesizable VHDL code from UML notations using MDD techniques. To facilitate this, metamodels of the two languages have been used and a transformation definition has been created which maps the concepts from the state diagram UML metamodel onto concepts in the VHDL metamodel. This has been achieved by implementing two model transformations, one from the model of a diagram into a model of state diagrams and another that maps the state diagram model onto concepts in the VHDL language. A model-to-text transformation was subsequently implemented to generate synthesizable VHDL code from the VHDL model. The generated VHDL code was successfully loaded directly into commercial simulation and synthesis tools [41], [42], without the need for human intervention in the content of the code. A possible limitation that the reader may consider for the proposed techniques relates to the lack of a direct mechanism for ascertaining the validity of the transformations presented, which may then, of course, invalidate the VHDL generated. However, although this is a significant issue, the probability of an error occurring is analogous to


an error within the design of a compiler and the work required to alleviate this error is comparable. Therefore, this consideration should not be considered a disadvantage of the MDD approach to the design of embedded systems specifically. The authors have shown a method for producing synthesizable VHDL code from UML state machine diagrams. The two languages are significantly different in structure for the issue to be nontrivial and, consequently, they feel that the technique of MDD has proven to be an appropriate mechanism for specifying the mapping from one to the other. Adopting the MDD approach contributes a significant improvement to the hardware design process in terms of productivity, portability, interoperability, and maintenance. Automating the code generation becomes easier through a better separation of concerns.

1369

TABLE 11 Supported UML State Machine Constructs

APPENDIX A Table 11 indicates which UML state machine constructs are supported by the MODEASY transformation tool and those which currently are not.

APPENDIX B ARCHITECTURE behavioral OF ews IS TYPE EWS IS (st_OFf, st_on); SIGNAL State_EWS: EWS; TYPE Monitoring IS (Idle,SettingUp, St_Working); SIGNAL State_Monitoring: Monitoring; TYPE Working IS (Comparing, AlarmOn, Final); SIGNAL State_Working: Working; TYPE Processing IS (Disconnected, St_Connected); SIGNAL State_Processing: Processing; TYPE Connected IS (Idle, Operating); SIGNAL State_Connected: Connected; BEGIN PROCESS(clk) VARIABLE value: std_logic_vector (0 TO 1); VARIABLE scope: std_logic_vector (0 TO 1); BEGIN IF clk=’1’ AND clk’event THEN IF reset=’1’ THEN State_EWS