Regular Hardware Architecture Modeling with UML 2 - Semantic Scholar

Regular Hardware Architecture Modeling with UML 2 Arnaud C UCCURU, Pierre B OULET, Jean-Luc D EKEYSER Laboratoire d’Informatique Fondamentale de Lille University of Lille, France {Cuccuru,Boulet,Dekeyser}@lifl.fr

Abstract Concepts introduced in most Hardware Architecture Models based on UML (mainly processing, storage and communication resources) are enough to model all kinds of architecture at a high abstraction level, even parallel architectures. However, a model limited to these few concepts can be tedious to use, for example if you have to model hardware architectures composed of tens of processing elements connected in a regular way. Moreover, the topology of a target architecture can (or must) strongly influence the way to develop or schedule an application. The information gathered in the hardware model must drive the design (development and scheduling) of the application : The clearer and the more expressive the information is, the more efficient the design of the application is. Factorization mechanisms proposed in UML can bring ambiguity in the models, and are not powerful enough for this purpose. We show how the mechanisms that we introduce in the hardware architecture model of our “Y Model” approach help us to fill this gap.

1 Introduction In the domain of embedded system design, one needs to design both the application and the hardware architecture on which it will execute. As Systems-on-Chip become more and more common, there is a growing need to design the hardware architecture of the chip at a high level of abstraction. The high-level model can be used to dimension the resources needed to meet the requirements (e.g. time or power consumption constraints) of the application. It is also useful to map the application to the hardware in the most efficient way.

1.1 Need for Regular Parallel Architecture Modeling We believe that regular parallel computation units will be more and more present in SoCs in the future. This belief is driven by two considerations: 1. Time-to-market constraints are becoming so tight that massive reuse of computation units is one of the only ways to get the computation power needed for next generation embedded applications [14]. 2. Parallelism is a good way to reduce power consumption in SoCs. Indeed at equal computing power, a chip able to run several computations simultaneously will be clocked at a lower frequency than a chip able to run less computations in a given cycle. As frequency is square in the power consumption equation, this leads to important gains. Several such regular parallel architectures already exist [19, 16]. So, a way to model these regular architectures is needed in order to be able to exploit the provided parallelism. A compact way of expressing repetitive architecture is an obvious requirement. No one would name explicitly the 256 processors of a 16 × 16-processor array.

Another good reason for wanting a factorized notation is that such a notation would be more comprehensible for a compiler. As the regularity of the architecture is expressed, it can be exploited to regularly map some repetitive computations (as usually appear in signal processing applications) to the available processing units, thus decreasing the optimization time while producing some more efficient and compact code.

1.2 Hardware Modeling and UML During the last four years, several proposals, emerged from the OMG world or not, have introduced hardware modeling techniques and/or concepts as extensions of UML [18] (Unified Modeling Language). AADL [7] (Avionics Architecture Description Language) is used to describe the structure of an embedded system as a gathering of software and hardware components. It can describe both functional (data inputs and outputs) and non functional (such as timing) aspects of components. A UML profile for AADL (based on UML 2) is under standardization, and will be soon submitted to the OMG. The hardware model part of this proposal introduces four concepts : memory, processor, bus and device. UML SPT Profile [17] (Scheduling, Performance, and Time analysis) is an UML 1.x OMG standard profile for embedded system modeling. It introduces various hardware (or more generally platform) modeling concepts and an interesting resource classification according to three criteria: purpose (processor, communication and device), activeness (a resource is active when it is able to generate stimuli, and passive when it is only able to react when prompted by stimuli), and protection (a resource is protected when the access to services it offers is restricted according to some control access policy). HaSoC [9, 10] (Hardware and Software Objects on Chip) is a platform-based design methodology using UML to represent the high-level structure and the behavior of the hardware architecture model of an application platform. The hardware architecture model of HaSoC distinguishes general-purpose hardware (processors, memory), programmable logic (FPGAs), fixed-function (custom) hardware, and interconnection elements. This model enables to generate SystemC code for simulation and particularly for hardware synthesis. SLOOP [21] (System Level design with Object-Oriented Process) is a design process that integrates a methodology based on UML for both SoC modeling and performance evaluation at system level. The hardware model proposed is similar to those previously presented: it proposes hardware elements such as processors, memories, buses and hardware devices. ACCORD/UML methodology [15] is basically an extension of UML for distributed real-time embedded systems modeling, taking into account only the software part of a system. In the ACOTRIS project [1], ACCORD UML has been extended with hardware modeling functionalities. The hardware model is in fact the SynDEx [20] hardware model : Processors are connected via Communication Media. None of the above models proposes some specific way to express regular parallel architectures in a factorized way. UML itself proposes a few factorization mechanisms, though.

