Using an MDE Approach for Modeling of Interconnection ... - CiteSeerX

Using an MDE Approach for Modeling of Interconnection Networks Imran-Rafiq Quadri, Pierre Boulet, Samy Meftali and Jean-Luc Dekeyser INRIA LILLE NORD EUROPE - LIFL - CNRS - USTL, France [email protected]

Abstract As System-on-Chip (SoCs) become more complex, high performance interconnection mediums are required to handle their complexity. Network-on-Chips (NoCs) enable integration of more Intellectual Properties (IPs) into the SoC with increased performance. In the recent MARTE (Modeling and Analysis of Real-time and Embedded Systems) Profile, a notion of multidimensional multiplicity has been proposed to model repetitive structures and topologies. This paper presents a modeling methodology based on that notation to model the Delta Network family of Interconnection Networks for NoC construction. Keywords: SoC, NoC, MINs, Delta Networks, MARTE, MDE, UML 2 Templates

1

Introduction

With simultaneous increase in performance and miniaturization of integrated circuits, SoCs are becoming more complex. Complexity of their Interconnection Networks (INs) is important as the problems linked to the propagation delays in INs are amplified by the reduction of the technological dimensions. Network-on-Chips (NoCs) [9] are thus considered a solution for these problems. They are a layered approach of communication similar to the INs [18] (for connecting large number of computers on a wide-area) but used for on-chip communications. Reusability of communication networks and resources (processors, memories, switches, etc.) is an important advantage of NoCs. NoCs undeniably incur a significant change in the SoC architecture and improve the design productivity of these complex systems. Model Driven Engineering (MDE) [16] is concerned with the development of standards and technologies to support the design of model based systems. The recent UML Profile for Modeling and Analysis of Real-time and Embedded Systems (MARTE) [10] is intended for SoC codesign. It describes the notion of Multidimensional Mul-

tiplicity which was first proposed in [6] and is the basis of our GASPARD Environment. The GASPARD (Graphical Array Specification for Parallel and Distributed Computing) co-design environment is an Integrated Development Environment (IDE) for visual co-modeling of SoCs. It is oriented towards parallel hardware and software co-design and exploits the parallelism included in repetitive constructions of hardware elements or regular constructions such as application loops. Our contribution is to introduce the notion of templates in the GASPARD environment allowing creation of parametrable components to aid in the modeling of INs, specifically Multistage Interconnection Networks (MINs). We extended the current UML 2 specifications and introduced certain new notions related to templates. Port multiplicity of template components is given by template parameters for specification of templates. A recursive approach is also used for the modeling aspect. Finally, these concepts allow to model the Delta Networks [14],[15] family of MINs. This family has been choosen due to its repetitive regular and scalable nature which complies with the underlying methodology of GASPARD [3]. However, this approach can be extended for modeling of all families of INs having aspects of repetitive regular construction. The plan of this paper is as follows: section 2 briefly explains the GASPARD environment. We then recall some basics of MINs and Delta networks. The UML 2 template mechanism and our extension is presented in section 4. Section 5 illustrates the modeling of Delta networks before the last section where we conclude our work.

2

GASPARD Environment

GASPARD [4],[21] is a co-modeling environment for designing massively parallel SoCs based on a model driven methodology and a subset of the MARTE Profile [5],[10]. It uses the ARRAY-OL [3] concepts to express parallelism and has a UML profile for designers to model both massively parallel applications and their architectures. An association mechanism then links the two aspects together with a set of transformations for simulation and synthesis. Us-

ing its underlying concepts, GASPARD analyzes and transforms the models to generate different programming languages that allow simulation, execution or synthesis of an application mapped onto an architecture. Detailed presentations and demos of the GASPARD environment can be found in [8].

3

Multistage Interconnection Networks

