1 Introduction

Nowadays, an increasing number of embedded systems are being delivered to the final customers with Field-Programmable Gate Array (FPGA) components interconnected with traditional IC components (e.g., processors and memory) as the system hardware platform. Programmability, flexibility and better performance are some of the reasons to justify the use of a FPGA device to perform some tasks of embedded systems [19, 25].

In such modern FPGA-based embedded systems, the hardware/software co-design and partitioning of system tasks, as well as the increasing number of services demanded from them, lead to an increase in design complexity. New approaches are required in order to cope with such a complexity. An old but still valid idea is the increase of the abstraction level used during design [11, 18]. Both academia and industry are looking for new approaches that use high-level specifications such as, for instance, Unified Modeling Language (UML) models annotated with stereotypes of the profile for Modeling and Analysis of Real-Time and Embedded Systems (MARTE). Model-Driven Engineering (MDE) [12, 18, 32] makes intensive use of models, in order to manage complexity and also other design constraints. Such an approach advocates that engineers need lesser focus on technological details, and thus, system design (as a whole) may profit from using the information contained in the high-level models to generate the executable artifacts of embedded and real-time systems.

Since late 1990’s, one can find approaches, e.g., [16], that are able to generate VHDL descriptions from UML models. In [6, 27], an UML model (especially its class diagram) is used as source of information to generate a VHDL description that comprises only the system structure, i.e., its components and their connections, not its behavior. System behavior is commonly generated from state diagrams as in [34]. The main drawback of such approaches is that it is common to find VHDL statements within the UML model, decreasing its abstraction level, as well as its usability for generating code for other languages. Furthermore, state diagrams are not frequently used by software engineers, and hence, co-design of embedded system components may be hindered, increasing design time. Furthermore, most of the proposed approaches, e.g., [3, 4, 28], do not use the main principles of Object-Oriented (OO) paradigm, e.g., inheritance and composition/aggregation relationships in class diagram to define system structure. In addition, such approaches do not use other behavioral diagrams from UML, for instance, sequence diagrams to define system behavior. The mentioned high-level features (e.g. inheritance and multiple diagrams to specify system behavior) are some of the UML strengths [26] and should not be ignored within UML-based approaches.

Aspect-oriented Model-Driven Engineering for Real-Time systems (AMoDE-RT) [32] is a MDE approach that proposes the intensive use of UML/MARTE models, from which a system implementation can be automatically generated, including software/hardware implementation of embedded system components. In [20], AMoDE-RT has been extended to support the generation of VHDL descriptions, including both system structure and behavior. System behavior is specified in a platform-independent fashion via sequence diagrams rather than state diagrams, since the former is easily understood by both hardware and software engineering teams. However, the approach proposed in [20] has some limitations: (i) it supports only few classes/objects per system; (ii) only 1-to-1 associations are supported; (iii) the generated behavior does not differentiate synchronous and asynchronous methodFootnote 1 calls used within sequence diagrams; (iv) engineers need to include unnecessary details in the UML model in order to generate the VHDL description as complete as possible; (v) depending on the amount of such details, generated VHDL descriptions need some minor manual modifications before they can be synthesized by a synthesis tool. This work improves [20] and proposes a new set of mapping rules for the UML-to-VHDL transformation, including the support of some OO constructions which have not been initially supported, as well as the support for sequence diagrams full semantics.

Another issue that affects the design of embedded and real-time systems is the effective handling of non-functional requirements, e.g., deadlines, energy consumption, reduced footprint, communication latency, etc. In the embedded systems domain, non-functional requirements introduce crosscutting concerns in system design and implementation. Such concerns are not properly handled by traditional approaches (e.g., object-orientated, component-based approaches) due to the functional decomposition [7, 13] enforced by such approaches. This decomposition schema leads to modularization problems of crosscutting concerns, since their handling cannot be encapsulated within single modular units, which, in turn, results in scattered and tangled handling.

Aspect-Oriented Programming [13] addresses crosscutting concerns modularization issues in software components by proposing special constructs called aspects. Aspects encapsulate the handling of crosscutting concerns by defining adaptations (also known as advices in AOP terminology). Engineers indicate which elements of the system base code are affected by aspects adaptations. For that, they define pointcuts describing elements selection expressions to indicate join points on which adaptations are applied. In this sense, VHDL descriptions are somehow similar to a software source code files: they describe components structure and behavior using a language based on functional decomposition. Therefore, the handling of crosscutting concerns is found in many distinct elements, and hence, VHDL descriptions are subject to the same modularization issues related to crosscutting non-functional requirements [8, 17, 22].

AMoDE-RT supports aspect-oriented concepts in UML/MARTE model by means of DERAF aspects [10, 33]. Therefore, other contribution of this work is the VHDL implementation of some DERAF aspects. Aspects adaptations have been specified as mapping rules scripts that generate VHDL constructs to handle crosscutting concerns. By using the proposed approach, it is possible to generate a fully functional and synthesizable VHDL description from a more abstract UML model—there is no need for manual modifications on the generated descriptions. Engineers can generate both hardware and software source code from the same UML model [32], facilitating hardware/software co-design. This paper extends [31] by providing a detailed discussion on the UML-to-VHDL mapping rules for the high-level object- and aspect-oriented features as proposed in AMoDE-RT.

This work has been validated through some case studies that represent real systems, namely, the design of a digital watch, a line-following robot, and a valve control system. These systems have been modeled following AMoDE-RT approach and implemented in a FPGA development board. Results demonstrate the feasibility of the proposed approach. A better utilization of FPGA resources has been obtained, which, on the other hand, impacted on system performance. In comparison with the results presented in [20], a greater amount of source code lines was generated from the UML model. This may indicate a decrease in the effort for creating the embedded system implementation, especially when designing larger systems. Moreover, by using AMoDE-RT approach, it is possible not only to deal with non-functional requirements earlier in the design cycle, but also to obtain automatically a fully synthesizable VHDL descriptionFootnote 2, as demonstrated in the presented case studies.