1.3 UML 2 Factorization Mechanisms Limitations UML proposes basic factorization mechanisms in internal structure diagrams. Indeed, it’s possible to add cardinalities on parts and connectors in the components structure. Nevertheless, these mechanisms are intended to be used for simple connection patterns, such as the “star connector pattern” illustrated in Fig. 1. How to model complex patterns such as a “perfect shuffle” (see Fig. 2) between two stages of an Omega interconnection network [3] ? In the same way,

how to model a grid of communicating PEs (see Fig. 3), emphasizing the logical paths (north, south, east, west) ?

Figure 1: Star Connector Pattern

Figure 2: ”Perfect shuffle” between two stages of an Omega interconnection network

Figure 3: A grid of 4 × 4 PEs

Furthermore, semantics related to the number of connections and connection points for two parts with different cardinalities connected together is relatively ambiguous. Moreover (and consequently), it’s not easy to get relevant information from such a specification to efficiently design or schedule an application targeted for this architecture. Therefore, we can conclude that UML 2 can not be used without extensions to model regular architectures.

2 Extending UML for Regular Architecture Modeling Concerning software engineering, UML has become a standard language for modeling. It does not present a particular methodology and it can be used to model different point of view of the same system. UML 2 introduces the component notion and structure diagrams that facilitate architecture modeling. With deployment diagrams, UML 2 also considers hardware descriptions and mapping. Unfortunately, the model for applications differs from the model

for hardware. The same comment applies for the mapping of an application on a particular hardware, for example a System-on-Chip: we want to benefit from the component notion, and the hierarchical constructs of the structural and behavioral diagrams for the hardware design as well as for the software design. However, as we have shown in the previous section, factorization mechanisms proposed in UML structural diagrams can bring ambiguity in the models, and are not powerful enough to be suited to our needs. Therefore, our approach consists in extending a subset of UML to enable the modeling of regular architectures. In [2], we have presented a hierarchical hardware architecture model, with precise syntactic and semantic rules. The UML extensions we present in this paper are integrated in this model. The abstract syntax of our model is described by a MOF metamodel defined as an extension of the UML 2 metamodel. The metamodeling brings a set of tools which will enable us to specify our application and hardware architecture models using UML tools, to reuse functional and physical IPs, to ensure refinements between abstraction levels via mapping rules, to ensure interoperability between the different abstraction levels used in a same codesign, and to ensure the opening to other tools, like verification tools, thought the use of standards. The concrete syntax is defined by a profile for UML 2. This profile is, for the moment, only based on UML 2 class diagrams and internal structure diagrams 1 . In this paper, we focus on the description of the profile (there is almost a “one to one” equivalence between concepts introduced in the metamodel and stereotypes introduced in the profile). Section 3 summaries the so-called “Y model approach” [6], and gives a brief recall on the basics of our hardware architecture model and section 4 presents the mechanisms we introduce to model regular architectures.

3 The "Y Model" approach Our proposal [6] is partially based upon the “Y-chart” [8] concepts. A clear distinction is made between application and hardware, which are related via an explicit mapping. ISP-UML (application) PIM

use model

use model

PIM

association PIM

- Application and architecture association concepts independently of targeted platforms.

deployment PSM

- Platform specification concepts

hardware architecture PIM

PSM Mapping rules

Java Model

DPN* Model

interoperability Model

SystemC Model

VHDL Model

*Distributed Process Network

Figure 4: Y Model Approach The application and hardware architecture are described by different metamodels. The proposed methodology is to separately design the two models for the application and the hardware architecture (maybe by two different people). At this point, it becomes possible to map the application model on the hardware architecture model. For this purpose we introduce a 1

We are investigating the introduction of activity diagrams, and possibly state diagrams, to model hardware architecture behavior

