Synthesis of UML-Models for Reconfigurable Hardware

Size: px
Start display at page:

Download "Synthesis of UML-Models for Reconfigurable Hardware"

Transcription

1 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.

2 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.

3 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

4 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).

5 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

6 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 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.

7 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

8 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 ) ; 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 [2] D. D. Gajski, 3ULQFLSOHVRI'LJLWDO'HVLJQ. Prentice-Hall, [3] 6SHF& 7HFKQRORJ\ 2SHQ &RQVRUWLXP. 6SHF& /DQJXDJH 5HIHUHQFH 0DQXDO, Version 2.0. Specification, December [4] 6\VWHP& /DQJXDJH :RUNLQJ *URXS )XQFWLRQDO VSHFLILFDWLRQIRUV\VWHPF. Specification, April [5] 0RFFD 3URMHFW 7KH 0RFFDFRPSLOHU IRU UXQWLPH UHFRQILJXUDEOH DUFKLWHFWXUHV. Web-Pages, January (under construction). [6] University Irvine, Center for Embedded Computer Systems. 63$5. +LJK/HYHO 6\QWKHVLV XVLQJ 3DUDOOHOL]LQJ&RPSLOHU7HFKQLTXHV. April [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 University of Applied Sciences Mittweida, Germany

Hardware Synthesis of UML-Models

Hardware Synthesis of UML-Models Hardware Synthesis of UML-Models Thomas Beierlein Dominik Fröhlich Bernd Steinbach Hochschule Mittweida TU Bergakademie Freiberg TU Bergakademie Freiberg Labor Embedded Control Inst. of Computer Science

More information

UML-BASED CO-DESIGN FOR RUN-TIME RECONFIGURABLE ARCHITECTURES

UML-BASED CO-DESIGN FOR RUN-TIME RECONFIGURABLE ARCHITECTURES Chapter 1 UML-BASED CO-DESIGN FOR RUN-TIME RECONFIGURABLE ARCHITECTURES Bernd Steinbach 1, Thomas Beierlein 2, Dominik Fröhlich 1,2 1 TU Bergakademie Freiberg Institute of Computer Science 2 Hochschule

More information

Hardware/Software Codesign of Reconfigurable Architectures Using UML

Hardware/Software Codesign of Reconfigurable Architectures Using UML Chapter 1 Hardware/Software Codesign of Reconfigurable Architectures Using UML Bernd Steinbach 1, Dominik Fröhlich 1,2, Thomas Beierlein 2 1 Technische Universität Bergakademie Freiberg Institute of Computer

More information

UML Model Transformation for a Product Line Design

UML Model Transformation for a Product Line Design UML Model Transformation for a Product Line Design R. Aroulcanessane #1, S. Srinivasan *2 # Research Scholar, Sathyabama University, Chennai, Tamil Nadu, India 1 aroul_308@yahoo.co.in * Professor & Head,

More information

SpecC Methodology for High-Level Modeling

SpecC Methodology for High-Level Modeling EDP 2002 9 th IEEE/DATC Electronic Design Processes Workshop SpecC Methodology for High-Level Modeling Rainer Dömer Daniel D. Gajski Andreas Gerstlauer Center for Embedded Computer Systems Universitiy

More information

Model-Driven Compilation of UML-Models for Reconfigurable Architectures

Model-Driven Compilation of UML-Models for Reconfigurable Architectures -Driven Compilation of UML-s for Reconfigurable Architectures Thomas Beierlein 1, Dominik Fröhlich 12, and Bernd Steinbach 2 1 Hochschule Mittweida Dept. Information Technology and Electrotechnique Germany

More information

R07. IV B.Tech. II Semester Supplementary Examinations, July, 2011

R07. IV B.Tech. II Semester Supplementary Examinations, July, 2011 www..com www..com Set No. 1 DIGITAL DESIGN THROUGH VERILOG (Common to Electronics & Communication Engineering, Bio-Medical Engineering and Electronics & Computer Engineering) 1. a) What is Verilog HDL?

More information

A Synthesizable RTL Design of Asynchronous FIFO Interfaced with SRAM

A Synthesizable RTL Design of Asynchronous FIFO Interfaced with SRAM A Synthesizable RTL Design of Asynchronous FIFO Interfaced with SRAM Mansi Jhamb, Sugam Kapoor USIT, GGSIPU Sector 16-C, Dwarka, New Delhi-110078, India Abstract This paper demonstrates an asynchronous