The rest of this text is organized as follows: Sect. 2 discusses related works; Sect. 3 describes how AMoDE-RT generates VHDL descriptions from aspect-oriented UML/MARTE models; Sect. 4 presents the case studies and analyses the obtained results. Finally, Sect. 5 draws some conclusions and discusses directions for future works.

2 Related works

Generating VHDL descriptions from high-level models has been proposed in various works [5, 6, 20, 24, 28]. For instance, COmponent LAnguage (COLA) tool allows the system high-level specification as well as the generation of a VHDL description [28]. The generated VHDL description comprises the hardware structure and behavior, which is extracted from state machine diagrams. However, COLA has its own formal modeling semantics, which is not a standard, hindering its adoption in comparison with UML-based approaches.

On the other hand, GASPARD is a tool that generates VHDL descriptions from UML/MARTE models [6, 24]. GASPARD uses concepts from logical view of MARTE Hardware Resource Modeling (HRM) package. Such a tool focuses on modularization and components mapping. It is necessary to define templates for the static elements of UML, in order to generate the system VHDL description. As a consequence, GASPARD generates entity and components mapping but it does not support the code generation for system behavior.

In [5], the proposed approach generates VHDL descriptions intended for system behavior validation. Sequence diagrams are used to specify system interactions, from which a VHDL description is generated. Design constraints are specified in sequence diagram as MARTE stereotypes, defining system non-functional properties that are subject to validation. However, that approach generates VHDL files only for system validation; it does not generate VHDL description for the system functional requirements.

Recently, an increasing number of research works propose the use of Aspect-Oriented Programming (AOP) in hardware design. The use of AOP in conjunct with VHDL language is analyzed in [8]. This work identifies some elements in VHDL which may be subject to aspects adaptations. As result, those authors indicate process and variable/signal assignments as possible join points in VHDL. These places are suitable for code injection, especially before, after and around each join point [8].

Aspect Described Hardware-description-language (ADH) is described in [23]. ADH is an aspect-oriented language for hardware descriptions based on AspectJ language [13]. A compiler has been developed to translate ADH descriptions into VHDL descriptions. However, according to [23], the compiler generates “synthesizable” VHDL code but it cannot be directly used on FPGA devices due to missing library classes, as well as other open issues and bugs of the compiler.

AspectVHDL language is an extension to VHDL syntax that includes AOP concepts and constructs [17]. Such a language allows the definition of join points for procedures, functions, data type definitions, entity architecture, and processes sensitivity list. However, in order to allow the definition of join points and hence to use AspectVHDL, the system description must be structured in terms of functions and procedures.

In order to design embedded systems using the synthesizable subset of SystemC, Muck et al. [22] propose an approach that combined AOP and OO programming. That work focuses on increasing components reuse by means of decreasing components coupling. For that, their approach uses meta-programming, OO concepts such as inheritance and interfaces, as well as design patterns. According to [22], the obtained results indicate that, although using higher abstraction levels for system design, system performance is not impacted negatively in spite of a small increase in FPGA area usage.

In comparison with the mentioned related work, this work presents the following differences: (i) AMoDE-RT is based on MDE techniques and high-level UML/MARTE models allowing the engineers specify the system functional and non-functional requirements in a platform independent way using a standard modeling language; (ii) AMoDE-RT is supported by a flexible code generation tool such as GenERTiCA, opening room for exploring the use of distinct target platforms for implementing the embedded real-time system, since engineers can easily change the mapping rules script. Moreover, this work enhances the VHDL generation approach proposed in [20] by means of providing a proper support for high-level constructs available in UML. System behavior is completely specified using sequence diagrams, including MARTE stereotypes for specifying of non-functional requirements. These diagrams are used to generate the VHDL components behavior. It is worth mentioning that an important contribution of this work is to address the handling of crosscutting non-functional requirements in a high-level and independent of platform way throughout the use of a platform-independent aspects framework. This work proposes and demonstrates one possible VHDL implementation of these high-level aspects. Thus, it is possible to generate a complete VHDL description from UML/MARTE high-level specification. Such a description is synthesizable and fully functional, according to system requirements specified in the UML/MARTE model.

3 From aspect-oriented UML models to VHDL descriptions

3.1 Overview of AMoDE-RT

Aspect-oriented Model-Driven Engineering for Real-Time systems (AMoDE-RT) [32, 33] is an UML-based MDE approach that promotes the use of Platform Independent Models (PIM) as the main artifacts to specify embedded real-time system requirements, including system structure, behavior, constraints and non-functional properties. One of its main contributions is the separation of concerns for handling functional and non-functional requirements. For that, AMoDE-RT supports concepts of the Aspect-Oriented Software Development (AOSD) within UML/MARTE models by means of the Distributed Embedded Real-time Aspect Framework (DERAF) [10, 33].

Furthermore, in AMoDE-RT, system implementation is obtained automatically from UML/MARTE models by means of model transformations [32]. For that, AMoDE-RT proposes the use of an intermediate platform independent model called Distributed Embedded Real-Time Compact Specification (DERCS) [30, 33]. DERCS model of an embedded real-time system represents functional requirements in terms of concepts of object-oriented paradigm, whereas non-functional requirements are represented using concepts of aspect-oriented paradigm. Generation of Embedded Real-Time Code based on Aspects (GenERTiCA) tool [29] supports the UML-to-DERCS transformation as well as the automatic generation of source code from the DERCS model. GenERTiCA implements a script-based code generation approach that uses a set of scripts to map model elements into constructs, services, and/or APIs provided by a given target platform. Engineers may specify mapping rules scripts for distinct target platforms, including both software and hardware (i.e., using Hardware Description Languages). Therefore, this work proposes a new set of mapping rules for VHDL implemented as the code generation scripts, enhancing our previous approach [20]. Figure 1 shows the code generation approach implemented in GenERTiCA tool [29].

Fig. 1
figure 1

GenERTiCA code generation process

Full size image