Interconnection Networks [18] are a balance between complex crossbar networks and the non scalable bus architectures in terms of complexity, scalability, fault tolerance and cost. They are classified as Static, Dynamic or hybrid networks. Multistage Interconnection Networks (MINs) classified as Dynamic Networks are used to interconnect a set of N input nodes to M output nodes. In MINs, the input and output nodes (usually processors and/or memories) are connected via a number of intermediate stages of switching elements (SEs) followed (or leaded) by interconnection links. The most commonly used SEs are hyperbars and specifically crossbars. The SEs in MINs may or may not have input and/or output buffers. This paper deals only with MINs in their simplest configuration (without buffers). The size of a MIN is the number of its inputs and outputs where as the degree of a MIN is defined as the size of the SEs used to build it [2]. In [2], MINs are classified as Uniform, Rectangular or Square on the basis of their topology. A Uniform MIN is one in which all SEs of a stage are of the same degree. A Rectangular MIN has the same number of inputs and outputs while a Square MIN is one having a degree r built from SEs of size r. Depending on the types of switches, they can be either Unidirectional or Bidirectional in nature. A MIN having a unique path between every input/output node pair is called a Banyan Network [7].

3.1

Delta Networks

Delta Networks, first proposed by Patel [14],[15] form a subset of Banyan Networks. Every Delta network is a Banyan network while the reverse is not always true. Delta networks have a routing property called Self Routing Property or Delta Property. As we focus on MINs of a repetitive regular nature, we focus only on unidirectional DSUB (Delta, Square, Uniform, Banyan) networks. This is because these types of networks have a repetitive regular and scalable architecture complying with the rules of GASPARD. A DSUB network is a Delta network with all SEs of the same size. Normally, DSUB networks are constructed using crossbars of size based on powers of 2, however this is not a restriction. In the paper, we focus primary on the Delta networks constructed with SEs of size 2 × 2. Further details about these networks can be found in [17]. Although various types of Delta MINs exist (Omega, Flip and etc.);

for the sake of the paper, we only discuss the Butterfly networks. However all the popular types can be modeled with our methodology as shown in [17]. Except Omega and its reverse network, all other Delta networks are built using recursive composition as shown in figure.1. For a Delta network of size N × N, the first stage has Nk crossbars and 2 smaller Delta networks of size N2 . Figure.2 shows the recursive nature of a Butterfly (8,2) network. Butterfly (8,2) means a Butterfly network of size 8 and degree 2. Here, the first stage of a Butterfly (8,2) network has N2 = 4 SEs followed by two smaller Butterfly networks of size 4 × 4. Stages of Interconnection wires

C0

C1

2x2 N ports

Cn

N/2xN/2 N

N/2

ports

2x2

Processors

N/2xN/2

Memory Modules

Figure 1. Recursive composition of Delta Networks

Figure 2. A Butterfly (8,2) Network

4

UML 2 Templates

Templates are used for generic programming in many different application areas especially programming languages such as C++ templates [19]. In the UML 2 Standard [13], a template is a model element parameterized by other model elements. These parameterizable elements can be classifiers, packages or operations. Classifier and package template elements are respectively called Classifier Templates and Package Templates. For parameterization specification, a template element owns a Template Signature relating to a list of formal Template Parameters where each parameter chooses an element that is part of the template. Using the Template Binding relationship, a template can create other model elements. This binding relationship links a ”bound” element to the signature of a target template causing a set of template parameter substitutions in which formal template parameters are replaced by actual parameters. Also a template cannot be instantiated and is an abstract form; but when a template is made concrete by means of the template binding relationship, the bound element (if not a template itself) can be instantiated.

4.1

Component Templates

While [1],[20] do use the component template concept to some extent, there is a lack of references related to component templates. Usage of template parameter of a component template for expressing port multiplicity has not been considered before. For modeling of MINs, we haved used component templates. Port multiplicity of the component template ports is associated with the template parameter specified in the component template and depends on the actual value of the template paramater upon substitution during binding. Figure.3 shows the schematic of a component template. This construction is possible as a port is defined as Structural Feature of an Encapsulated Classifier. An encapsulated classifier extends a classifier enabling it to own ports in its specification. Also only classes and components can contain the ports. We now focus only on components. Ports are structural features of a component and help to define the specification of a component or its instances. As a template parameter is used in the namespace of a template element, it can be used anywhere in the specification of a template element, making it possible to use the template parameter with ports of the component template so that when a template parameter is given a value for the parameter, the ports acquire a specific multiplicity depending on the value of the actual parameter. By using component templates and template binding, we can create different component types with the necessary multiplicity on their ports. These component types can be instantiated in turn. We assume that we can create different component types from a component template having similar names after the template binding but with different values for the template parameter because as described in UML 2 standard specifications, a bound element can have multiple bindings to the same template. The different bindings are evaluated in isolation and produce intermediate results, which merge to produce the final result.