More information

Software Service Engineering

Software Service Engineering Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language

More information

Cosimulation of ITRON-Based Embedded Software with SystemC

Cosimulation of ITRON-Based Embedded Software with SystemC Cosimulation of ITRON-Based Embedded Software with SystemC Shin-ichiro Chikada, Shinya Honda, Hiroyuki Tomiyama, Hiroaki Takada Graduate School of Information Science, Nagoya University Information Technology

More information

UNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach?

UNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach? Department: Information Technology Questions Bank Class: B.E. (I.T) Prof. Bhujbal Dnyaneshwar K. Subject: Object Oriented Modeling & Design dnyanesh.bhujbal11@gmail.com ------------------------------------------------------------------------------------------------------------

More information

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a

More information

Hardware Design Environments. Dr. Mahdi Abbasi Computer Engineering Department Bu-Ali Sina University

Hardware Design Environments. Dr. Mahdi Abbasi Computer Engineering Department Bu-Ali Sina University Hardware Design Environments Dr. Mahdi Abbasi Computer Engineering Department Bu-Ali Sina University Outline Welcome to COE 405 Digital System Design Design Domains and Levels of Abstractions Synthesis

More information

A Design Methodology for the Exploitation of High Level Communication Synthesis

A Design Methodology for the Exploitation of High Level Communication Synthesis A Design Methodology for the Exploitation of High Level Communication Synthesis Francesco Bruschi, Politecnico di Milano, Italy Massimo Bombana, CEFRIEL, Italy Abstract In this paper we analyse some methodological

More information

Unit 2: High-Level Synthesis

Unit 2: High-Level Synthesis Course contents Unit 2: High-Level Synthesis Hardware modeling Data flow Scheduling/allocation/assignment Reading Chapter 11 Unit 2 1 High-Level Synthesis (HLS) Hardware-description language (HDL) synthesis

More information

Addressing Verification Bottlenecks of Fully Synthesized Processor Cores using Equivalence Checkers

Addressing Verification Bottlenecks of Fully Synthesized Processor Cores using Equivalence Checkers Addressing Verification Bottlenecks of Fully Synthesized Processor Cores using Equivalence Checkers Subash Chandar G (g-chandar1@ti.com), Vaideeswaran S (vaidee@ti.com) DSP Design, Texas Instruments India

More information

Concept as a Generalization of Class and Principles of the Concept-Oriented Programming

Concept as a Generalization of Class and Principles of the Concept-Oriented Programming Computer Science Journal of Moldova, vol.13, no.3(39), 2005 Concept as a Generalization of Class and Principles of the Concept-Oriented Programming Alexandr Savinov Abstract In the paper we describe a

More information

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.

SOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis. SOFTWARE ENGINEERING UML FUNDAMENTALS Saulius Ragaišis saulius.ragaisis@mif.vu.lt Information source Slides are prepared on the basis of Bernd Oestereich, Developing Software with UML: Object- Oriented

More information

Cycle-accurate RTL Modeling with Multi-Cycled and Pipelined Components

Cycle-accurate RTL Modeling with Multi-Cycled and Pipelined Components Cycle-accurate RTL Modeling with Multi-Cycled and Pipelined Components Rainer Dömer, Andreas Gerstlauer, Dongwan Shin Technical Report CECS-04-19 July 22, 2004 Center for Embedded Computer Systems University

More information

Hardware Software Codesign of Embedded System

Hardware Software Codesign of Embedded System Hardware Software Codesign of Embedded System CPSC489-501 Rabi Mahapatra Mahapatra - Texas A&M - Fall 00 1 Today s topics Course Organization Introduction to HS-CODES Codesign Motivation Some Issues on

More information

HIERARCHICAL DESIGN. RTL Hardware Design by P. Chu. Chapter 13 1

HIERARCHICAL DESIGN. RTL Hardware Design by P. Chu. Chapter 13 1 HIERARCHICAL DESIGN Chapter 13 1 Outline 1. Introduction 2. Components 3. Generics 4. Configuration 5. Other supporting constructs Chapter 13 2 1. Introduction How to deal with 1M gates or more? Hierarchical

More information

Outline HIERARCHICAL DESIGN. 1. Introduction. Benefits of hierarchical design