In addition, it is important to highlight that GenERTiCA does not only generate source code but also performs aspects weaving. In other words, GenERTiCA weaves aspects adaptations into the generated code, allowing the use of aspect-oriented concepts, even though the target implementation language does not support such concepts. For that, GenERTiCA uses the information provided by DERAF aspects, which have been specified in a platform independent way within the UML/MARTE model. Aspects adaptations are implemented as mapping rules scripts, enabling their portability for different platforms or/and applications. An adaptation may occur in two ways: in model level or in code level. At model level, adaptations may include or change elements in DERCS model [29] generated from UML/MARTE specification. These modifications are accessible to mapping rules during code generation step. On the other hand, at code level, modifications affect directly the generated code without changing the input model. Thus, a relevant contribution of this work is the VHDL implementation of some DERAF aspects, via mapping rules scripts, that was not supported in [20]. Details on AMoDE-RT, DERAF and GenERTiCA can be found in [10, 29, 32, 33].

3.2 Functional requirements

A set of mapping rules to generate VHDL code from UML/MARTE models has already been proposed in a previous work [20]. However, as mentioned in [15], our previous approach [20] has some limitations, especially when one considers the potential increase in the specification abstraction level by using object-oriented features, e.g., encapsulation and inheritance. Besides improving the management of design complexity, by using such abstractions, engineers may improve artifactsFootnote 3 modularity, and hence, facilitate their reuse.

Table 1 Mapping concepts from UML/MARTE to VHDL
Full size table

In order to address the already mentioned issues, a new set of mapping rules have been created, as depicted in Table 1. First column shows the UML meta-model elements; second column depicts the VHDL elements mapping, as proposed in [20]; and, third column shows the modifications proposed in this work for UML-to-VHDL mapping. As one can note, classes are mapped into entities and their related architectures. In addition to the support for encapsulation and inheritance, an important contribution of these new mapping rules is the support for synchronous and asynchronous method calls.

Furthermore, it is worth mentioning that this work supports UML structural elements (e.g., classes and objects) and behavioral elements (e.g., interactions and actions). Some stereotypes from Hardware Resource Modeling (HRM) and Software Resource Modeling (SRM) of MARTE profile are also covered, e.g., Table 1 shows that \(\texttt {<<TimedEvent>>}\) stereotype indicates that the annotated message is mapped to a VHDL process that is activated periodically according to its timing constraint. It is worth mentioning that it is possible to extend the mapping rules to add different packages and elements. AMoDE-RT and GenERTiCA are flexible approaches, and hence, they can support other mapping rules describing different implementation strategies for the model elements or DERAF aspects.

In order to illustrate the translation process, the remainder of this section discusses some key UML-to-VHDL mappings representing the system functional requirements. For that the digital watch case study is presented. Figure 2 shows the class diagram of the digital watch. In summary, this system is composed of a timer (WatchTimer class), four seven-segment displays (Display and Number classes), and a controller component (SystemControl class). This digital watch shows time passing in terms of minutes and seconds. Each seven-segment display shows one digit of the given number of minutes or seconds and is controlled via an activation port (turn on/off each digit). In addition, Segment class represents the status (on/off) of each segment of the seven-segment display. The watch control system assigns the current number of minutes/seconds (generated by the timer) to the related digit display, which, in turn, enables the correct segments according to this number. Thereafter, the watch control system activates this digit turning off the other ones.Footnote 4 However, as this system has a high refresh rate for the seven-segment displays, turning on/off each display individually is imperceptible to human eyes.

Fig. 2
figure 2

Watch class diagram

Full size image

As mentioned, this work provides the support for object-oriented features such as generalization/inheritance and association between classes. Generalization relationship is translated to VHDL in two ways. The first one considers concrete super classes. In this case, a component representing the super class is instantiated within all child classes, i.e., the super class is mapped to a separated entity which owns ports, signals and processes like a “regular” class. On the other hand, the second mapping is related to abstract super classes. In this case, all child classes incorporate the elements from the super class, i.e., all attributes and methods of the super class are included into the child class. Therefore, the UML-to-VHDL mapping generates an entity for each child class that incorporate ports, signals and processes from the super class. In a similar way, when a super class has abstract methods, these methods are implemented in all child classes and removed from the super class.

Listing 1 shows an excerpt of the mapping rule that checks whether a class has an abstract super class, i.e. it shows the second way to map inheritance relationships. Mapping rules run through all DERCS elements and can access and modify the information contained in the DERCS model. In the line 12, one can see that, after several information and consistency checks, the rules found an attribute in the abstract super class that, in turn, is added to the child class—the same happens with other features (e.g., methods) of the abstract super class. Listing 2 (lines 8, 30–36) shows the VHDL constructs generated from executing this script using the information of Number class. The digit attribute and setDigit and initialize methods are inherited from Display (see Fig. 2). Since digit attribute has a setter method (i.e., setDigit), the proposed UML-to-VHDL mapping determines that the inherited attribute digit is mapped to an INOUT port (see line 8). Details on attributes and methods mappings are discussed in [15].

figure a
figure b

When the class Display is modified to represent a concrete class, the proposed UML-to-VHDL mapping generates an entity for this class as shown in the Listing 3. The display component is instantiated within the number entity in a way similar to a “regular” association between classes (see example in Listing 2, lines 18–23).

figure c

Other important feature supported by the proposed UML-to-VHDL mapping is the association relationship between classes. Table 1 shows that associations between classes are mapped to components instances and their related ports mapping. For instance, the composition relationship between Number and Segment classes (see Fig. 2) generates the instantiation of seven components, since this is a fixed 1-to-7 relationship. Listing 2 depicts this composition relationship mapping: lines 18–24 show the instantiation of the first of seven segment components within the number entity, as well as lines 5–7 show the ports associated to these components.

Regarding system behavior, this work provides the support for mapping the complete semantics of sequence diagrams elements into VHDL constructs. For that, the proposed UML-to-VHDL mapping supports the use of synchronous and asynchronous method callsFootnote 5, as well as MARTE \(\texttt {<<TimedEvent>>}\) stereotype to specify active objectFootnote 6 concurrent behaviors.