Figure 3. Example of a Component Template

4.2

Nested Templates

In UML, nested templates are only defined expressively for packages. While a package template may contain another nested package template, nested classifier templates are not addressed in UML 2 but present in languages like

C++ [11]. We address this problem and give a solution for using nested classifier templates. We first recall anonymous bound classifiers as defined in UML 2. Figure.4 shows a class template FArray, with two template parameters T and k. The second parameter k has a template signature with a default value set to 10. The square box below the class template is an alternative to show the template binding relationship. As shown, the class template has not been renamed in the template binding and an anonymous bound class(ifier) having the same name FArray as the class template is used. The template parameter T is replaced for the Point class. As k is not substituted, the default value (10) is used. This anonymous bound class is a type of a typed element and can be instantiated. This methodology resembles the use of templates (or generics) in languages like C++. In C++, when a class template is specified, it is assigned a name for its definition and is made concrete by using the same name as the abstract template with an actual value for the template parameter (and its type declaration) followed by name of an instance. So a new class type (bound class) is created and the instance is of this class. The bound class is in fact an anonymous bound class as described in UML 2. We use this concept to create nested component templates. However, as nested classifier templates are not specified in the UML 2 standard, we propose a new semantic to address this problem.

Figure 4. An Anonymous Bound Classifier In figure.5, two template components A and B are shoown. A contains B as part of its specification (part b). B is shown separately to give an idea of its underlying semantics. The part b contained within A shows the new semantics. The notation < N → N > written with b is to represent the template binding mechanism for nested templates where the template parameter N (at left side of the notation) of B is replaced by actual value of the template parameter N (at right side of the notation) of A. So using this notation, a bound component with same name as B is created with port multiplicities equal to the value of template parameter of A. It is clear that this bound component is an anonymous bound component and can have potential instances as shown from part b. Using the template binding for A, a value of 8 is given to N to create an anonymous bound component with the same name and concretizes its internal structure. We also assume that a template can be used in the specifications of a non templateable element.

5

Figure 5. Binding notation for Nested Templates

4.3

Nested Templates and Recursion

As nearly all Delta networks are built with recursive composition, we need to use generic components with recursive characteristics to model them. We thus specify use of recursion using nested templates. Figure.6 shows the details of nested recursive templates. In the same manner as described before, component template A contains the nested component template B as part of its specification. For recursion to take place, template B itself contains template A as part of its own specification with the difference that in the binding relationship specified for A inside B, the value for the template parameter N of A is set to N2 of B. The port multiplicities also change due to the binding mechanism.

Figure 6. Nested Recursive Template components If N of B is given a value of 8 for example, due to binding, template A is concretized as an anonymous bound component and the ports of part a get a multiplicity of N2 . The difference between the anonymous bound component with template parameter N and the new anonymous bound component with template parameter N = N2 is that they represent two different component types with different values of N; each having their respective port multiplicities. These are intermediate results leading to a final result when the recursion should stop but as this recursion is infinite in nature, we need to avoid infinite recursion and to stop the recursion at a desired level. For this we use OCL constraints [12]. OCL (Object Constraint Language) is a language for describing rules for UML models and provides object query expressions and constraints not expressed by UML diagrams. By using these OCL constraints, we control the recursion by manipulating the connectors present in our methodology. This approach has also been used in [1] for the creation of a generic shift register. This feature allows us to avoid the infinite recursion trap.

Modeling of Multistage Interconnection Networks