Outline HIERARCHICAL DESIGN. 1. Introduction. Benefits of hierarchical design Outline HIERARCHICAL DESIGN 1. Introduction 2. Components 3. Generics 4. Configuration 5. Other supporting constructs Chapter 13 1 Chapter 13 2 1. Introduction How to deal with 1M gates or more? Hierarchical

More information

Unit Wise Questions. Unit-1 Concepts

Unit Wise Questions. Unit-1 Concepts Unit Wise Questions Unit-1 Concepts Q1. What is UML? Ans. Unified Modelling Language. It is a Industry standard graphical language for modelling and hence visualizing a blue print of all the aspects of

More information

The SpecC System-Level Design Language and Methodology, Part 1. Class 309

The SpecC System-Level Design Language and Methodology, Part 1. Class 309 Embedded Systems Conference San Francisco 2002 The SpecC System-Level Design Language and Methodology, Part 1 Class 309 Rainer Dömer Center for Embedded Computer Systems Universitiy of California, Irvine,

More information

FPGA for Software Engineers

FPGA for Software Engineers FPGA for Software Engineers Course Description This course closes the gap between hardware and software engineers by providing the software engineer all the necessary FPGA concepts and terms. The course

More information

UML-Based Design Flow and Partitioning Methodology for Dynamically Reconfigurable Computing Systems

UML-Based Design Flow and Partitioning Methodology for Dynamically Reconfigurable Computing Systems UML-Based Design Flow and Partitioning Methodology for Dynamically Reconfigurable Computing Systems Chih-Hao Tseng and Pao-Ann Hsiung Department of Computer Science and Information Engineering, National

More information

SoC Design for the New Millennium Daniel D. Gajski

SoC Design for the New Millennium Daniel D. Gajski SoC Design for the New Millennium Daniel D. Gajski Center for Embedded Computer Systems University of California, Irvine www.cecs.uci.edu/~gajski Outline System gap Design flow Model algebra System environment

More information

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D. Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice

More information

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : ,

For 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : , Course Code : MCS-032 Course Title : Object Oriented Analysis and Design Assignment Number : MCA (3)/032/Assign/2014-15 Assignment Marks : 100 Weightage : 25% Last Dates for Submission : 15th October,

More information

ECE 448 Lecture 15. Overview of Embedded SoC Systems

ECE 448 Lecture 15. Overview of Embedded SoC Systems ECE 448 Lecture 15 Overview of Embedded SoC Systems ECE 448 FPGA and ASIC Design with VHDL George Mason University Required Reading P. Chu, FPGA Prototyping by VHDL Examples Chapter 8, Overview of Embedded

More information

Computer Systems Organization

Computer Systems Organization The IAS (von Neumann) Machine Computer Systems Organization Input Output Equipment Stored Program concept Main memory storing programs and data ALU operating on binary data Control unit interpreting instructions

More information

System Level Design Flow

System Level Design Flow System Level Design Flow What is needed and what is not Daniel D. Gajski Center for Embedded Computer Systems University of California, Irvine www.cecs.uci.edu/~gajski System Level Design Flow What is

More information

Software Architecture

Software Architecture Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment

More information

Using SystemC to Implement Embedded Software

Using SystemC to Implement Embedded Software Using SystemC to Implement Embedded Software Brijesh Sirpatil James M. Baker, Jr. James R. Armstrong Bradley Department of Electrical and Computer Engineering, Virginia Tech, Blacksburg, VA Abstract This

More information

Hardware Description Languages & System Description Languages Properties

Hardware Description Languages & System Description Languages Properties Hardware Description Languages & System Description Languages Properties There is a need for executable specification language that is capable of capturing the functionality of the system in a machine-readable

More information

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1 What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely

More information

Design Patterns. SE3A04 Tutorial. Jason Jaskolka

Design Patterns. SE3A04 Tutorial. Jason Jaskolka SE3A04 Tutorial Jason Jaskolka Department of Computing and Software Faculty of Engineering McMaster University Hamilton, Ontario, Canada jaskolj@mcmaster.ca November 18/19, 2014 Jason Jaskolka 1 / 35 1

More information

Object Oriented Analysis and Design - Part2(Design)

Object Oriented Analysis and Design - Part2(Design) Object Oriented Analysis and Design - Part2(Design) Exam A QUESTION 1 Which statement is true about elements within the subsystem and public visibility? A. Only the subset of elements that define the subsystems