Synchronous execution semantics is common in software components, while asynchronous execution semantics can be found in both software and hardware components. Synchronous execution semantics is not supported in VHDL synthesizable set, and hence, to support the use of synchronous method calls in sequence diagrams a heuristic has been proposed. The proposed UML-to-VHDL mapping defines that the whole behavior of a called method must be incorporated in the caller method behavior at the point in which the synchronous method call is specified. In other words, the VHDL fragment of the called method behavior is included into the VHDL fragment of the caller method. On the other hand, asynchronous execution semantics is supported in VHDL synthesizable set by means of processes. Therefore, besides creating a separated process for each method whose behavior is called asynchronously, the proposed UML-to-VHDL mapping defines a triggering control signal for this behavior. When an asynchronous method call is identified in the sequence diagram, a VHDL signal assignment is generated. Interested readers should refer to [15] for more details.

Fig. 3
figure 3

Sequence diagram of systemControl.refreshDigit

Full size image

To illustrate the generation of VHDL code from a sequence diagram, Fig. 3 depicts the behavior of refreshDigit method of SystemControl class. VHDL description for this method is shown in Listing 4. As one can observe, the alt combined fragment is translated to an if-then-else statement (lines 8, 12, 16, etc.) and the messages within each compartment became action statements. According to AMoDE-RT modeling guidelines (see [33]), messages 2 and 5 represent assignment actions and are translated to the signal assignment statements shown in lines 9 and 11. Message 3, on the other hand, represents a synchronous method call of the getSecondUnit method, whose returned value is assigned to a variable. As discussed, the corresponding called method behavior is added at the point of the synchronous method call. In this case, as this message refers to a getter method, its behavior returns the current value of seconds counter. VHDL fragment that corresponds to this behavior is a variable assignment statement, which is included in the refreshDigit method behavior (i.e., the caller method) as shown in line 10. Similar VHDL fragments have been generated for the other messages contained within the alt combined fragment, as one can see in lines 12–15.

figure d

It is important to highlight that sequence diagram elements provide all information needed to generate a VHDL process. As demonstrated in the Sect. 4, the proposed approach allows the generation of the complete and fully synthesizable VHDL description based on the information provided in the class diagram and various sequence diagrams. For that, 29 scripts of mapping rules have been created, totalizing 2365 code lines. By using these mapping rules scripts, engineers are allowed to use high-level object-oriented concepts supported in UML such as: encapsulation by means of get/set methods; 1-to-n relationships such as aggregations and compositions; inheritance/generalization relationships; full semantics of sequence diagrams, such as combined fragments, synchronous and asynchronous method calls. For additional details see [15].

3.3 Non-functional requirements

AMoDE-RT uses DERAF aspects to handle crosscutting concerns in a platform independent way within UML/MARTE models. The high-level semantics of DERAF allow its aspects to be implemented in distinct target platforms, including those that do not support AOSD concepts [32]. This section provides only an overview of the VHDL implementation of three DERAF aspects used in the case study. Details on how aspects adaptations are implemented in VHDL have been discussed in [14].

3.3.1 PeriodicTiming

PeriodicTiming aspect [33] deals with the periodic execution of one or more active objects behaviors. A similar behavior is achieved triggering periodically a process within VHDL entities. Therefore, the proposed VHDL implementation of PeriodicTiming considers VHDL entities as active objects, whereas each periodic behavior is mapped to a process. The execution frequency of periodic processes is controlled via a clock divider component associated to the entity. Therefore, in summary, PeriodicTiming aspect modifies the generated code by including a clock divider for each affected entity, as well as creates the interconnection logic between this component and the affected processes.

The clock divider is included as a FPGA platform component through mapping rules of platform configuration. Such a component is included in the generated VHDL files when PeriodicTiming aspect is used in the UML model. In fact, PeriodicTiming mapping rules scripts do not define a clock divider component; they only use its services. The target platform library should provide resources for aspect implementation related to the non-functional requirements handling [32]. Such an approach makes PeriodicTiming aspect portable to other platforms, which have their own mechanisms to control the execution frequency of active objects. According to AMoDE-RT approach, embedded system specifications (i.e., models) must be platform independent, in order to allow the reuse of model elements in distinct projects and with different target platforms. Therefore, when GenERTiCA identifies that aspects have been specified in the UML/MARTE model, it includes the necessary platform services used in their implementation, i.e., mapping rules scripts. In this case, the clock divider component is included as a FPGA platform component by means of platform configuration mapping rules, but only when PeriodicTiming aspect is used in the model.

3.3.2 DataFreshness

DataFreshness [1] can be understood as the temporal validity of real-time data. Such kind of non-functional requirement is important for some embedded system applications, such as control systems. In such systems, data can only be used whether it is temporally valid. For instance, before using data coming from other components (e.g., sensors), it is necessary to check whether these data are updated. To address such a non-functional requirement, DataFreshness aspect [33] associates timestamps with controlled data, checking them before using such data.

VHDL implementation of DataFreshness creates constants representing the temporal validity of affected object attributes. An additional process is created within the entity that represents the affected object. This process controls whether values are updated by using a one-bit signal, which, in turn, is checked before any reading access of the controlled attribute.

However, it is worth mentioning that this approach is one possible implementation of Datafreshness aspect. Other engineers may handle data freshness non-functional requirements in a different way. This VHDL implementation has been proposed as proof-of-concept for AMoDE-RT aspect-oriented MDE approach, and hence, more efficient implementations are indeed feasible.

3.3.3 COPMonitoring

Computer Operating Properly Monitoring (COPMonitoring) aspect deals with the identification of faults in system components (hardware and software). This aspect adds a mechanism to monitor system components, checking whether they are executing correctly. For that, monitored components must periodically communicate with such a mechanism to inform they are executing without problems. When any component fails to accomplish such a communication, it is considered faulty and the system is warned on such an issue. Thus, the system may take any measure to overcome the problems caused by such a faulty component.