For modeling of Butterfly networks of Delta networks family, an important aspect is that the interconnection links in these networks are different between the stages of the SEs except the links attached to the sources and the destinations. As shown in figure.2, Butterfly networks are recursively composed. Using the concepts of GASPARD, the Butterfly permutation pattern of the interconnecting wires of the Butterfly networks were fist generalized in [17] with concepts of Reshape and Tiler connectors [5] present in the GASPARD profile. The Tiler connector is used to define a repetitive link between two components and has origin, paving, and fitting attributes for specifying Array-OL information for processing input and output patterns. The Reshape link is used to specify the redistribution/reorganization of some array elements on another array. It contains two tilers at each connector end along with two additional attributes: patternShape and repetitionSpace representing respectively the pattern of used arrays, and its repetition space. Detailed semantics about these concepts can be found in [5] and [10]. For the modeling, we break the network into several GASPARD components. All components described here are template components except the Crossbar2x2 component. We use a bottom to top approach for the explaination. All components have a HW Communication stereotype defined in MARTE [10]. The first component Crossbar2x2 represents a crossbar of size 2 × 2 shown in figure.7 consisting of input port init{2} and output port target{2} where the port multiplicities indicates the number of inputs and outputs for the Crossbar2x2. Escalating to a higher level, we define a template component FirstStage in figure.8 representing first stage of a Butterfly network. It has a template parameter N of integer type and has its respective init and target ports with multiplicities set to N. Crossbar2x2

init [{2}]

target [{2}]

Figure 7. A Crossbar2x2 component The FirstStage component has part xbar of type Crossbar2x2 with multiplicity equal to N2 . This multiplicity shows number of crossbars in the first stage of a Butterfly network. Thus if N = 8, the FirstStage component contains 4 repetitions of a crossbar. The FirstStage component also has two Tiler connectors, their tagged values corresponding to a straight link from init{N} and target{N} ports of the FirstStage component to the init{2} and target{2} ports of Crossbar2x2. In figure.9, at the next higher level, we define a template

component NextStage with a template parameter N of integer type with respective init and target ports. NextStage contains part Recursive of type ButterflyBlock (described at a higher level of hierarchy) with multiplicity of 2. It should be noted that template binding has been specified with the part Recursive with the notation < N → N2 > enabling it to have port multiplicities set to one half as given to NextStage. The NextStage component also has two Tiler connectors, their tagged values corresponding to a straight connection from the init{N} and target{N} ports of the NextStage to the init{N} and target{N} ports of one repetition of ButterflyBlock component.

ports of the ButterflyBlock to the init{2} ports of the part XbarA, and defines a direct connection. The fifth reshape connector (Reshape 5) is connected from the target{2} ports of the part XbarA to the target{N} ports of the ButterflyBlock, and also defines a direct connection. We also specify a set of OCL constraints for ButterflyBlock, which basically help to stop the recursion, as described earlier in the paper. The OCL constraints state that the actual value of the template parameter N should always be greater than or equal to 2. The Reshape connectors 1, 2 and 3 along with parts First and Next, exist only for a value of N ≥ 2. When the value of N is 2, only the Reshape connectors 4, 5 and part XbarA exist causing the recursion to stop.

N : int FirstStage

N : int ButterflyBlock

init [{2}]

xbar : Crossbar2x2 [{N/2}]

target [{2}]

init [{N}]

{fitting = "{1}" , origin = "{0}" , paving = "2" }

{fitting = "{1}" , origin = "{0}" , paving = "{2}" }

{fitting = "{}" , {fitting = "{}" , origin = "{0}" , {patternShape = "{1}" , origin = "{0}" , paving = "{1}" } repetitionSpace = "{N}" } paving = "{1}" }

target [{N}] init [(N)]

Figure 8. A FirstStage Template Component

{fitting = "{0,1}" , origin = "{0,0}" , paving = "{1,0},{N/4,0}" }

1 init [{N}]

First : FirstStageN>

{patternShape = "{2}" , repetitionSpace = "{N/4,2}"

}

