Multiprocessor chips are now commonly supplied by IC manufacturers. Real-time applications based on this kind of execution platforms are di cult to develop for many reasons: complexity, design space, unpredictability, ... The allocation of the multiple hardware resources to the software entities could have a great impact on the nal result. Then, if the interest to represent the set of hardware computing resources inside an architectural model is obvious, we argue that other hardware elements like shared buses or memory hierarchies must be included in the models if analyze of the timing behavior is expected to be performed. This article gives guidelines to represent, with AADL, shared-memory multiprocessing systems and their memory hierarchies while keeping a high-level model of the hardware architecture.
The growth potential for computing power supplied by general purpose monoprocessor (GPU) systems, is quite decreasing. New gains are related to complex hardware structures and to very advanced fabrication technologies. Especially in the embedded system context, the additional power consumption to paid for increasing the instruction rate is high.
Today, the main answer to that problem is to multiply the number of processing units in VLSI chips. Less aggressive internal core designs allow for increasing the hardware e ciency and reducing the thermal problems (hot spots).
Moreover, as the execution units are multiple, it becomes possible to specialize some of them for dedicated usages. As an example, System-On-Chips like TI OMAPs include multiples GPUs, a DSP and an image processing unit.
These Programmable Heterogeneous Multiprocessors (PHMs) are now execution platforms that the designers must consider when they develop new products. The focus should not be only on the individual processing units, but on the whole hardware system. An early knowledge of some non-functional details of the execution target might be a condition to lead a project to completion. A meaningful performance analysis cannot be conducted without considering a realistic model of the platform, and the data ow. The challenge is to eliminate low-level complexity, while the functional or non-functional behaviors remain close to the reality of the execution environment. The complexity of both the hardware execution platform and the software application requires that designers develop high-level models of their systems.
At the same time, system design space exploration requires to apply separationof-concerns principles and to distinguish the application model from the architecture platform one. This approach requires that a deployment step maps software entities onto the hardware resources, statically or dynamically like for instance in the case of multi-processor scheduling decisions.
The aim of the paper is to propose a level of abstraction of the hardware for complex shared-memory multi-processor platforms. The section 1 focuses on the modeling of the processing resources based only on the functional point of view. The usefulness of such models are tested for the allocation of software entities on processors through deployment processes. The section 2 develops these descriptions to include memory hierarchy models, as a major structuring entities by considering the information ow into the system. In the next section, we apply those modeling guidelines to a real board. Hence, examples of tools that work or could work from the modeling level that we propose are given. Finally, after the description of related works, we conclude on some uncovered features of the hardware platform that could enrich our modeling guidelines. 1
When a hardware platform provides multiple execution units, the design process
must include an allocation or a placement strategy. The system model de nes
what software entities are assigned to hardware resources. Such assignments may
be done by the mean of a component-containment hierarchy[
The next two paragraphs illustrate the usage of binding properties for allocating tasks and logical partitions to processors.
Processing unit modeling and allocation In multi-processing systems, the
processing units may be implemented as a separated chip (a processor), or grouped
into a single chip (a core). Finally, the data path of a core or a processor may be
shared to execute concurrently several execution threads (physical threads)[
A way to model the system is to enumerate, at the same level, all the processing units without consideration of their actual implementation. The model of the Fig. 2 represents the available processing units of a PHM as arrays of AADL processors which group together those compatible with the same instruction set. processor i s a 1 end i s a 1 ; processor implementation i s a 1 . proc end i s a 1 . proc ; processor implementation i s a 1 . c o r e end i s a 1 . c o r e ; processor implementation i s a 1 . p h y s t h r e a d end i s a 1 . p h y s t h r e a d ; processor i s a 2 end i s a 2 ; system mpHardSystem end mpHardSystem ; system implementation mpHardSystem . impl subcomponents
PU isa1 : processor i s a 1 [N ] ;
PU isa2 : processor i s a 2 [M] ; end mpHardSystem . impl ;
The ability of this model to express the allocation of the hardware execution resources to the software tasks is shown Fig. 3.
A l l o w e d P r o c e s s o r B i n d i n g => ( r e f e r e n c e ( e x e c . PU isa1 ) )
applies to app . t h r s ;
A l l o w e d P r o c e s s o r B i n d i n g => ( r e f e r e n c e ( e x e c . PU isa2 ) )
applies to app . d e d i c a t e d T h r ;
A c t u a l P r o c e s s o r B i n d i n g => ( r e f e r e n c e ( e x e c . PU isa1 [
As the processing units of an array are homogeneous, all tasks, which are abstraction of executable codes for an ISA, can be allocated on all of them. The Allowed Processor Binding property expresses this in the model. Then, thee Actual Processor Binding properties allocate threads onto one or a set of processors.
Process and partition allocations The same basic principle of allocation schemes
can be applied to processes to de ne the visibility space of data in the context
of partitioned systems. On the model of the Fig. 4, a process part may be used
by two processing units following the operational mode: in normal mode, only
PU isa1[0] has the right to access it, whereas PU isa1[
A l l o w e d P r o c e s s o r B i n d i n g => (
r e f e r e n c e ( e x e c . p r o c U n i t s [ 0 ] ) , r e f e r e n c e ( e x e c . PU isa [
In [
At the hardware layer level, the architecture models enumerate the processing units as a " at" structure; they abstract multi-processing architectures as a set of available implementation-agnostic computing resources.
But a major problem with tightly coupled systems like shared-memory multiprocessors comes from the unexpressed sharing of resources at the level of memory hierarchy. Private cache memories locally separate the information ows near the processing units, but some parts of the memory hierarchy remain shared between processors.
The programming model of shared memory multiprocessor platforms allows communications of data or synchronizations between tasks through memory locations accesses. However, such a functional explicit sharing is generally secondary with respect to the sharing of the main memory banks and buses which provides all the memory words that the program execution requires.
For instance, [
So, an AADL model of shared memory multiprocessor systems must represent the resources shared by the processing units, especially if the software speci cation does not express this sharing as own. 2
The memory hierarchies can be complex subsystems, but they mostly expose, to the software, the interface of a simple memory3. Hence, designers must take attention to memory hierarchy as its non-functional characteristics are signi cant.
The guidelines we propose are based on the modeling of the memory hierarchy as a tree. The terminal nodes represent the processing units and the nodes abstract the di erent sub-parts of the memory system. A node of the memory hierarchy is characterized by the visibility of the memory words it contains; a node is shared by the same set of processing entities. Data exchanges within the memory hierarchy follow the paths of the tree.
The following rules may be applied to build the model: { The memory entities used by a same set of processing units are declared in a system component, as sub-components. If the memory entity is unique, a single memory component may be substituted to the system component. { A system component groups, as sub-components, a memory system, and the processors and upper level memory systems which share the access to this memory system. { For the sake of simplicity, levels of memory hierarchy connected to only one processor, i.e. processor's private caches, may be modeled as sub-components of this processor component. { The memory system associated to the root node contains at least a memory component representing the main memory. 3 We consider that the program or the operating system are aware of memory coherency problems.
When required for analyzing purposes, processors and composite memory components may detail their internal structure. AADL bus connection features can be used for that purpose. Information about the behavior of the each memory entities are given by AADL properties or AADL memory classi ers, for instance for distinguishing the main memory and the cache levels.
The Fig. 5 shows the modeling of the tree with a hierarchy of AADL components. The memories associated to the My sub-system are used or shared by Pj and Pk processors. Mx is the root memory system, including all the data that could be addressed in the physical address space. The Mx memory is shared by the Pi processor and My memory sub-system. As an example, we apply the guidelines that we propose on the processor of a VPX board from the company InterfaceConcept. The board VPX3a includes an Intel core i7, a FPGA Xilinx Kintex7 and an IO Bridge. The core i7 2566LE processor contains two cores, with an optional activation of multi-threading capabilities. Three levels of caches constitute the memory hierarchy; level 1 is composed of two separated caches for instructions and data, level 2 and 3 are uni ed ones. Only the level 3 of cache is shared between cores.
The Fig. 6 shows an high level model of the hardware architecture for the VPX3a board, with emphasis on the processing units and the memory hierarchy. We assume that the hyper-threading is enabled on the core number two.
The Fig. 7 and 8 show the structure of the memory hierarchy nodes. AADL bus connections have been used to model the internal hierarchy of the implementation L1I L1D L2 of mem system. A similar modeling method can be applied to the other memory systems.
Notice that the cache sharing may change during the design process, even on a given execution platform. The activation of the multi-threading on a core or system implementation exec . IC INT VPX3a subcomponents c o r e 1 : processor I n t e l 6 4 . c o r e s i n g l e t h r e a d ; c o r e 2 : system I n t e l 6 4 . c o r e d u a l t h r e a d ; mem : memory mem system . L3 main ; end exec . IC INT VPx3a ; system implementation I n t e l 6 4 . c o r e d u a l t h r e a d ; subcomponents pth1 : processor I n t e l 6 4 . p h y s i c a l t h r e a d ; pth2 : processor I n t e l 6 4 . p h y s i c a l t h r e a d ; mem : memory mem system . L1I L1D L2 ; end I n t e l 6 4 . c o r e d u a l t h r e a d ; the operating system enabling of a level of cache are examples of modi cations that a designer could do to explore their impact on the system performance. If such situations may exist, the component hierarchy can contain "potentially shared" nodes in the tree, currently used by only one processing unit. 4
As shared-memory multiprocessor platforms become more complex and widely used, designers of real-time systems need to have access to analysis tools in order to assess their choices or dimension their systems. Such tools must work from an architectural model of the execution platform; we think that the modeling guidelines presented in this article set up a right level of abstraction for this purpose. These AADL models may be used directly as a tool entry or as a source for a model transform whether the tool uses a DSL language.
In the sequel, we give examples of tools which are or could able to handle models compliant with the guidelines proposed in this article.
Scheduling analysis AADL Inspector from Ellidiss Technologies is a lightweight
framework allowing to apply di erent analysis on AADL models. One of the
analysis tools available with AADL Inspector is Cheddar[
Resource allocations The placement of software entities on hardware resources
may be complex if the number of tasks or virtual processors is high. The use of
optimization methods are sometimes necessary to perform these allocations. For
instance, Cheddar implements basic partitioning algorithms such as
RM-BestFit [
From an AADL model, Allowed Processor Binding can be used to supply the set of candidate resources and allocation targets (e.g. processors). The results of partitioning algorithms can then be expressed on the analyzed AADL model by updating its Actual Processor Binding properties. AADL Inspector will integrate such a function in its future releases.
Timing analysis In [
Then, the analysis assumes that all the possible con icts happen with the other processors for the shared cache usage. From this pessimistic analysis, the worst case response times of all the tasks are computed, and the interferences previously considered are kept if the task's running times intersect. This process is recurrently performed upto a x point is reached.
These examples of tools and analysis show the interest of modeling multiprocessing platform and their memory hierarchy, as many analysis can be conducted from that kind of models. 5
We describe in this section other modeling approaches used to guide performance analysis on shared-memory multiprocessor systems.
In [
In the context of shared-memory multiprocessors, [
The modeling of multicore execution platforms with Simulink has been
proposed by [
This article presents an approach for modeling shared-memory multiprocessor platforms. Basic entities that we have emphasized in this high-level model, are the processing units, whereas the way they are implemented, and the di erent levels of the memory hierarchy. We expect the architecture of the memory subsystem is a key feature to perform timing analysis on multi-processing platforms.
The memory hierarchy is not the only challenge in the timing analysis on multiprocessor platforms. Another topic is the multiplication of interconnection buses, with various characteristics in term of throughput and latency. Multiprocessor SoCs use the capabilities of integrated circuit to implement a lot of buses to connect the di erent functions available on the chip. One goal devoted to the architectural models will be to document this structure, and guide tools and designers to identify potential bottlenecks.
Another problem is to deal with PHMs. SoCs mix di erent types of processors, with di erent speeds or capabilities. How AADL models can represent all these types of information must be investigated.
Acknowledgments This work is done in the context of the SMART project. SMART and Cheddar are supported by the Conseil Regional de Bretagne, Bpifrance, Conseil General du Finistere and BMO. Cheddar is also supported by Ellidiss Technologies, EGIDE/PESSOA n. 27380SA and Thales TCS.