The proposed VHDL implementation of COPMonitoring aspect consists in a watchdog timer, an interrupt mechanism, and all glue logic that implements the mentioned behavior. One watchdog timer component instance is created for each affected entity, which, in turn, must handle the watchdog timeout interruption, i.e., it must handle the faults identified by the watchdog timer. In this implementation, when a watchdog timeout occurs, the system is reset. Moreover, the behavior of the affected entity is modified to include the logic that will reset the watchdog timer.

Watchdog components shall be provided by the component library of the chosen target FPGA platform. As it happened with the clock divider component in the PeriodicTiming aspect, when GenERTiCA identifies that COPMonitoring aspect is specified in the UML model, all required services are included into the generated VHDL description. Moreover, it is important to highlight that COPMonitoring is the first aspect that deals with faults provided within DERAF framework. This is an additional contribution of this work.

3.3.4 Example of VHDL implementation: COPMonitoring aspect

To illustrate the use of aspects in model level and its transformation to VHDL code, COPMonitoring aspect is taken into consideration in the context of the digital watch case study. Figure 4 shows the COPMonitoring aspect and its crosscutting relation with Number class. In this example, the seven-segment display represented by Number class may eventually fail during system runtime. Therefore, COPMonitoring is used to identify this fail and then warn the system so that corrective measures may be executed. For that, COPMonitoring adds a watchdog timer to the system, which, in turn, must be reset by Number component within 1 ms after the previous reset.

Fig. 4
figure 4

ACOD diagram for number class of Digital Watch project

Full size image

The next step is to define the system components that are affected by COPMonitoring aspect. In this example, a join point definition is created to select all hardware resource that must be monitored (see Fig. 5a) and other join point selects resources that depend on these resources (Fig. 5b). The pointcut pcInterruptionHandling (indicated in Fig. 4) uses JPDD_interruptionHandler join point (Fig. 5b) to specify the elements that are affected by the InterruptionHandler adaptation. The mapping rule script of this adaptation is shown in Listing 5. On the other hand, Listing 6 shows a fragment of the generated VHDL code for Number entity that includes the VHDL statements added by InterruptionHandler adaptation of COPMonitoring (lines 9–22). This adaptation code has been added automatically during the code generation process by the GenERTiCA aspects weaving engine.

Fig. 5
figure 5

Join points definitions. a Code instrumentation. b Interruption handler

Full size image
figure e
figure f

3.4 On the VHDL implementation of the remainder DERAF aspects

DERAF provides a total of 22 aspects classified according the non-functional requirements classification proposed in [10]. Although this work has focused on implementing VHDL mapping rules for PeriodicTiming, DataFreshness and COPMonitoring Footnote 7, other DERAF aspects can be implemented as well. However, due to space constraints, this section discusses briefly a possible VHDL implementation for some of these aspects.

Timing package provides aspects that deal with time issues. Besides the PeriodicTiming aspect, this package provides the following aspects: TimingAttributes, TimeBoundedActivity, SchedulingSupport. For instance, let us consider the VHDL implementation of SchedulingSupport aspect. This aspect inserts a scheduler object in the affected computing nodes. The scheduler object is responsible to control active objects execution, indicating instants at which they must start performing their behavior. In VHDL, all process execute in parallel without the need for any element to explicitly start their execution. However, when one considers reconfigurable FPGA devices, SchedulingSupport can be used to control the partial reconfigurations during runtime, and hence, what tasks/components execute on the FPGA during a given time interval. For that, SchedulingSupport will add an entity/componentFootnote 8 to control and handle the FPGA partial reconfiguration. In addition, this aspect must add the logic to: (i) manage the reconfigurable blocks, and (ii) implement the scheduling policy, e.g., FIFO or EDF.

Precision package provides aspects that deal with the precision in meeting time requirements. In addition to DataFreshness aspect, this package provides the following aspects: Jitter, ToleratedDelay, ClockDrift. For instance, Jitter aspect measures the variance on timing characteristics of the activities performed by the system, e.g., the periodic activation of active objects. A possible VHDL implementation for this aspect would be the following. Firstly, a variable or signal is included in the affected processes. This variable stores the previous occurrence of the controlled event, e.g., the start of the execution of a periodic process. This variable would be used to calculate the jitter of the controlled event, i.e., the difference between current and previous occurrences of such an event. If the jitter is greater than the tolerated threshold, a signal indicated such an issue to the affected entity, and hence, it can execute some process to mitigate the jitter effects.

Synchronization package provides the following aspects to deal with non-functional requirements related to the synchronization and the concurrent access control to shared resources: ConcurrentAccessControl, MessageSynchronization. For instance, ConcurrentAccessControl aspect provides means to control the concurrent access to objects, which share their attributes information with other objects. In VHDL, such a non-functional issue might be understood as concurrent access to shared variables or signals by distinct parallel processes within an entity. A simple implementation of this aspect would be to include a busy signal to indicate when a shared variable/signal is being used by any process. Other process will have access to this shared variable/signal only when the busy signal indicates that no one else is accessing it. In addition, it is important to include a logic that implements an algorithm or protocol that assures that only one process is able to set the busy signal to “on”.

Communication package provides the following aspects to deal with objects communication in terms of messages sending: MessageAck, MessageIntegrity, MessageCompression. In the case of a VHDL implementation of these aspects, a message sending is mapped to a signal connecting two entities. Therefore, for instance, MessageAck aspect may be implemented using a handshaking protocol. For each affected OUT or INOUT port in the sender entity, an additional IN port (i.e., to indicate an acknowledge from the other communication partner) is added to the entity port declaration. Likewise, on the receiver entity, for each IN or INOUT port, an additional OUT port is added. In addition, the logic to set the acknowledge signal is added into the receiver entity, as well as the logic for waiting the acknowledge is added into the sender entity.

TaskAllocation package provides the aspects to handle non-functional requirements related to objects distribution on different computing devices at runtime: NodeStatusRetrieval, TaskMigration. For instance, NodeStatusRetrieval aspect includes a mechanism to gather information on the system dynamic characteristics, such as processing load, message sending and reception rates, and if the computing device is running. A possible VHDL implementation for this aspect would be to include variables or signals to calculate these metrics while the system is running. For instance, all signal assignments that indicate a communication among entities may be subject of this statistics gathering.