{fitting = "{N/4,0}" , origin = "{0,0}" , paving = "{1,0},{0,1}" }

2

target [{N}]

init [{N}]

{fitting = "{}" , origin = "{0}" , paving = "{1}" }

Next : NextStageN>


{patternShape = "{1}" , repetitionSpace = "{N}" }

{fitting = "{}" , origin = "{0}" , paving = "{1}" }

3

target [{N}]


4

init [{2}]

XbarA : Crossbar2x2

target [{2}]

5

target [{N}] N : int

Inv:If(self.N>2) then (self.part.oclIsTypeOf(FirstStage)−>size()=1 and (self.part.oclIsTypeOf(NextStage)−>size()=1 and self.ownedconnectorname=’1’ and self.ownedconnectorname=’2’ and self.ownedconnectorname=’3’) else If(self.N=2) then (self.part.oclIsTypeOf(Crossbar2x2)−>size()=1 and self.ownedconnector.name=’4’ and sef.ownedconnector.name=’5’)

NextStage

init [{N}]

init [{N/2}]

{fitting = "{1}" , origin = "{0}" , paving = "{N/2}" }

Recursive : ButterflyBlockN/2> [{2}]

target [{N/2}]

{fitting = "{1}" , origin = "{0}" , paving = "{N/2}" }

target [{N}]

Figure 10. Modeling of a ButterflyBlock Template Component

Figure 9. A NextStage Template Component N : int

Ascending to another level in figure.10, we define the template component ButterflyBlock with template parameter N of integer type and respective init and target ports. ButterflyBlock contains part First, Next and XbarA of component types FirstStage, NextStage and Crossbar2x2 respectively. Both parts First and Next have the template binding notation assigned to them. For both, the notation is < N → N >. This means that when an actual value for template parameter N of ButterflyBlock is specified, the parts acquire the same value on their ports. For ButterflyBlock, we also define five Reshape connectors and name them respectively. The naming is done to remove ambiguity for OCL constraints. The first reshape connector (Reshape 1) is connected from init{N} ports of ButterflyBlock to the init{N} ports of part First, and defines a direct connection or no permutation. The second reshape connector (Reshape 2) is connected from the target{N} ports of part First to the init{N} ports of part Next. This connector defines the Butterfly interconnection pattern for a value corresponding to N. The third reshape connector (Reshape 3) is connected from target{N} ports of part Next to the target{N} ports of the ButterflyBlock, and also defines a direct connection. The fourth reshape connector (Reshape 4) is connected from the init{N}

ButterflyNetwork


init [{N}]

init [{N}]


ButBlock : ButterflyBlockN>

target [{N}]

target [{N}]

Figure 11. Modeling of a ButterflyNetwork Template Component

Finally in figure.11, we define the template component ButterflyNetwork with template parameter N of integer type and its respective init and target ports with multiplicities set to N. It has a part ButBlock of the component type ButterflyBlock having the binding notation set to < N → N >. Thus when an actual value for N is specified for ButterflyNetwork, the part Butblock acquires this value on its ports as their multiplicity. In order to completely specify the topology, ButterflyNetwork uses two reshape connectors. The first reshape connector connects the init{N} ports of the ButterflyNet-

work to init{N} ports of part ButBlock. This reshape connector specifies the first interconnection pattern from the sources to the first stage of a Butterfly network. The second reshape connector connects the target{N} ports of part ButBlock to the target{N} ports of the ButterflyNetwork. This reshape connector defines the last interconnection pattern from the last stage of a Butterfly network to the destinations. Due to space limitations, The visibility of the diagrams has been comprised. A detailed summary of the modeling process and clear visibility of the diagrams is presented in [17]. Figure.12 shows a simplified overall view of the above mentioned semantics for a Butterfly (8,2) network.

Figure 12. Simplified Butterfly (8,2) Network

6

Conclusion

We have first given the basic definitions of MINs and Delta networks and then have proposed a methodology to model the Delta networks family. These networks and more specifically DSUB networks are chosen due to their scalable regular repetitive nature in accordance with the underlying semantics of GASPARD. For a generic modeling methodology adaptable to all Delta networks, we created parametrable components to aid in the modeling. We have explored and extended the notion of UML templates and proposed the notion of component templates, nested component templates and the template binding notation for nested templates along with an alternative approach for template binding specification as described in the current standard. Finally, a recursive approach is also used to ease generation of certain type of Delta networks. Now, all popular DSUB networks constructed from crossbars of size 2 × 2 can be modeled. This modeling methodology can be extended to include DSUB networks constructed from crossbars of different sizes based on the function of powers of 2. Future works would include modeling of other network topologies having repetitive regular characteristics such as mesh networks along with a path to the lower level specifications and transformations in the lower level descriptions of the GASPARD chain for the simulation of these and other NoCs.

References [1] A UML Profile for SOC Specification, 2006. [2] A. Aljundi. Une Méthodologie Multi-Critères Pour ´ l’Evaluation de Performance Appliquée aux Architectures ´ de Réseaux d’Interconnexion Multi-Etages. PhD thesis, USTL, LIFL, July 2004. (In French). [3] P. Boulet. Array-OL revisited, multidimensional intensive signal processing specification. Research Report RR-6113, INRIA, Feb. 2007. [4] P. Boulet, C. Dumoulin, and A. Honore. From MDD concepts to experiments and illustrations, chapter Model Driven Engineering for System-on-Chip Design. ISTE, 2006. ´ [5] P. Boulet, P. Marquet, Eric Piel, and J. Taillard. Repetitive Allocation Modeling with MARTE. In FDL’07, Barcelona, Spain, Sept. 2007. [6] A. Cuccuru. Modélisation unifiée des aspects répétitifs dans la conception conjointe logicielle/matérielle des systèmes sur puce a` hautes performances. PhD thesis, USTL, LIFL, Nov. 2005. [7] G. Goke and G. Lipovski. Banyan networks for partitioning multiprocessor systems. In Proc. 1st Annu. Symp. Comput. Arch., pages 21–28, 1973. [8] INRIA. DaRT short presentations and demos. 2007. [9] A. Jantsch and H. Tenhunen. Networks on chip. Kluwer Academic Publishers, 2003. [10] L. Rioux et al. MARTE: A new profile RFP for the modeling and analysis of real-time embedded systems. In UMLSoC’05, Anaheim, CA, June 2005. [11] MSDN. Visual C++ Language Reference:Nested Class Templates. http://msdn2.microsoft.com/en-us/ library/71dw8xzh.aspx, 2006. [12] Object Management Group, Inc. OCL 2.0 specification, version 2.0. http://www.omg.org/docs/ptc/05-06-06. pdf, June 2005. [13] Object Management Group, Inc., editor. UML 2 Superstructure (Available Specification). http://www.omg.org/ cgi-bin/doc?formal/05-07-04, Aug. 2005. [14] J. Patel. Processor-memory interconnections for multiprocessors. In Proc. 6th Annu. Symp. on Comput. Arch. Newyork, pages 168–177, 1979. [15] J. Patel. Performance of processor-memory interconnections for multiprocessors. IEEE. Trans. Comput., C-30(10):771– 780, Oct. 1981. [16] Planet MDE. Model Driven Engineering. http:// planetmde.org/, 2007. [17] I. Quadri, P. Boulet, and J. Dekeyser. Modeling of topologies of interconnection networks based on multidimensional multiplicity. Research Report RR-6201, INRIA, May 2007. [18] I. D. Scherson and A. S. Youssef. Interconnection Networks for High-Performance Parallel Computers. IEEE computer society press, 1994. [19] B. Stroustrup, editor. The C++ Programming Language. Addison-Wesley Publishing Company, 1991. [20] M. Tichy, B. Becker, and H. Giese. Component Templates for Dependable RealTime Systems. Sept. 2004. [21] WEST Team LIFL, Lille, France. Graphical array specification for parallel and distributed computing (GASPARD-2). http://www.lifl.fr/west/gaspard/, 2005.