UML2.0 Profiles for Embedded Systems and Systems On a Chip (SOCs)

Fateh Boutekkouk, Mohammed Benmohammed, Sebastien Bilavarn, Michel Auguin
2009 Journal of Object Technology  
Recent embedded systems and SOCs design is confronted with the problem of the socalled productivity gap. In order to cope with this problem, authors emphasize on using UML as a system level language, so higher level of abstraction is achieved. However UML in its current form has not yet achieved the maturity necessary to enable its efficient use within current embedded systems and SOCs CAD environments. Consequently a proper tuning of UML to the specificities of such systems has became
more » ... . To meet this requirement, many UML profiles have been proposed by both academia and industry. On the other hand enhancements included in UML2.0 has increased UML opportunities to model embedded systems. UML2.0 is qualified to be a component-based which is more suitable for hardware modeling. In this paper we review and compare the most known UML2.0 profiles for embedded systems and SOCs. For each profile, we try to show its defined stereotypes and the corresponding design flow if it exists. We use some objective criteria to highlight the benefits and the pitfalls of each profile. 136 J OURNAL OF OBJECT TECHNOLOGY V OL. 8, NO. 1 principles mentioned above. We believe that if done correctly, the Unified Modeling Language (UML) can be such a language. UML2.0 has brought several significant improvements to support concepts related to Codesign.The latter aims at meeting the system-level requirements by using a concurrent design and validation methodology, thus exploiting the synergism of the hardware and the software parts. Although software (Sw) design techniques may seem foreign to hardware (Hw) designers, at a reasonable level of abstraction such separation can be blurred because many of concepts are similar. For instance Sw objects communicate with messages and Hw blocks communicate with signals. Sw systems reuse classes from libraries and Hw systems reuse IPs (intellectual properties). Embedded systems (ES) are generally defined as application-specific computers, masquerading as non-computers that interact with the physical world and must perform a small set of tasks cheaply and efficiently. ES have specific characteristics such as heterogeneity (hardware / software), ability to react, criticality, real-time and consumption constraints. As the resources are constrained, the design of embedded systems requires optimization. According to Moore's law stipulating that the integration density of VLSI circuits doubles all the eighteen (18) months, embedded systems will contain more one billion of transistors in the near future. Modern ESs are capable to execute very complex algorithms implemented in only one chip (SOC: System-on-a chip). A SOC is a complex and heterogeneous system that can integrate in the same chip hundreds of IPs possibly furnished by different manufactures and connected by communication infrastructure ranging from simple buses to complex On chip networks (NOC : Network On Chip). A general classification of the design process of embedded systems is available through the DajskiY-Chart as shown in Figure 1 . It defines System, Register-Transfer (RT), gate, and transistor levels where each level is defined by the type of objects and where higher level objects are hierarchically composed out of lower level ones. At each level, the design can be described in the form of a behavioral, a structural model, or a physical model. A conventional design process (see figure 2) starts from informal requirements; a functional executable model (eg. C/C++) is modelled from the requirements to capture the system behaviour. At this level there is no difference between software and hardware parts. The final destination of the various parts of the design are decided at the partitioning stage. Two separate design flows start concurrently for the software and hardware. Software parts are compiled for the target processing elements and hardware parts are translated to an HDL (Hardware Description Language) description, then synthesized into ASICs or FPGAs. Intermediate steps of functional and timing verifications and simulations are carried out at different phases. Today 's methodologies fail to meet embedded systems requirements. This is due essentially to the large gap that exists between the specification level and the implementation level on one hand and because the hardware and software teams are still work independently and the actual hardware-software integration takes place lately where discovered errors are often uncorrectable. VOL. 8, NO. 1 JOURNAL OF OBJECT TECHNOLOGY 137 152 J OURNAL OF OBJECT TECHNOLOGY V OL. 8, NO. 1 DIPLODOCUS This profile is based on an existing TURTLE profiling whose first aim was formal analysis. this new profile tends to enhance TURTLE profile to support hardware/software Codesign and related aspects as design space exploration, mapping, and co-simulation. The main limitations are : Since the same abstract specification serves as input to both formal analysis and abstract simulation, It is not clear whether abstraction (in both data and tasks internal behaviour), which is one of the basic principles of DIPLODOCUS conflicts or not with formal semantics of LOTOS. The architectural model is strongly dependant on the TML semantics. TML language is too restrictive since there is no support for hierarchy and input dependant behaviour expression The design space exploration concerns only architecture, but not application. In some cases, we must for instance split an intensive computationally task to parallel subtasks or to merge two tasks with high communication workload into one task. The methodology is still under experimentation, and should prove its efficiency for more complex and realistic architectures [3] . UML PLATFORM
doi:10.5381/jot.2009.8.1.a1 fatcat:coirvylxd5amzmiwtz6ymxi6l4