Finally, the Embedded package provides aspects to monitor and control the usage of system physical resources, e.g., FPGA area, memory, energy. The following aspects are provided: HwAreaMonitoring, HwAreaControl, MemoryMonitoring, MemoryControl, EnergyMonitoring, EnergyControl. For instance, EnergyMonitoring aspect relies on the chosen target FPGA platform for providing means to monitor energy consumed by system activities. A VHDL implementation of this aspect would add the logic to measure the energy level at the beginning and at the end of the execution of processes within an entity. In addition, an additional logic is included in order to calculate the energy consumed by these processes, and hence, a measure of the remaining energy can be obtained.

4 Case studies and results

This work has been evaluated through some case studies, namely, a line-following robot, a valve control system and a digital watch. These systems have been designed using AMoDE-RT approach and implemented as an ASIP on a Xilinx Spartan-6 FPGA (model XC6LX16-CS324, Speed:-3) using Xilinx ISE WebPack.

System requirements have been specified in the UML/MARTE model following AMoDE-RT modeling guidelines [33]. Thereafter, GenERTiCA, using the created UML/MARTE model and the proposed set of VHDL mapping rules as input, has been generated a VHDL description. Once the VHDL description is generated, it was synthesized and uploaded into the FPGA by using Xilinx ISE WebPack.

By using the UML-to-VHDL transformation proposed in this work, we have been able to generate complete and synthesizable VHDL descriptions for all three case studies. No manual modification has been performed on the generated VHDL description, since it was synthesized without errors at the first attempt, indicating that the mapping rules scripts have been well specified.

4.1 Line-following robot

The robot case study is composed of two infrared sensors: one detects the left-hand side of the line, while the other one detects the right-hand side. An Arduino Uno board was used as an Analog-to-Digital Converter. It converts sensors analog signals into digital signals, which, in turn, are sent to FPGA board input ports. The robot has two servomotors to spin left/right wheels. The movement control system commands the robot to turn left/right based on sensors input.

This project presents three non-functional requirements: (i) active objects must be periodically activated according to the execution frequency specified in \(\texttt {<<TimedEvent>>}\) stereotype; (ii) servomotor faults must be handled within the robot control system; (iii) sensor and motor data have temporal validity. These requirements have been handled through PeriodicTiming, COPMonitoring and DataFreshness aspects, respectively.

In this evaluation, the line-following robot has been designed in two versions. The first one does not use DERAF aspects in UML/MARTE model. Non-functional requirements handling has been implemented manually, i.e., the generated VHDL description was manually modified in order to include these requirements handling. This implementation was done by the same engineer that made the implementation of DERAF aspects. On the other hand, in the second version, DERAF aspects have been used, and the complete VHDL description has been automatically generated. There was no manual modification in the generated VHDL description. The UML model of for both versions consists of one class diagram and five sequence diagrams. Table 6 provides details on these models. It is worth pointing out that both versions have implemented the same set of functional and non-functional requirements. In the first version of the line-following robot, the crosscutting concerns related to non-functional requirements have been implemented directly on the generated VHDL code. In addition, besides very high-level indications of non-functional requirements (by means of MARTE stereotypes), the UML model does not specify any handling of these crosscutting concerns.

Synthesis results are presented in Table 2. First column shows analyzed metrics. Column “FPGA resources” presents the total amount of resources available in FPGA. Third and fourth columns depict metrics for, respectively, object-oriented version (V1) and the aspect-oriented version (V2). GenERTiCA has generated the VHDL description of both versions. However, as mentioned, V1 was modified manually in order to include non-functional requirements handling; and V2 was fully generated automatically due to the use of DERAF aspects and the proposed VHDL mapping rules. Finally, last column presents the variation (percentage) in the analyzed metrics of the two versions.

Table 2 Synthesized system metrics on line-following robot design
Full size table

As one can see, Lines of Code (LOC) increased around 16 % in V2. However, the amount of utilized FPGA hardware has doubled, since used FPGA resources increases ca. 184 on average.Footnote 9 Such a result indicates that, for VHDL descriptions, an increase in LOC cannot be related to a proportional increase in FPGA resources utilization. In software, on the other hand, this relation can be established, since the binary code size usually increases proportionally to LOC.

Furthermore, even though the generated system ASIP in V2 has a large increase in FPGA resources utilization, its performance is better: it presents a shorter critical path (6.22 % decrease in minimum period in comparison with V1), leading to a greater operation frequency (6.65 % increase). This improvement may have been achieved due to a better modularization of system elements achieved by using DERAF aspects (see Sect. 4.4), since concerns are better separated among components as indicated in TR metric presented in Table 5. Such a modularization improvement has also impacted positively on utilization ratio of FFs and LUTs per slice: 2.02 FF/slice and 3.16 LUT/slice in V1; and 2.65 FF/slice and 3.62 LUT/slice. In other words, this could indicate that the place and routing algorithms of the synthesis tool use more efficiently the available slices in V2, since the increase in FF/LUT is not proportional to the increase of slices. However, it is necessary to perform a more detailed analysis to confirm such hypotheses. In larger systems, this difference in utilization ratio may impact strongly on system performance, i.e., the higher the FF/LUT utilization ratio, the lesser the amount of used slices and better the system overall performance. Moreover, these results are different from those presented in [22], where aspects had a lesser impact on area usage (\(3~\%\)) but did not affect system performance. Finally, it is worth pointing out that the trade-off between performance and FPGA area depends on system requirements and constraints. Hence, engineers shall choose a design approach that meets the projects requirements and constraints.

4.2 Valve control system

The valve control system case study was originally presented in [20] and extended in [21]. The aim of this case study is twofold: (i) demonstrate the practicability of the proposed UML-to-VHDL transformation; and (ii) compare the valve control system created in [21] with the one created in this work. For such an evaluation, some metrics have been calculated on both case studies. In summary, this system is composed by an automatic valve to regulate the water flow and sensors that provide information about the valve states. The UML model consists of one class diagram and four sequence diagrams, whose details are presented in Table 6.