third metamodel, the so-called association metamodel, to express the associations between the functional components of the application model and the hardware components of the hardware model. This third metamodel imports the first two metamodels. In the hardware architecture model, resources are classified according to two criteria: a functional criterion, and a structural criterion (Fig. 5). Each resource is characterized by a composition of these two criteria. In UML, it comes to apply two stereotypes to each component.

Figure 5: Resource classification Functional Classification We identify three kinds of function for a component (three stereotypes in UML): a component can be either passive, active, or for interconnection. “PassiveHwComponent” A passive component symbolizes a resource which has the function of supporting data. Typically, we find in this category elements such as RAMs, ROMs, sensors, or actuators. “ActiveHwComponent” An active component symbolizes a resource which has the function of reading or writing into passive resources. It may modify, or not, the data. This category includes elements such as CPUs or DMAs. It also includes more coarse-grained elements, such as a SMP node inside a parallel machine. “InterconnectHwComponent” An interconnection resource connects active and passive components, or active and active ones in the case of a distributed memory architecture. This category includes elements as simple as a bus, or as complex as an omega interconnection network. Structural Classification The structural classification is used to ease the introspection of models and, as a consequence, the automatic or manual exploitation of the gathered data (for example to optimize the mapping of an application on a hardware architecture). We identify three kinds of structure for a component (three stereotypes in UML): a component may be either elementary, compound, or repetitive.

“ElementaryHwComponent” An elementary component is a component without an internal structural description. For example, it could be used in the case where we have a hardware IP for this component, or in the case where we don’t want to model the component more finely. “CompoundHwComponent” A compound component is a component with an internal structure description. A compound component can represent an “executable architecture” (fully defined architecture) or a part of an architecture that will be reused in other contexts. A compound component may be defined with several hierarchy levels: it may be described as the gathering of other “sub” compound components. The benefits of composition are numerous, and they are not specific to our model: encapsulation of structural details not needed at a given hierarchical level, reuse or repetition (in the case of a “RepetitiveHwComponent”) of predefined blocks to model other architectures... “RepetitiveHwComponent” A repetitive component is a particular case of the compound component. The repetitive component structure contains a regular repetition of a single component. This kind of component is well suited to the modeling of regular parallel architectures. The next section will focus on the way to express such kind of architectures using a repetitive component.

4 Regular Hardware Architecture Modeling via Dependence Expressions Basically, our proposal consists in using mechanisms similar to those we have used in the application model. Similiraty between concepts handled within these two models permits to unify and so simplify their understanding and use. This unification is possible as the modeling problems encountered in the two models are actually the same: Expressing the repetition of components and the factorization of the dependences among them. In the application model, these mechanisms are mainly used to express data parallelism in the context of a “DataParallelComponent” [6]. In the hardware architecture model, the UML extensions we introduce enable us to define “iterators” over architectural elements: The “RepetitiveHwComponent”. The structure of a “RepetitiveHwComponent” contains only one instance of an hardware component, i.e. the instance of the component that must be repeated. A RepetitiveHwComponent is characterized by an iteration space, explicitely given or deduced from the specification of the component. With the “MultiPort” concept, we allow to see a port as a collection of ports, or an array of ports, with possibly several dimensions and a size for each dimension. Via the expression of dependence vectors, these two concepts enable to model complex connection patterns such as a perfect shuffle (Fig. 2) or regular architectures such as a 16 × 16PE grid (Fig. 3). Let us illustrate our subject with these two academic examples. Perfect Shuffle Modeling An Omega network (Fig. 6) is a Multistage Interconnection Network (MIN). In each stage of a MIN, multiple switch modules (in our case, crossbars) are used. The modules of two adjacent stages are connected according to a fixed ISC (InterStage Connection) pattern (in our case, a perfect shuffle) [12]. Benefits of such kind of networks are numerous. For example, time for a transaction accross the network is constant 2 . Moreover, the regularity of the structure enables to have simple routing algorithms. 2 Except in case of conflicts. Works such as [11] give methodology on the way to avoid conflicts on an Omega network.

Figure 6: A 8x8 Omega network ISC patterns are generally described with functions such as: 0 ≤ i < N2 ≤i