Synthesis of UML-Models for Reconfigurable Hardware

Synthesis of UML-Models for Reconfigurable Hardware Christina Dorotska, Dominik Fröhlich, and Bernd Steinbach $EVWUDFW -,Q WKLV SDSHU ZH SUHVHQW DQ DSSURDFK WKDW DOORZV IRU FRPSOHWH SUHFLVH DQG REMHFWRULHQWHG VSHFLILFDWLRQRIKDUGZDUHVRIWZDUHV\VWHPVXVLQJ80/ DQG LWV DXWRPDWHG FRPSLODWLRQ LQWR D GLUHFWO\ H[HFXWDEOH DSSOLFDWLRQFRPSULVLQJKDUGZDUHDQGVRIWZDUHPRGXOHV$ 80/ PRGHO FRPSLOHU IRU UHFRQILJXUDEOH DUFKLWHFWXUHV 02&&$ LPSOHPHQWV RXU PHWKRGRORJ\ DQG SHUIRUPV YDOLGDWLRQPDSSLQJDQGDSSOLFDWLRQV\QWKHVLV.H\ZRUGV - 8QLILHG 0RGHOLQJ /DQJXDJH 80/ 5XQ WLPH UHFRQILJXUDEOH +DUGZDUH 575 0RGHO 'ULYHQ $UFKLWHFWXUH0'$6\VWHPRQ&KLS6R&)3*$)60 I. INTRODUCTION The tremendous technological progress in microelectronic industry during the past decades offers a steadily increasing amount of hardware resources. However, the amount of resources that can be actually used for the realization of applications is only a small portion of the available resources, which is called the design gap. The growing complexity of designs and the shortage in time-to-market, demands for novel development approaches to be able to address problems like verification, synthesis and test with reasonable effort. In the recent years there is a strong trend toward the adaptation of methods, languages and tools used in the software domain, for the computer-aided development (CAD) of hardware and mixed hardware/software systems. In contrast to the various programming-languages based approaches, like SystemC, SpecC and SPARK [4][3][6], the development of hardware/software system with the Unified Modeling Language (UML) has recently turned out to be a very promising direction to address the current problems. However, the most of the current UML-based development efforts have a strong focus on software. Problems like design space exploration, hardware/software synthesis, estimation and verification are not sufficiently addressed. Thus our recent research focuses on the complete, precise and object-oriented specification of computationally intensive applications with UML and MAL (MOCCA Action Language) [1]. The approach is supported by the MOCCA-compiler (Model Compiler for reconfigurable Architectures), which allows for the automated compilation of such specifications into directly executable hardware/software solutions. The targeted hardware architectures comprise of classical microprocessors and reconfigurable hardware resources, like field-programmable gate arrays (FPGA). Our development methodology incorporates model-driven architecture, platform-based design and hardware/software co-design [1]. In this paper we introduce a novel approach for the synthesis of reconfigurable hardware from UML models. The presented approach enables the synthesis of object-oriented specifications into hardware circuits. The model of computation is objects communicating by structured messages. The key concepts of object-orientation - inheritance, polymorphism, encapsulation and information hiding - are supported. The approach is applicable for stand-alone hardware synthesis and hardware/software co-synthesis environments. It is the first approach that enables the entire realization of object-oriented specification, and thus avoids the archetypal break in paradigms, languages and tools of current object-oriented hardware development efforts. The rest of this paper is organized as follows. In the first part we give some basic knowledge s about modeling of object oriented software with UML and introduce briefly into our development approach. We also describe the relationships between used application models and platform models. The next chapter is devoted the synthesis of software implementation. Then we present a logical hardware/software interface of objects and components and theirs life-cycles. Concrete implementation options for hardware-objects and components are presented in the last part of this paper. A concrete example for the synthesis approach is used. Finally the paper is concluded. II. FUNDAMENTALS 80/ UML is a universal description language for all kinds of object-oriented software [7]. The statically aspects of a device are described by various structural diagrams, such as class diagrams, component diagrams and deployment diagrams and, for dynamic behavior are used behavioral diagrams, such as activity diagrams, sequence diagrams, and state machine diagrams. In this paper we use in the UML model the diagrams which describe the system structure of a TVL-Processor example (Fig.1). With this simple application can be checked whether a list of ternary vectors is orthogonal. Fig.1 Class diagram for example design model.