This case study consists of generating the VHDL description from the mention UML model using both the previous approach [20, 21] and the new approach proposed in this work. Thereafter, both implementations have been compared. Table 3 shows the obtained metrics. First column indicates each analyzed metrics, while the second one presents the available resources in Spartan-6 FPGA. Third column shows results presented in [21] whereas fourth column presents results obtained by applying the proposed approach. Finally, fifth column shows differences between this work results and [21].

Table 3 Synthesized system metrics on valve control system
Full size table

The results show a considerable improvement in utilized FPGA area for the VHDL description generated by following the proposed approach. Such an improvement has been obtained due to a better modularization of components, which was achieved by applying mapping rules that follow the key principles of object-oriented design. In other words, system functions are better divided between components. A well-structured VHDL description leads to less resource usage, opening room for inclusion of additional functions into system design, and hence, improving system scalability.

On the other hand, when Lines of Code (LOC) is considered, the proposed approach resulted in a considerable increase in the number of generated VHDL lines. Such an increase is related to a greater number of components generated when using the proposed approach. As discussed, due to a better modularization, FPGA area was better utilized in spite of this increase in LOC, i.e. the code generated using the UML-to-VHDL mapping proposed in this work demands about 23 % lesser slices than our previous approach. In addition, there is the small decrease in system performance, i.e., operation frequency decreased from 307 to 302 Mhz (1.54 %). Such a result might had happened due to the increased number of interconnected components, which led to a longer circuit critical path. It is worth noting that system performance can be improved by making optimizations on the proposed mapping rules, aiming enhancements on the generated VHDL description.

4.3 Digital watch

The digital watch case study has already been introduced in Sect. 3. For this system, the following non-functional requirements have been identified: periodic refresh of display; periodic time counting; and identification of display faults. These requirements have been handled by PeriodicTiming and COPMonitoring aspects. As in the line-following robot, the digital watch system has been designed in two versions. The first one does not use DERAF, and hence, the non-functional requirements handling has been implemented manually on the generated VHDL description. The second one uses DERAF and the generated VHDL description has been synthesized without modifications.

For this case study, the created UML model consists of one class diagram and six sequence diagrams. Table 6 shows the details of this model It is worth mentioning that, although the higher number of messages within the sequence diagrams, the digital watch is a small system. Such an amount of messages is the result of describing the seven-segment display main behavior using a sequence diagram rather than a state machine diagram, which would present this behavior in a less verbose and more elegant way. These diagram covered system functional and non-functional requirements and provided the details needed to code generation.

Table 4 Synthesized system metrics on digital watch
Full size table

Table 4 shows the synthesis results. One can notice version V2 of the digital watch uses less slices, whereas there is an increase in the number of FF, LUT and IOBs. It can also be observed a small increase in system performance (\(0.75~\%\)) and an increase of LOC, as it happened in the line-following robot case study. This corroborates with the claim that there is no relationship between the amount of LOC and the FPGA area usage. Moreover, the better modularization achieved in version V2 (see Sect. 4.4) might had helped the place/route algorithms of the used synthesis tool, leading to a better used of FPGA resources. However, it is important to highlight that such an indication is based on empirical knowledge rather than on solid analysis, and hence, in order to develop a definitive conclusion on this issue further analyses are needed.

4.4 Assessing the impact of DERAF on generated VHDL descriptions

This section discusses the influence of DERAF aspects on the generated VHDL descriptions for handling the crosscutting concerns related to non-functional requirements. Table 5 shows this analysis through some metrics that have been calculated on the generated VHDL descriptions of all case studies. The first three columns indicate the number of code lines for: (i) the architecture description of VHDL entities without any aspect (LOC*), (ii) the architecture description of VHDL entities with aspects (LOWC), and (iii) the implementation of all used aspect adaptations (LOAC). The remaining columns indicate AOSD-specific metrics. CDLOC [9] indicates the number of context switches between functional and non-functional requirements handling code. One can see that LOAC varies among the case studies. Although the DERAF aspects adaptation have been implemented onceFootnote 10 and reused throughout all case studies, not all aspect adaptations have been used in all case studies. This happened due to the requirements of each systems that did not demand the use of all adaptations, e.g., all adaptations of PeriodicTiming are used in the line-following robot, whereas one of them was not necessary in the other case studies.

Table 5 Impact of DERAF on projects design
Full size table

CDLOC and LOC* are used to calculate the Tangling Ratio (TR). According to [2], TR indicates how much functional and non-functional concerns are intermixed. The obtained average value of 10.48 % is similar to results obtained in [2]. This indicates that the impact of DERAF aspects on the generated VHDL code is around 10 % for these case studies. It is important to highlight that higher TR indicates a more intermixed concern code within functional code, whereas lower TR indicates a more localized concern code. For instance, PeriodicTiming and COPMonitoring present higher impact on the line-following robot than on the other case studies. On the other hand DataFreshness has a higher impact on the valve control system. This impact is related to the amount of elements affected by these aspects, which, in turn, is associated to the non-functional requirements of each system.

Table 6 Overview of projects features
Full size table

Aspect Bloat (AB) [9] metric indicates the efficiency on using an aspect. AB is calculated considering the amount of VHDL code lines generated by DERAF aspects, as well as the amount of lines that have been written as DERAF adaptation scripts. In addition, AB indicates the impact of aspects on reusability throughout the case studies. According to [2], AB values lower than 1 indicate a low efficiency of the aspect because the number lines used to implement the aspect is higher than the lines woven in the actual system implementation. Therefore, when aspects adaptations are applied on many join points, aspect efficiency increases. AB average value is 1.43, indicating that, in average, for each aspect adaptation mapping rule script 1.43 lines of VHDL have been generated. One may observe that the most effective aspect is DataFreshness since its average AB is 1.60. On the other hand, it may be seen that AB value of PeriodicTiming is lesser than 1 in the valve control system, as well as AB value of COPMonitoring in the line-following robot case study. In the other case studies, AB metric of these aspects is higher than 1, indicating a higher efficiency. Additionally, it is important to highlight that, when the same implementation is reused without modifications in several case studies, AB may be calculated considering this historical data, and hence, the aspects efficiency might improve due to their reuse.