More information

DOWNLOAD PDF CORE JAVA APTITUDE QUESTIONS AND ANSWERS

DOWNLOAD PDF CORE JAVA APTITUDE QUESTIONS AND ANSWERS Chapter 1 : Chapter-wise Java Multiple Choice Questions and Answers Interview MCQs Java Programming questions and answers with explanation for interview, competitive examination and entrance test. Fully

More information

What are the characteristics of Object Oriented programming language?

What are the characteristics of Object Oriented programming language? What are the various elements of OOP? Following are the various elements of OOP:- Class:- A class is a collection of data and the various operations that can be performed on that data. Object- This is

More information

AOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz

AOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz AOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz Results obtained by researchers in the aspect-oriented programming are promoting the aim to export these ideas to whole software development

More information

EMBEDDED SOPC DESIGN WITH NIOS II PROCESSOR AND VHDL EXAMPLES

EMBEDDED SOPC DESIGN WITH NIOS II PROCESSOR AND VHDL EXAMPLES EMBEDDED SOPC DESIGN WITH NIOS II PROCESSOR AND VHDL EXAMPLES Pong P. Chu Cleveland State University A JOHN WILEY & SONS, INC., PUBLICATION PREFACE An SoC (system on a chip) integrates a processor, memory

More information

APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS

APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS APPLYING DESIGN PATTERNS TO SCA IMPLEMENTATIONS Adem Zumbul (TUBITAK-UEKAE, Kocaeli, Turkey, ademz@uekae.tubitak.gov.tr); Tuna Tugcu (Bogazici University, Istanbul, Turkey, tugcu@boun.edu.tr) ABSTRACT

More information

RUN-TIME RECONFIGURABLE IMPLEMENTATION OF DSP ALGORITHMS USING DISTRIBUTED ARITHMETIC. Zoltan Baruch

RUN-TIME RECONFIGURABLE IMPLEMENTATION OF DSP ALGORITHMS USING DISTRIBUTED ARITHMETIC. Zoltan Baruch RUN-TIME RECONFIGURABLE IMPLEMENTATION OF DSP ALGORITHMS USING DISTRIBUTED ARITHMETIC Zoltan Baruch Computer Science Department, Technical University of Cluj-Napoca, 26-28, Bariţiu St., 3400 Cluj-Napoca,

More information

JTAG TAP CONTROLLER PROGRAMMING USING FPGA BOARD

JTAG TAP CONTROLLER PROGRAMMING USING FPGA BOARD JTAG TAP CONTROLLER PROGRAMMING USING FPGA BOARD 1 MOHAMED JEBRAN.P, 2 SHIREEN FATHIMA, 3 JYOTHI M 1,2 Assistant Professor, Department of ECE, HKBKCE, Bangalore-45. 3 Software Engineer, Imspired solutions,

More information

System Level Design For Low Power. Yard. Doç. Dr. Berna Örs Yalçın

System Level Design For Low Power. Yard. Doç. Dr. Berna Örs Yalçın System Level Design For Low Power Yard. Doç. Dr. Berna Örs Yalçın References System-Level Design Methodology, Daniel D. Gajski Hardware-software co-design of embedded systems : the POLIS approach / by

More information

EECS150 - Digital Design Lecture 6 - Field Programmable Gate Arrays (FPGAs)