The behavior of this application is presented by the operations which are detailed described with MOCCA action language. A class diagram models the class structure and displays relationships such as containment, inheritance, associations and others. A rectangle represents in a class diagram a class (Fig. 1). There are three parts in a rectangle of a class. The name of the class is located on top; the middle part shows the attributes and the lower part the operations of the class. Fig.2 Class diagram for design platform model. The association relationship is the most common relationship in a class diagram. The association expresses the collaboration between instances of classes. For example, the class Main is associated with the class TVL-Processor. Another common relationship in class diagrams is a generalization. A generalization relationship between two classes means that one class inherits the attributes and operations of another one. For example, the class object in the Fig. 2 is the base class for the classes ERROHDQ, ELW, UHPRWH, WLPH, VWULQJ, FKDU and for the class REMHFW>@ that presents an array. Deployment diagrams show the physical layout of a system, revealing which pieces of software run on what pieces of hardware [8]. The main items of the diagram are nodes connected by communication path (Fig. 3). A node represents a piece of hardware and can host some software. The nodes contain or deploy artifacts, which are physical manifestations of software, usually files. In the Fig. 3 the node h0 represents a microprocessor and deploy in runtime the artifact tvlprocessor.exe. An artifact is also used to represent a concrete instance of a component. For example the artifact HWTestComp.bit represents an instance of the component HWTestComp and was deployed in the node FPGA. A dependency in the UML is represented with a dotted arrow Fig.3 Implementation and Deployment Model for example design model. and exists between two elements, if changes to the definition of one element may cause changes to the other. By the «realize» dependency the source is an implementation of a specification defined by the target. 'HYHORSPHQW0HWKRGRORJ\ In this part the brief overview of the development approach is given. Figure 4 shows the basic activities and artifacts of our development approach. The illustrated approach incorporates the general methodology of software/hardware co-design into the concept of Model Driven Architecture (MDA) [2]. In our approach the design of the application is represented with an object-oriented system level UML-model (Fig.1). As basis for design model we use the design platform, which is described by a set of types and constraints (Fig.2). The definition of functions, structure and behavior of the objects is captured in a platform independent design model (PIM). The target platform (TPM) model specifies all information necessary for platform mapping and synthesis. The TPM describes the architecture of the target hardware also as UML model. Thereby we specify hardware nodes, like reconfigurable devices and microprocessors, their communication path, and the capabilities that these components provide for application implementation (Fig.3). By mapping the application to the target hardware system structure we perform the transformation of PIM to platform specific model (PSM). If the implementation requires additional operating system support, e.g. for inter-object synchronization and communication, the according elements of the PIM are bound to the resources provided by the respective target platform devices. The final step of the development process is synthesis. Given a platform specific model of our application we proceed by transforming it into an implementation model which is finally synthesized into a ready-to-run implementation. For the functionality deployed on micro-processors we generate executable software modules; the functionality that will be executed on reconfigurable logic respective hardware modules is generated.