Considering the engineering cost, a comprehensive discussion on applying AMoDE-RT in the design of three other embedded systemsFootnote 11 is presented in [32]. Although the present work does not evaluate the same set of high-level design metrics, this work demonstrates and evaluates the impact of AMoDE-RT on the VHDL implementation of three real-world embedded systems. For that, a set of lower-level metrics has been analyzed. These metrics consider the system implementation rather than the UML model, and hence, the results presented in this section are complementary to the ones discussed in [32]. The effort for obtained the VHDL implementation is decreased due to the reuse of DERAF and the VHDL mapping rules scripts. The main reasons of such a decrease are: (i) DERAF aspects have been used within the UML model of the three case studies without any modification on their adaptations—engineers need only to describe the affected elements by specifying the pointcuts, which may vary for different application; (ii) UML-to-VHDL mapping rules have been created for the line-following robot and reused without modifications in the other case studies; (iii) AB metric is greater than 1 (in average), indicating that aspect added more lines of VHDL code than the number of script lines actually written by the engineers. (iv) UML-to-VHDL mapping rules have been created in the line-following robot and reused without modification in the other case studies. In addition, considering the statistics on the UML models and LOC of each case study (see Table 6), it is possible to see that GenERTiCA was able to generate 91.63 lines of VHDL code per class. These results corroborate with the results discussed in [32], indicating that, by using AMoDE-RT and its tools, it is possible to decrease the design effort in both system specification and implementation.

4.5 Pitfalls and limitations

Although the achieved results indicate that the expected benefits have been obtained by applying AMoDE-RT and the proposed UML-to-VHDL mapping, some factors may influence the conducted evaluation and the obtained results, as it is usual in any empirical study.

Despite the proposed work has been successfully applied to design of a FPGA-based embedded system, the proposed VHDL implementation of DERAF aspects presents some issues. Some aspects adaptation implementation have interfered in the project specification, e.g., DataFreshness reads signal value associated to an OUT port, but such a situation is forbidden in VHDL. To overcome this problem, this port type had to be changed to INOUT, so that this signal could be read internally within the entity. Other issue is related to the interference among aspect adaptations. For instance, a signal created in COPMonitoring had interfered the implementation created for DataFreshness, and hence, COPMonitoring implementation, i.e., its mapping rule scripts, had to be modified.

Other issue is regarding the proposed UML-to-VHDL mapping rules. Such mapping rules have been created with the focus on keeping the high-level semantics of the UML model in the generated VHDL description, in order to facilitate the hardware/software co-design and design space exploration. This may be achieved by means of using distinct hardware and software mapping rules on the same source UML model. At the moment, this research has not evaluated the effect of different kinds of strategies for the generated VHDL implementation, e.g., optimizations for area or speed, keeping/flattening hierarchy, or using behavioral or structural description style. Therefore, the obtained FPGA slices utilization rate, as well as system performance, might be directly affected due to a distinct description strategy.

Finally, it is important to mention that engineers skills may affect the results discussed in this paper. Engineers knowledge of UML or the application domain may impact the quality of the produced model, leading to inaccuracies in the discussed results. In addition, experience with AMoDE-RT, GenERTiCA as well as the chosen target platform may affect the way engineers describe the mapping rules. Thus, trained engineers might create better mapping rules for a new target language, e.g., SystemC, Verilog, etc.

5 Final remarks

This paper discusses an approach that allows the automatic generation of fully synthesizable VHDL descriptions from high-level UML/MARTE models. By applying MDE and AOSD, the proposed approach deals with functional and non-functional requirements in a platform independent way, opening room for hardware and software co-design of embedded systems.

One of the main contributions of this work is a new definition of UML-to-VHDL mapping rules, which have been implemented as code generation scripts for the GenERTiCA tool. These mapping rules include the support for key object-oriented features supported in UML, namely, encapsulation, inheritance, and 1-to-n associations, as well as the support for synchronous and asynchronous method calls from sequence diagrams. In addition, a VHDL implementation of some DERAF aspects have been created, in order to handle with crosscutting concerns related to system non-functional requirements. Such a handling code is woven into functional requirements code. Hence, it is important to highlight that, in comparison with a previous work [20, 21], a greater amount of VHDL statements is generated, resulting in complete and fully synthesizable VHDL descriptions. Engineers do not need to modify manually the generated VHDL files, since our experiments have demonstrated that the generated VHDL descriptions have been synthesized and uploaded without any error into a FPGA device.

In order to assess the proposed work, this paper has presented the design of the control systems of a line-following robot, a valve control system and a simple digital watch. These systems have been implemented as an ASIP on a FPGA development kit. AMoDE-RT has been successfully applied, impacting positively in system implementation, for instance, in components modularization (TR metric is around 10 % in average) and system performance (circuit frequency increased 6.65 % in the line-following robot system). It is worth mentioning that occupied FPGA resources increased in the aspect-oriented version of this system. However, slices are used more efficiently. In larger systems, this may lead to a better use of FPGA resources without penalizing system performance. On the other hand, as DERAF aspects have led to a better modularization of crosscutting concerns, their usage opens room for a good reutilization rate. AB and TR metrics are indication that corroborate with this inference. As AMoDE-RT advocates for using platform independent specifications, e.g., UML models and DERAF aspects, design complexity management may be improved due to an enhanced opportunity for hardware/software co-design, as well as reuse of artifacts [32].

As future work, more case studies are already being performed. A similar analysis is going to be executed, in order to demonstrate the suitability and feasibility of using platform independent aspects to design FPGA-based embedded real-time systems. New rules for UML elements that are not yet covered will be defined as well, e.g., state machine diagrams and their relationship with sequence diagrams. In addition, other DERAF aspects need to be implemented in VHDL. However, for that, it is important to obtain or create a set of reusable soft IP components, in order to implement aspects adaptations using their services.