EECS150 - Digital Design Lecture 6 - Field Programmable Gate Arrays (FPGAs) EECS150 - Digital Design Lecture 6 - Field Programmable Gate Arrays (FPGAs) September 12, 2002 John Wawrzynek Fall 2002 EECS150 - Lec06-FPGA Page 1 Outline What are FPGAs? Why use FPGAs (a short history

More information

FPGA based Design of Low Power Reconfigurable Router for Network on Chip (NoC)

FPGA based Design of Low Power Reconfigurable Router for Network on Chip (NoC) FPGA based Design of Low Power Reconfigurable Router for Network on Chip (NoC) D.Udhayasheela, pg student [Communication system],dept.ofece,,as-salam engineering and technology, N.MageshwariAssistant Professor

More information

VHDL: RTL Synthesis Basics. 1 of 59

VHDL: RTL Synthesis Basics. 1 of 59 VHDL: RTL Synthesis Basics 1 of 59 Goals To learn the basics of RTL synthesis. To be able to synthesize a digital system, given its VHDL model. To be able to relate VHDL code to its synthesized output.

More information

Outline. EECS150 - Digital Design Lecture 6 - Field Programmable Gate Arrays (FPGAs) FPGA Overview. Why FPGAs?

Outline. EECS150 - Digital Design Lecture 6 - Field Programmable Gate Arrays (FPGAs) FPGA Overview. Why FPGAs? EECS150 - Digital Design Lecture 6 - Field Programmable Gate Arrays (FPGAs) September 12, 2002 John Wawrzynek Outline What are FPGAs? Why use FPGAs (a short history lesson). FPGA variations Internal logic

More information

Appendix A - Glossary(of OO software term s)

Appendix A - Glossary(of OO software term s) Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component

More information

Chapter 1: Object-Oriented Programming Using C++

Chapter 1: Object-Oriented Programming Using C++ Chapter 1: Object-Oriented Programming Using C++ Objectives Looking ahead in this chapter, we ll consider: Abstract Data Types Encapsulation Inheritance Pointers Polymorphism Data Structures and Algorithms

More information

Object Oriented Paradigm

Object Oriented Paradigm Object Oriented Paradigm Ming-Hwa Wang, Ph.D. Department of Computer Engineering Santa Clara University Object Oriented Paradigm/Programming (OOP) similar to Lego, which kids build new toys from assembling

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration

More information

Object Orientated Analysis and Design. Benjamin Kenwright

Object Orientated Analysis and Design. Benjamin Kenwright Notation Part 2 Object Orientated Analysis and Design Benjamin Kenwright Outline Review What do we mean by Notation and UML? Types of UML View Continue UML Diagram Types Conclusion and Discussion Summary

More information

ISSN Vol.03, Issue.08, October-2015, Pages:

ISSN Vol.03, Issue.08, October-2015, Pages: ISSN 2322-0929 Vol.03, Issue.08, October-2015, Pages:1284-1288 www.ijvdcs.org An Overview of Advance Microcontroller Bus Architecture Relate on AHB Bridge K. VAMSI KRISHNA 1, K.AMARENDRA PRASAD 2 1 Research

More information

CHAPTER 6 FPGA IMPLEMENTATION OF ARBITERS ALGORITHM FOR NETWORK-ON-CHIP

CHAPTER 6 FPGA IMPLEMENTATION OF ARBITERS ALGORITHM FOR NETWORK-ON-CHIP 133 CHAPTER 6 FPGA IMPLEMENTATION OF ARBITERS ALGORITHM FOR NETWORK-ON-CHIP 6.1 INTRODUCTION As the era of a billion transistors on a one chip approaches, a lot of Processing Elements (PEs) could be located

More information

System Debugging Tools Overview

System Debugging Tools Overview 9 QII53027 Subscribe About Altera System Debugging Tools The Altera system debugging tools help you verify your FPGA designs. As your product requirements continue to increase in complexity, the time you

More information

Report. Middleware Proxy: A Request-Driven Messaging Broker For High Volume Data Distribution

Report. Middleware Proxy: A Request-Driven Messaging Broker For High Volume Data Distribution CERN-ACC-2013-0237 Wojciech.Sliwinski@cern.ch Report Middleware Proxy: A Request-Driven Messaging Broker For High Volume Data Distribution W. Sliwinski, I. Yastrebov, A. Dworak CERN, Geneva, Switzerland

More information

Introduction to Electronic Design Automation. Model of Computation. Model of Computation. Model of Computation

Introduction to Electronic Design Automation. Model of Computation. Model of Computation. Model of Computation Introduction to Electronic Design Automation Model of Computation Jie-Hong Roland Jiang 江介宏 Department of Electrical Engineering National Taiwan University Spring 03 Model of Computation In system design,

More information

Basic Processing Unit: Some Fundamental Concepts, Execution of a. Complete Instruction, Multiple Bus Organization, Hard-wired Control,

Basic Processing Unit: Some Fundamental Concepts, Execution of a. Complete Instruction, Multiple Bus Organization, Hard-wired Control, UNIT - 7 Basic Processing Unit: Some Fundamental Concepts, Execution of a Complete Instruction, Multiple Bus Organization, Hard-wired Control, Microprogrammed Control Page 178 UNIT - 7 BASIC PROCESSING

More information

Keywords: HDL, Hardware Language, Digital Design, Logic Design, RTL, Register Transfer, VHDL, Verilog, VLSI, Electronic CAD.

Keywords: HDL, Hardware Language, Digital Design, Logic Design, RTL, Register Transfer, VHDL, Verilog, VLSI, Electronic CAD. HARDWARE DESCRIPTION Mehran M. Massoumi, HDL Research & Development, Averant Inc., USA Keywords: HDL, Hardware Language, Digital Design, Logic Design, RTL, Register Transfer, VHDL, Verilog, VLSI, Electronic

More information

Transaction-Level Modeling Definitions and Approximations. 2. Definitions of Transaction-Level Modeling

Transaction-Level Modeling Definitions and Approximations. 2. Definitions of Transaction-Level Modeling Transaction-Level Modeling Definitions and Approximations EE290A Final Report Trevor Meyerowitz May 20, 2005 1. Introduction Over the years the field of electronic design automation has enabled gigantic

More information

81920**slide. 1Developing the Accelerator Using HLS

81920**slide. 1Developing the Accelerator Using HLS 81920**slide - 1Developing the Accelerator Using HLS - 82038**slide Objectives After completing this module, you will be able to: Describe the high-level synthesis flow Describe the capabilities of the

More information

Modeling Arbitrator Delay-Area Dependencies in Customizable Instruction Set Processors

Modeling Arbitrator Delay-Area Dependencies in Customizable Instruction Set Processors Modeling Arbitrator Delay-Area Dependencies in Customizable Instruction Set Processors Siew-Kei Lam Centre for High Performance Embedded Systems, Nanyang Technological University, Singapore (assklam@ntu.edu.sg)

More information

HIGH-LEVEL SYNTHESIS

HIGH-LEVEL SYNTHESIS HIGH-LEVEL SYNTHESIS Page 1 HIGH-LEVEL SYNTHESIS High-level synthesis: the automatic addition of structural information to a design described by an algorithm. BEHAVIORAL D. STRUCTURAL D. Systems Algorithms

More information

II. LITERATURE SURVEY

II. LITERATURE SURVEY Hardware Co-Simulation of Sobel Edge Detection Using FPGA and System Generator Sneha Moon 1, Prof Meena Chavan 2 1,2 Department of Electronics BVUCOE Pune India Abstract: This paper implements an image

More information

An Introduction to Object Orientation

An Introduction to Object Orientation An Introduction to Object Orientation Rushikesh K Joshi Indian Institute of Technology Bombay rkj@cse.iitb.ac.in A talk given at Islampur Abstractions in Programming Control Abstractions Functions, function

More information

Bibliography. Measuring Software Reuse, Jeffrey S. Poulin, Addison-Wesley, Practical Software Reuse, Donald J. Reifer, Wiley, 1997.

Bibliography. Measuring Software Reuse, Jeffrey S. Poulin, Addison-Wesley, Practical Software Reuse, Donald J. Reifer, Wiley, 1997. Bibliography Books on software reuse: 1. 2. Measuring Software Reuse, Jeffrey S. Poulin, Addison-Wesley, 1997. Practical Software Reuse, Donald J. Reifer, Wiley, 1997. Formal specification and verification:

More information

Hardware/Software Co-design

Hardware/Software Co-design Hardware/Software Co-design Zebo Peng, Department of Computer and Information Science (IDA) Linköping University Course page: http://www.ida.liu.se/~petel/codesign/ 1 of 52 Lecture 1/2: Outline : an Introduction

More information

Synthetic Benchmark Generator for the MOLEN Processor

Synthetic Benchmark Generator for the MOLEN Processor Synthetic Benchmark Generator for the MOLEN Processor Stephan Wong, Guanzhou Luo, and Sorin Cotofana Computer Engineering Laboratory, Electrical Engineering Department, Delft University of Technology,

More information

COE 561 Digital System Design & Synthesis Introduction

COE 561 Digital System Design & Synthesis Introduction 1 COE 561 Digital System Design & Synthesis Introduction Dr. Aiman H. El-Maleh Computer Engineering Department King Fahd University of Petroleum & Minerals Outline Course Topics Microelectronics Design

More information

Data Structures and Algorithms Design Goals Implementation Goals Design Principles Design Techniques. Version 03.s 2-1

Data Structures and Algorithms Design Goals Implementation Goals Design Principles Design Techniques. Version 03.s 2-1 Design Principles Data Structures and Algorithms Design Goals Implementation Goals Design Principles Design Techniques 2-1 Data Structures Data Structure - A systematic way of organizing and accessing

More information

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,

More information

Advanced FPGA Design Methodologies with Xilinx Vivado

Advanced FPGA Design Methodologies with Xilinx Vivado Advanced FPGA Design Methodologies with Xilinx Vivado Alexander Jäger Computer Architecture Group Heidelberg University, Germany Abstract With shrinking feature sizes in the ASIC manufacturing technology,

More information

The goal of the Pangaea project, as we stated it in the introduction, was to show that

The goal of the Pangaea project, as we stated it in the introduction, was to show that Chapter 5 Conclusions This chapter serves two purposes. We will summarize and critically evaluate the achievements of the Pangaea project in section 5.1. Based on this, we will then open up our perspective

More information

Partitioning of Mealy Finite State Machines

Partitioning of Mealy Finite State Machines Partitioning of Mealy Finite State Machines Arkadiusz Bukowiec Luis Gomes University of Zielona Góra, Institute of Computer Engineering and Electronics, Zielona Góra, Poland (e-mail: a.bukowiec@iie.uz.zgora.pl)

More information

Best Practices for Incremental Compilation Partitions and Floorplan Assignments

Best Practices for Incremental Compilation Partitions and Floorplan Assignments Best Practices for Incremental Compilation Partitions and Floorplan Assignments December 2007, ver. 1.0 Application Note 470 Introduction The Quartus II incremental compilation feature allows you to partition

More information

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns EPL 603 TOPICS IN SOFTWARE ENGINEERING Lab 6: Design Patterns Links to Design Pattern Material 1 http://www.oodesign.com/ http://www.vincehuston.org/dp/patterns_quiz.html Types of Design Patterns 2 Creational

More information

Hardware Software Codesign of Embedded Systems

Hardware Software Codesign of Embedded Systems Hardware Software Codesign of Embedded Systems Rabi Mahapatra Texas A&M University Today s topics Course Organization Introduction to HS-CODES Codesign Motivation Some Issues on Codesign of Embedded System

More information

Coordination Patterns

Coordination Patterns Coordination Patterns 1. Coordination Patterns Design Patterns and their relevance for Coordination Oscar Nierstrasz Software Composition Group Institut für Informatik (IAM) Universität Bern oscar@iam.unibe.ch

More information

C++ for System Developers with Design Pattern

C++ for System Developers with Design Pattern C++ for System Developers with Design Pattern Introduction: This course introduces the C++ language for use on real time and embedded applications. The first part of the course focuses on the language

More information

OpenMP for next generation heterogeneous clusters

OpenMP for next generation heterogeneous clusters OpenMP for next generation heterogeneous clusters Jens Breitbart Research Group Programming Languages / Methodologies, Universität Kassel, jbreitbart@uni-kassel.de Abstract The last years have seen great

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Performance Imrovement of a Navigataion System Using Partial Reconfiguration

Performance Imrovement of a Navigataion System Using Partial Reconfiguration Performance Imrovement of a Navigataion System Using Partial Reconfiguration S.S.Shriramwar 1, Dr. N.K.Choudhari 2 1 Priyadarshini College of Engineering, R.T.M. Nagpur Unversity,Nagpur, sshriramwar@yahoo.com

More information

DIGITAL DESIGN TECHNOLOGY & TECHNIQUES

DIGITAL DESIGN TECHNOLOGY & TECHNIQUES DIGITAL DESIGN TECHNOLOGY & TECHNIQUES CAD for ASIC Design 1 INTEGRATED CIRCUITS (IC) An integrated circuit (IC) consists complex electronic circuitries and their interconnections. William Shockley et

More information

Application Architectures, Design Patterns

Application Architectures, Design Patterns Application Architectures, Design Patterns Martin Ledvinka martin.ledvinka@fel.cvut.cz Winter Term 2017 Martin Ledvinka (martin.ledvinka@fel.cvut.cz) Application Architectures, Design Patterns Winter Term

More information

FPGA Interfacing of HD44780 Based LCD Using Delayed Finite State Machine (FSM)

FPGA Interfacing of HD44780 Based LCD Using Delayed Finite State Machine (FSM) FPGA Interfacing of HD44780 Based LCD Using Delayed Finite State Machine (FSM) Edwin NC Mui Custom R & D Engineer Texco Enterprise Ptd. Ltd. {blackgrail2000@hotmail.com} Abstract This paper presents a

More information

Lecture 9. VHDL, part IV. Hierarchical and parameterized design. Section 1 HIERARCHICAL DESIGN

Lecture 9. VHDL, part IV. Hierarchical and parameterized design. Section 1 HIERARCHICAL DESIGN Lecture 9 VHDL, part IV Hierarchical and parameterized design Section 1 HIERARCHICAL DESIGN 2 1 Dealing with Large Digital System Design 1. Apply hierarchy to the design At the highest level use larger

More information

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold.

2.0.3 attributes: A named property of a class that describes the range of values that the class or its instances (i.e., objects) may hold. T0/06-6 revision 2 Date: May 22, 2006 To: T0 Committee (SCSI) From: George Penokie (IBM/Tivoli) Subject: SAM-4: Converting to UML part Overview The current SCSI architecture follows no particular documentation

More information

ECL: A SPECIFICATION ENVIRONMENT FOR SYSTEM-LEVEL DESIGN

ECL: A SPECIFICATION ENVIRONMENT FOR SYSTEM-LEVEL DESIGN / ECL: A SPECIFICATION ENVIRONMENT FOR SYSTEM-LEVEL DESIGN Gerard Berry Ed Harcourt Luciano Lavagno Ellen Sentovich Abstract We propose a new specification environment for system-level design called ECL.

More information

LABORATORY 1 REVISION

LABORATORY 1 REVISION UTCN Computer Science Department Software Design 2012/2013 LABORATORY 1 REVISION ================================================================== I. UML Revision This section focuses on reviewing the

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecturer: Raman Ramsin Lecture 9: Generalization/Specialization 1 Analysis Workflow: Analyze a Use Case The analysis workflow consists of the following activities: Architectural

More information

Computer-Aided Recoding for Multi-Core Systems

Computer-Aided Recoding for Multi-Core Systems Computer-Aided Recoding for Multi-Core Systems Rainer Dömer doemer@uci.edu With contributions by P. Chandraiah Center for Embedded Computer Systems University of California, Irvine Outline Embedded System

More information

System-On-Chip Architecture Modeling Style Guide

System-On-Chip Architecture Modeling Style Guide Center for Embedded Computer Systems University of California, Irvine System-On-Chip Architecture Modeling Style Guide Junyu Peng Andreas Gerstlauer Rainer Dömer Daniel D. Gajski Technical Report CECS-TR-04-22

More information

2015 Paper E2.1: Digital Electronics II

2015 Paper E2.1: Digital Electronics II s 2015 Paper E2.1: Digital Electronics II Answer ALL questions. There are THREE questions on the paper. Question ONE counts for 40% of the marks, other questions 30% Time allowed: 2 hours (Not to be removed

More information

Lecture Notes on Programming Languages

Lecture Notes on Programming Languages Lecture Notes on Programming Languages 85 Lecture 09: Support for Object-Oriented Programming This lecture discusses how programming languages support object-oriented programming. Topics to be covered

More information

Contents Part I Basic Concepts The Nature of Hardware and Software Data Flow Modeling and Transformation

Contents Part I Basic Concepts The Nature of Hardware and Software Data Flow Modeling and Transformation Contents Part I Basic Concepts 1 The Nature of Hardware and Software... 3 1.1 Introducing Hardware/Software Codesign... 3 1.1.1 Hardware... 3 1.1.2 Software... 5 1.1.3 Hardware and Software... 7 1.1.4

More information

Semantics-Based Integration of Embedded Systems Models

Semantics-Based Integration of Embedded Systems Models Semantics-Based Integration of Embedded Systems Models Project András Balogh, OptixWare Research & Development Ltd. n 100021 Outline Embedded systems overview Overview of the GENESYS-INDEXYS approach Current

More information

VHDL Essentials Simulation & Synthesis

VHDL Essentials Simulation & Synthesis VHDL Essentials Simulation & Synthesis Course Description This course provides all necessary theoretical and practical know-how to design programmable logic devices using VHDL standard language. The course

More information