6\VWHP6SHFLILFDWLRQ 'HVLJQ3ODWIRUP0RGHO 3ODWIRUP,QGHSHQGHQW0RGHO 7DUJHW3ODWIRUP0RGHO 'HVLJQ0RGHO,PSOHPHQWDWLRQ 3ODWIRUP0RGHO +DUGZDUH 3ODWIRUP0RGHO 9DOLGDWLRQ6LPXODWLRQ (VWLPDWLRQ2SWLPL]DWLRQ 3ODWIRUP0DSSLQJ 3ODWIRUP6SHFLILF/LEUDULHV 3ODWIRUP6SHFLILF0RGHO,PSOHPHQWDWLRQ 0RGHO 'HSOR\PHQW 0RGHO 6\QWKHVLV,PSOHPHQWDWLRQ/DQJXDJH0DSSLQJ 3DWWHUQV5XOHV 3ODWIRUP'HSHQGHQW$SSOLFDWLRQ ([HFXWDEOH +DUGZDUH &RQILJXUDWLRQV Fig.4 Development Methodology - Activities and Artifacts. Ã 3ODWIRUPVDQG0RGHOV The development of applications is based on platforms, whereas different platforms for design, implementation and deployment are used [5]. Thereby a strict separation of development concerns is accomplished. Moreover this approach eases validation, portability, adaptability and reuse. Platforms have been used ever since in the areas of software and hardware development. However, platforms are mostly captured implicitly in language reference manuals, libraries and tools, which hamper their automated interpretation by computers. Platforms represent sets of assumptions that are the foundation of any development effort. In the presented approach these assumptions are made explicit with platform models, whereas each platform is specified with a dedicated UML model. Platform models abstract from the details of the described platform but carry enough information to avoid Fig.5 Relationships between models. iterations in the design flow. They are the basis for the definition of application models that describe a certain aspect of the system under development. The relationship between the platform models and application models is illustrated in Figure 5. The platform models below the horizontal line define the space of applications that may be developed with the respective platforms. Above the line the models defining a concrete application, and hence representing a point in the application space are depicted. Platform models are normally shared by different application models. III. SOFTWARE IMPLEMENTATION In the previous section we briefly presented our development approach and the relationships between application and platform models. In this section we will present an object-oriented approach to synthesis of software from UML models. The classes of the implementation model being deployed on microprocessor nodes are directly implemented in C++. The communication between local and remote objects is managed by local proxy objects. For each remote object that is accessed by a local object a proxy is instantiated locally. The proxy encapsulates the communication mechanism. Thus the objects of an application are not required to share a common address space. The proxy is explicitly modeled in the implementation

platform model as remote type (see Fig. 2). This allows the model compiler for high quality estimates of the characteristics of distributed applications. Objects that are realized in reconfigurable hardware are managed by a dedicated service called RTR-Manager [1]. This manager encapsulates the specifics of the reconfigurable hardware, e.g. reconfiguration modes, input/output functions and communication. The most important task of this service is to process application requests for the creation and destruction of hardware objects. Hardware objects are created and destroyed on demand. An application that instantiates a hardware object requests it from the RTR-Manager by its type. The RTR-Manager searches for a suitable object in the currently instantiated bitstreams and serves its proxy to the application. If no bitstream contains an object of the searched type is currently instantiated, the RTR-Manager dynamically instantiates an appropriate bit-stream. Fig.6 Software Architecture of TVL-Processor Example Figure 6 illustrates the principal architecture of the TVL- Processor example. The instance main of class Main and a proxy for hardware object are implemented in software. The actual instance of class TVLProcessor is realized with reconfigurable resources. The hardware object is accessed from software through a dedicated proxy. The proxy is served to the application by an instance of the RTR-Manager service. Proxies can be used directly in the software implementation to provide a simple yet fast mechanism to access the represented hardware objects. Alternatively proxies may be wrapped by software implementations of the hardware object classes. If an instance of the software object is created, the object tries to instantiate its hardware counterpart. In case of success the hardware object is used, otherwise the software object switches transparently to the software implementation. This approach also allows for a transparent migration between hardware and software objects. Advanced model compilers generate according implementations automatically. Implementations are guaranteed to be correct because they have been generated by the compiler entirely. Figure 7 shows a portion of operation PDLQ. IV. HARDWARE/SOFTWARE INTERFACE The direct implementation of components, classes and features is convenient and straightforward. Whereas in software this is a well understood problem, in hardware implementations this approach raises the following challenges: Fig.7 Generated Software implementation of int Main:main() '\QDPLF 2EMHFW,QVWDQWLDWLRQ'HVWUXFWLRQ Due to the static nature the efficient instantiation and destruction of hardware objects of partially reconfigurable hardware is not efficiently possible. The class instantiation per reconfigurable device is by far too expensive in terms of the number of required logic resources and reconfiguration time. 3RO\PRUSKLF )HDWXUHV Polymorphism is an important property of object oriented specifications. It should be supported directly by hardware implementations. Current approaches avoid polymorphism by prohibiting inheritance or overriding of behaviors. &RPPXQLFDWLRQ RI 2EMHFWV Objects should be able to communicate independent from their realization. In mixed software and hardware implementations there is no single, common mechanism for message exchange. In the following sections the mapping of implementation models to hardware/software implementations is discussed. The hardware/software interface of object-oriented implementations with reconfigurable hardware defines the life cycle and access mechanisms of objects and components realized in reconfigurable hardware. The hardware/software interface can be viewed from a logical and physical perspective. The logical hardware/software interface can be realized by different physical implementations. The concrete implementation depends upon the target platform and the model compiler. 2EMHFW/LIH&\FOH For efficiency reasons, the life cycle of hardware objects is not the same as of software objects. In order to avoid costly reconfigurations hardware objects are reused as much as possible. Initially each hardware object is in the state OBJ_UNBOUND. In this state the object is not bound to any hardware resources, so it does only exist as a template in a component that is realized by some hardware configuration context. When the component is instantiated its configuration is load into an appropriate device. All objects in the configuration go to the state OBJ_BOUND, because they are bound to physical hardware resources. Objects that are in the state OBJ_BOUND may be allocated by the application. If this is actually done, the respective objects go to the state OBJ_ALLOCATED. If an object is freed, it goes first to the state OBJ_BOUND, the instance may be destroyed, the contained objects go to state OBJ_UNBOUND again (Fig. 8).

Fig.8 Object Life-Cycle &RPSRQHQW/LIH&\FOH Objects are bound to resources in the context of an instance of a component that is realized by the objects classifier. In order to minimize costly hardware reconfigurations, the grouping of objects into components and the selection and scheduling of the reconfiguration process is optimized. Because a true dynamic instantiation/destruction of objects is not efficiently possible in hardware, these objects are pre instantiated at compilation time and synthesized into configuration bitstreams. The objects are dynamically allocated on demand; the RTR- Manager serves as object broker. Additionally, in RTR systems the objects and hardware configurations are dynamically bound to logic resources. Fig.9 Component Life-Cycle This mechanism is reflected in the life cycle components, which is illustrated in Figure 9. Because of the tight relationship between the hardware objects and their configuration context, as the container of the hardware objects, both life cycles influence each other. Like an object, a bitstream will go also through three states, BS_UNBOUND, BS_BOUND and BS_ALLOCATED. As long as the bitstream is not loaded into the reconfigurable hardware the bitstream is in state BS_UNBOUND and the objects are not existent. When a bitstream is loaded, a new instance of the bitstream is created and it changes its state to BS_BOUND. The contained objects go to state OBJ_BOUND. Objects allocated by the application change go from state OBJ_BOUND to OBJ_ALLOCATED. All objects returned by the application will set their state back to OBJ_BOUND. The last object of a context returned causes the bitstream set back to BS_BOUND. Until the bitstream is unloaded from the hardware, the objects will still be available for allocation. The bitstream is not allowed to be unloaded from the hardware as long as it is in state BS_ALLOCATED. 2EMHFW,QWHUIDFH The mechanisms for the access of objects are defined by the object interfaces. The interface of each object consists of a control interface, a data interface and an exception interface (Fig.10). Fig.10 Hardware Object Interface The FRQWURO LQWHUIDFH allows for identification, typing and access to the object. Objects are uniquely identified in their object space. The ID represents the address of the object and is set during initialization. This field is only required if the object address must be made explicit in the object interface. The type field represents the dynamic type of the object. It is used to select the proper implementations of polymorphic features. This field is only required if the object may have different dynamic types. The message fields uniquely identify the type of service accessed by a message send to the object. The service that is executed in response to the message may depend on the dynamic object type. The message parameters are passed through the data interface. The GDWDLQWHUIDFH allows to access the object state and to pass input/output parameters from and to objects. The interface contains the entire public state of the object and the parameters to/from services that are publicly accessible. The H[FHSWLRQLQWHUIDFH reflects exceptional conditions that occurred in the object. Depending on the exception handling of the object the information on the position and type of exceptions is exposed. This enables other objects to react appropriately. 2EMHFW$FFHVV The object interface as described above allows for the instantiation, destruction, and service access of hardware objects. The instantiation of objects is accomplished in four steps: - An object in state OBJ_BOUND that implements the

interface as defined by the required type must be selected. - The state of the selected object must be set to OBJ_ALLOCATED. - The selected object must be configured with an object- ID and object-type. - A create-service of the object must be executed. This is done by sending an appropriate create-message to the object with the service access mechanism. Note, that the second and third steps cannot be accomplished with services, because objects whose ID and type are not configured do not respond to any messages. Step four is executed for the internal initialization of the object state. The respective service is called constructor. For object destruction the destroy-service of the object must be executed. This is done by sending the destroy-message to the object with the service access mechanism. The object-id and object-type must be reset to deactivate the object. To make the object available for re-allocation its object-state must be set to OBJ_BOUND. To access to a specific service the input parameters of the service must be written to the data-interface and the message- ID to the control-interface. If the message is synchronously executed, the sender must wait until the execution of the service has been finished. If an exception occurred while the service was executed, the appropriate execution interface must be checked. If so, the service invocation breaks. At last the output/return-parameters of the message should be read from the data interface. V. HARDWARE IMPLEMENTATION +DUGZDUH,PSOHPHQWDWLRQRI&RPSRQHQWV The interface of each component representing a configuration bitstream comprises of all interfaces of the objects accessible through the component interface. Figure 11 shows a template for the implementation of UML components in hardware. The component contains the pre-implemented objects 2 L. The objects 2 0..2 Q are accessible via the communication interface. All other objects are not directly visible outside the component. The component also contains central circuits for the generation of clock and reset signals. There may be specialized clock generators for dedicated modules, like external ZBT RAM (zero bus turnaround random access memory) or peripheral devices. Fig.11 Hardware Component Template The ports DC i are manifestations of the Device Connect interfaces. This interface type is used to establish connections between internal logic resources and external devices through the physical device interface. From the UML specification of these interfaces the model compiler generates according implementations, which is controlled by the generation information in the model. In the VHDL implementation the interface of the top level design module comprises all signals of the DC ports. Additionally required components are modeled in the implementation platform model and instantiated on demand. Multiple objects are clustered in a hardware configuration. The number and type of the hardware objects being clustered in a single configuration is determined either manually or automatically. For this the global message exchange of classes and their object creation/destruction characteristics is analyzed. The number of concurrently required object instances is estimated from real or estimates execution profiles of the application. The public interface of publicly visible objects is realized with a register file. The register file allows for the access of the control, data and exception interfaces of the respective hardware objects. Collaborating objects communicate via direct connections or object buses (2% L ). To minimize bus contention there may be multiple object buses in one component. During design space exploration the model compiler tries to identify reasonably groups of collaborating objects. For each object group an object bus is generated, which connects all member objects of the group. Only the publicly visible objects can be instantiated by the software portion of the application. The other objects are hidden from outside and are used as helper objects within the component. The access to an object of a given type must be independent from the object template and the dynamic object type. For this to accomplish the public object interfaces of all objects of a given type and all of its subtypes must be identical. The realization of polymorphism is hidden behind the external object interface. The interface layout is performed by model compilers for V\VWHPRQFKLS (SoC) during generation. In the concrete layout alignment constraints on the items in the register file, which are imposed by the communication channels, are automatically considered. Model compilers assign to each element in the register file an address that suffices the alignment constraints in the system. Also the according address decoders are automatically generated. Software modules accessing a hardware object use only the relative addresses of the member elements of the object interfaces. The software proxies are parameterized with the absolute object address by the RTR-Manager. The proxies compute the absolute address of an element when it is accessed. This ensures that software and hardware always fit together and that the object access is independent from concrete object addresses and implementations. +DUGZDUH,PSOHPHQWDWLRQRI2EMHFWV Figure 12 shows a template for the implementation of objects in hardware.

Fig.12 Hardware Object Template The template shows the implementation of one object. The object contains the pre implemented operation 2 L, the operation parameters 3 L and the attributes $ L. The object can be of type 7 0 or 7 1. The sets 3 L and $ L comprise the data interface of the object. Operation 2 2 has a non empty exception interface. For each type the visible features must be provided in the interface. The set of visible operations is a super set of the operations that are defined by a type. Unused features are automatically eliminated by model compilers before design space exploration. The control interface is realized by a control and type register. The type register holds the current dynamic type of the object. The control register contains the two signals *2 and '21( for each operation. An operation is started by setting its *2 signal. The end of execution is signaled by the operation when it sets its '21( signal. Operation 2 1 is polymorphic, that is the behavior to be executed when the operation is started depends on the current object type. The selection of the concrete behavior is performed by a selector circuit, whose implementation is depicted on the right hand side of Fig. 12. Because the execution of both implementations of 2 1 does not need to require the same time, the selector must also multiplex the DONE signal. The object interface hides the execution of polymorphic behavior; that is for the sender of a message that is handled by 2 1 it must be irrelevant which implementation of this operation is executed. Thus both implementations of 2 1 share the same data interface. If both behaviors of the operations change data in their data interface the implementations must be decoupled from the actual data by according logic, e.g. tristate buffers or multiplexers. If no other output enable was specified in the model the '21( signal is used to activate the appropriate tristate buffers or selector signals. With a growing number of polymorphic operations the implementation requires a reasonable amount of logic resources. However, the support of polymorphism also provides significant advantages. If the implementation supports the object oriented features the designer has more freedom in the system specification. Moreover, because object orientation means to implement the differences between classes, the direct implementation of class hierarchies can help to reduce the required amount of logic resources. In each class of the hierarchy only the new and overridden features of the class in comparison to its super classes must be realized. Also the probability that an object of a required type is contained in the current bitstream is raised, because there are virtually more objects of different types. Hence the overall number of reconfiguration may drop. In experiments we have shown that this approach can improve the overall performance by orders of magnitude [1]. The full implementation of class hierarchies is only advantageous, however, if the classes in the hierarchy are actually instantiated by the application. The implementation of attributes and parameters is straightforward; they are mapped to a storage component of an appropriate width. If the implementation platform contains components with appropriate interfaces (Local Access, External Access), the modeled resources are used to generate the storage components. Simple registers are generated entirely by the model compiler or constructed from the modeled storage components. For performance and synchronization reasons the data interface of publicly visible objects is located in the register file. Objects are connected to the data interface and other objects with direct connections or buses. This raises a significant synchronization problem, because features may be accessed concurrently by multiple objects or operations. For the publicly visible objects the software proxy objects synchronize concurrent accesses by using suitable sequences for them. Concurrent accesses of proxy object and their hardware counterparts are decoupled by the dual ported architecture of the register file. Potentially concurrent accesses to an element in the same hardware component are guarded with arbiters. If the implementation uses an implementation type or operation that implements the Device Connect interface, the signals of this interface are routed to the top level VHDL module. This mechanism is used to include peripherals into the generated designs. +DUGZDUH,PSOHPHQWDWLRQRI%HKDYLRU The behavior of classes and operations is implemented according to the FSMD model (finite state machine with data path) as Moore FSM [2]. This model is especially suitable for control oriented applications and thereby fits the message based computing paradigm of the object based model of computation. Each behavior is constructed as controller with an attached data path. The data path performs the computations of the behavior, the evaluation of the conditions that control the data path and the components that store the inputs, outputs and intermediate results. For the realization of the computation operations and buffers the resource services that have been allocated during design space exploration are used. The results of conditions are inputs of the controller. The scheduling of the data path is performed and assigned to the behavior during design space exploration. During implementation this schedule is then actually realized. For each PE the global scheduling policy is specified in the deployment platform model. For a better control of the implementation the designer may also specify a local, operation specific policy in the implementation model. The controller is realized as FSM that activates the operations in the data path. Each of the operations of the data path is associated with a number of states of the FSM. Operations that require at most one clock cycle are associated with one FSM state. Multicycle operations are associated with a number of consequtive states. Independent operations and

operations that execute at most one clock cycle may be chained to execute back to back in the same cycle. State transitions are performed synchronously. Figures 13 and 14 show the realization of the first loop of the behavior of the function 79/3URFHVVRU LV2UWKRJRQDOYHFWRULQW ERROHDQ (see Fig. 1). The FSM in the Figure 13 is decomposed into a controller, a data path and a synchronization process. The loop is executed as long as the loop counter, where L is less than VL]H. The synchronization process is not shown. It synchronously sets the current FSM state and the '21(signal when the FSM is in the final state. fsm : process (tmp, CS) is begin case CS is when S8 => NS <= S9 ; when S9 => if (tmp = 1') then NS <= S10 ; else NS <= ; end if; when S10 => NS <= S11 ; when S11 => if (tmp = 1 ) then NS <= S10 ; else NS <= S12 ; end if; when S12 => NS <= ; when S22 => NS <= end process fsm; Controller dp : process (GO, CLOCK) is begin if GO = '0' then Initialization else if CLOCK'event and CLOCK = '1' then case CS is when S8 => tmp <= conv_std_logic( i < size) ; when S10 => ADRESS_9 <= i ; RW <= 0' ; ENABLE <= '1' ; tmp <= (ACK = '0') ; when S12 => RW <= '0' ; ENABLE <= '0' ; when S22 => i <= (i + 000001 ) ; end case; end if; end if; end process dp; Data path Fig.14 VHDL Loop Implementation Example hardware/software codesign. We have shown UML can be used beneficially to develop a wide range of relevant SoC applications. This has been exemplified with a simple application to check if a Ternary Vector List is orthogonal. With this application the transformation of platform independent UML design models into final implementations of hardware/software modules has been demonstrated. Fig.13 FSM for the first loop of implementation Example In contrast to software implementations each behavior is realized for each hardware object. That means the implementation of a behavior is not shared by objects that provide the same behavior. Thereby no synchronization of concurrent executions of the same behavior in different object is required. To avoid write contention the data path keeps local copies of attributes and inout parameters. All modifications of the data path are performed on the copies. If no explicit output enable is specified in the model they are synchronized back at the end of the computation and when the behavior executes a message transfer. Array accesses in the model are transformed to explicit bus transfers. Similar transformations are performed to accomplish message exchange between objects. Message transfers between operations of the same object are commonly inlined by the model compiler. This requires more implementation resources but again minimizes data contention. VI. CONCLUSIONS In this article we presented a novel approach to the UML based development of applications for reconfigurable architectures. The approach incorporates the key concepts of model driven architecture, platform based design and REFERENCES [1] T. Beierlein, D. Fröhlich, and B. Steinbach, "UML-Based Co- Design of Reconfigurable Architectures," in 3URFHHGLQJV RI WKH)RUXPRQ6SHFLILFDWLRQDQG'HVLJQ/DQJXDJHV)'/, Frankfurt a.m., Germany, Sept. 2003, pp 285-296. [2] D. D. Gajski, 3ULQFLSOHVRI'LJLWDO'HVLJQ. Prentice-Hall, 1997. [3] 6SHF& 7HFKQRORJ\ 2SHQ &RQVRUWLXP. 6SHF& /DQJXDJH 5HIHUHQFH 0DQXDO, Version 2.0. Specification, December 2002. http://www.specc.org. [4] 6\VWHP& /DQJXDJH :RUNLQJ *URXS )XQFWLRQDO VSHFLILFDWLRQIRUV\VWHPF. Specification, April 2002. http://www.systemc.org. [5] 0RFFD 3URMHFW 7KH 0RFFDFRPSLOHU IRU UXQWLPH UHFRQILJXUDEOH DUFKLWHFWXUHV. Web-Pages, January 2004. http://www.htwm.de/lec/mocca (under construction). [6] University Irvine, Center for Embedded Computer Systems. 63$5. +LJK/HYHO 6\QWKHVLV XVLQJ 3DUDOOHOL]LQJ&RPSLOHU7HFKQLTXHV. http://mesl.ucsd.edu/spark/, April 2004. [7] L. Lavagno, G. Martin, B. Selic, 80/IRU5HDO'HVLJQRI (PEHGGHG 5HDO7LPH 6\VWHPV. - Boston, Kluwer Academic Publishers, 2003 [8] M. Fowler, K. Scott, 80/'LVWLOOHG$EULHI*XLGHWRWKH 6WDQGDUG 2EMHFW 0RGHOLQJ /DQJXDJH. Addison Wesley, Juni 2004 [9] H. Riedel, 'HVLJQ DQG,PSOHPHQWDWLRQ RI D 5XQ7LPH (QYLURQPHQW IRU 5756\VWHPV Diploma Thesis, January 2004. University of Applied Sciences Mittweida, Germany