Light-weight Communication Infrastructure for IP Integration

By J. Barba, F. Rincón, F. Moya, F.J. Villanueva, D. Villa & J. Carlos López
University of Castilla-La Mancha
School of Computer Engineering
Ciudad Real, Spain

Abstract:

We present an interface generation scheme based on high-level object oriented models. The novelty of our approach is the definition of a hardware object model that reduces the gap between system specification and implementation. This simplifies the synthesis process since there is no need of redefining module interface in each design step.

Along with the object model, a bus/network independent communication mechanism is proposed to access modules functionality. It is based on the technology succesfully used in software middlewares for decades. The use of RMI semantics effeciently decouples behaviour from communication and enables the automatic generation of and optimal communication infrastructure.

1 INTRODUCTION

Interface synthesis is one of the key steps in SoC design. Frequently, the high level abstraction models used to specify such systems do not have a straight correspondence with the final implementation of the communication mechanisms between them. This is specially critical for hardware components.

Thus, a refinement process is then needed to overcome the gap between system specification and system implementation. All the semantics captured at system level vanish in this process forcing the designer to define once again the modules interfaces. To avoid this situation two alternatives are possible: (a) including low level interface information in system models making them unsuitable for later reuse (for example, due to a change in the communication protocol used by a IP) or (b) raising the level of module interface abstraction making use for example, of operations instead of signals, ports, etc.

In this work, a solution to the interface synthesis problem, based on object oriented models of the IPs to be integrated, is presented. The system is modelled as objects that interact each other through the use of methods. A method is the entry point to the object functionality. The benefit of considering IPs as objects is twofold since (a) it keeps the system model invariable and (b) it establishes clear semantics for communication enabling module interchange and reuse.

1.1 RELATED WORK

The application of object-oriented techniques to the design of hardware systems has mainly found three working lines: (a) the adoption of software object-oriented programming language concepts by hardware description languages, (b) the use of object-oriented modelling techniques in systemlevel design and (c) the development of hardware components that implements software objects behaviour.

OO-VHDL is an example of the former. The improvement of the productivity is achieved by the reuse of previous code making use of concepts such as inheritance, encapsulation and polymorphism. However, there is not a clear correlation between the concept of object (and all the characteristics that it implies) and a hardware implementation. This conceptual gap (Damasevicius et al [1]) is one of the reasons that has motivated a slow (though progressive) acceptance of these techniques in hardware design.

Figure 1. The interface synthesis process in detail.

Regarding system-level design, SystemC provides hardware-oriented constructs within the context of C++ as a class library implemented in standard C++ to develop hardware systems. The use of UML for system level design has been proposed in [2,3], while [4] deals with the synthesis process from an object-oriented specification.

Several implementations of software objects have been proposed in the literature. Radetzki [5] establishes a hardware object architecture based on a memory plus some control logic for state transition. Goudarzi and Hessabi [6] implements hardware object with support for inheritance and polymorphism. Cheng and Wu [7] analyses four implementation strategies for software objects in hardware based on an data-memory mapping analysis. Our work does not propose any hardware object implementation but a general hadware object model at module interface level to easily embrace current and future object hardware implementation strategies.

The works mentioned above do not consider the problem of communication between hardware objects. We focus on how to implement an efficient communication infrastructure for a system modelled as a set of objects that interchange messages [8].

Figure 2. Object diagram of a simple real-time image processing application

The need of wrapper modules that make it possible the connection of components using different communicating mechanism is a recurrent problem in hardware design. We take advantage of the special characteristics of a hardware objectbased system to simplify the generation of such adapters.

2 INTERFACE SYNTHESIS PROCESS.

Figure 1, shows the workflow of the proposed interface synthesis process. The inputs to this process are the Object Diagram and the Collaboration Diagram of the system to be implemented. Both diagrams make use of the UML (Unified Modeling Language) notation to represent the structural aspects of the system and the relations between the objects that are part of the system.

A textual representation of these diagrams is then analysed to extract only that information relevant to the wrapper generator tool. Before the generation of RTL code, the designer must select a concrete scheme of communication (bus, network, etc.) from a set of predefined mechanisms. Finally, a wrapper generation process specializes and optimizes a wrapper template that depends on the communication method previously selected, the number and type of operations that it must support, etc.

2.1 OBJECTS AND COLLABORATION DIAGRAMS : MODELLING THE SYSTEM.

An object diagram shows how classes interact whit each other at run time. Thus, the relation between the instantiated classes (objects) in the logical view of the system is exposed. Each object appearing in the object diagram represents a hardware component and a class is a type of component. All objects belonging to a class share the same interface. A collaboration diagram describes interactions among these hardware components in terms of sequenced messages for a concrete use case. No information about communication implementation details is given at this level so the system model is highly suitable for

Figure 3. Collaboration diagram of the image transformation process.

later reuse. Figure 2 represents a simplified version of the object diagram of a simple real-time image processing application while figure 3 shows the collaboration diagram for the normal use case in our system.

Notice that what differences our approach with respect to other related work is the absence of a interface specification phase [9]. This prevents the designer to perform a non negligible amount of work comprising, for example, protocol specification.

2.2 IPS AS OBJECTS.

To reduce the gap between system specification and the final implementation we propose a direct mapping of the concepts of the object model instead of applying several refinement steps. As stated previously, a system is modeled as a set of objects that communicate through message passing. In the logical view an object provides just some per-instance private state data (attributes) and an encapsulation mechanism for some functionality (methods). A method is defined as an operation name and optionally some parameters and/or a return value.

To implement logical objects as physical hardware components, we define: (1) a standardized interface in order to automatize the generation of wrappers and (2) a synchronous method invocation protocol. A hardware object exhibits a characteristic physical interface: common system signals (clock, reset, etc.), one input signal per method to activate it, one output signal per method to notify the end of an operation (this is used for synchronization purposes) and several input/output data ports (a data port is a set of related input/output signals).

One of the main features of our hardware object model is the flexibility to define how values are passed/retrieved to/from the IP. This makes it easier to fit the final implementation to particular design constraints or to adapt existing IPs. By default, each method parameter is bound to a data port. If the data port width is not enough to transport the parameter value in parallel, a serial protocol is then automatically selected. This can be useful, for example, in operations with vectors. But the designer is free to pack two or more method parameters to a data port saving input/output lines.

The method invocation mechanism starts with the activation of the input signal associated with the operation to be initiated. In the same cycle, the pass of parameters must start. The number of cycles this process lasts, and in which cycle each parameter is ready to be utilized by the hardware object are known at design time. Our hardware

Figure 4. Input Buffer as a hardware object (a) and call mechanism for set (b) and get (c) methods.

object model defines a data type system in order to assure inter-component communication semantics as in [10]. Finally, if the method produces a result, it is placed at its corresponding output data port and the associated synchronization signal must be asserted to notify that the operation has concluded.

Figure 4 illustrates one of the possible module interfaces for the object Input Buffer and the derived timing diagrams representing how method invocation takes place for put and get operations.

2.3 REMOTE METHOD INVOCATION

At this point, what we have is a flexible, standardized interface for hardware objects plus the semantics that defines how to access its functionality. This assures interoperability and IPs can be interchanged in a design without affecting other IPs that communicate with them. For the same reason, we are able to automatize the creation of the communication infrastructure. The invocation mechanism briefly described above, is an example of how an IP could interact “locally”. By “local”, we mean an invocation made by an IP directly connected to the hardware object.

However, this is not the main scenario in current SoC: hardware components communicate through a system bus or network. Therefore, it is mandatory to have a way to “remotely” invoke object methods. By “remote”, we mean an invocation that takes place between two hardware objects connected to a system bus or network. The hardware object that initiates the invocation is called client and the target object is called server.

Ideally, the client-server communication should be (1) independent of location and (2) independent

Figure 5. Actors in a Remote Method Invocation

Figure 6. Proxy Template

of the interconnection media. Independent of location means that there is no difference whether the invocation is remote or local. Therefore, the hardware object does not have to change either its interface or its method invocation protocol implementation.

To achieve these goals, we embrace the architectural solution present in commercial software middlewares [11]. Figure 5 depicts the main elements that take part in a remote method invocation. Each method invocation must take place between a proxy and a skeleton. Actually, proxies and skeletons are not merely bus/network wrappers that isolate clients and servers from the interconnection infrastructure.

From the client point of view a proxy is seen as a private object implementation. It provides exactly the same physical interface. Consequently, the client can start the invocation of a method as usual (step 1 in figure 5). The proxy forwards the request to the servant through the communication bus/network dealing with the specific protocol and timing requirements (step 2). The servant does the reverse process (step 3) and completes the process doing the actual method invocation on the server (step 4).

Both proxies and skeletons must agree in how local invocations are translated into a sequence of low level actions over the bus or network to activate the execution of a method. Also, some data encoding/decoding rules have to be defined in order to homogenize how data types are sent “on the wire”. These two items comprise the remote protocol definition. A method call is decomposed into write and read primitives. Read and write are basic services offered by any of the buses and onchip networks, so that the complete process can be easily targeted to a concrete implementation. Each hardware object in the system has a unique identifier. Actually, this identifier corresponds with the base address of the module implementing the skeleton. Each method has an address within the address space reserved to the hardware object. This address is coded in the proxy and must be used as argument in write and read operations.

2.5 WRAPPER GENERATION

The last step in our interface synthesis process is the generation of proxies and skeletons, the hardware object wrappers. The function of proxies and skeletons is to serve as adapters between the local and remote protocols. We have defined two interface templates [12] which will be specialized according to the bus/network selected by the designer and the number and kind of methods to be interpreted.

Figures 6 shows the general architecture of a proxy. The most important modules are the Port Acquisition Units (PAU) and the Port Delivery Unit (PDU) that are responsible for the adaptation of the data received (IP or bus) according the local method invocation mechanism imposed by the hardware object interface. The Combinational Adaptation Logic (CAL) translates the control signals into bus/network specific commands and viceversa. The correspondence between FSM signals and bus control signals is defined separately in system configuration files. The Control Logic implements the FSM doing the local and remote protocol adaptation. Eight parameterized VHDL design modules has been developed (one for each case and actor in the communication).

Based on the relationship information provided by the object and collaboration diagrams, a skeleton is produced for each hardware object exporting at least one method. Only for each method that has to be remotely invoked by the client, a proxy to the target (actually, the skeleton) is generated. This reduces the logic used in the proxy since there is no implementation for unused methods. Another optimization introduced in this process is the reutilization of logic when two method definitions and their corresponding physical hardware object interfaces are identical.

3 EXPERIMENTAL RESULTS

To validate the concepts presented in this work, we have implemented a little image filtering application. There are only three objects involved: the one requiring the filtering, the filter object itself and an iterator object used by the latter in order to get the pixels of a certain image. Despite of the simplicity of the example, it is straightforward to extend it to much more complex systems.

The SoC described above has been implemented on the Xilinx XUP-V2Pro platform. We have also tested two different transport infrastructures: (1) the OPB bus which is available in the board, (2) a 3 switches NoC synthesized from a xpipes description. From the experiment we can conclude that the transport architecture can also transparently be replaced. It only requires to resynthesize the corresponding proxies and skeletons using another transport protocol. A software version of the filter object and the proxy to the iterator has been tested. SW to HW communication takes place transparently between the filter and the iterator since the latter keeps exactly the same interface. On the other hand the hardware implementation of the iterator is not able to distingish whether the invocation came from a SW or a HW object.

In order to evaluate the overhead introduced by proxies and skeletons, we have defined and implemented the simplest hardware object with two methods (get_value and set value). In table 1, the synthesis results are shown for two alternatives: (1) using the IPIF wrapper generator from Xilinx tools and (2) using our proposed architecture and design flow.

Table 1. Proxy and Skeleton area results

4 CONCLUSIONS AND FUTURE WORK

We have described an implementation strategy of a light-weight communication infrastructure for systems that are modelled as communicating objects. This infrastructure is independent of the underlying bus/network that relates all the components in the system. We have implemented all the presented concepts in a FPGA-based system.

The principal features of our interface generation process are: (a) it is done in an automatic way, with a minimum participation of the designer, (b) it is flexible since it is extremely easy add new target technologies.

Future works are being focused on developing an asynchronous (non-blocking) method invocation mechanism for high latency operations. Transparent and efficient SW to HW and HW to SW communication based on object-oriented concepts is another of the work in progress that will lead us to a real co-design object-oriented design methodology based on concepts as locations transparency and access transparency.

5 REFERENCES

[1] R. Damasevicius, G. Majauskas and V. Stuikys. Application of design patterns for hardware design. In Design Automation Conference, Jun 2003.

[2] R. Chen, M. Sgroi, L. Lvagno, G. Martin, A. Sangiovanni-Vicentelli, and J. Rabaey. Embedded system design using UML and platforms. In Forum on Specification and Design Languages (FDL), Marseille, France, September 2002.

[3] Q. Zhu, A. Matsuda, S. Kuwamura, T. Nakata, and M. Shoji. An object-oriented design process for system-on-chip using UML. In International Symposium on System Synthesis (ISSS), pages 249-254, Kyoto, Japan, September 2002.

[4] C. Schulz-Key, M. Winterholer, T. Schweizer, T. Kuhn, and W. Rossenstiel. Object-oriented modeling and synthesis of system specifications. In Asia South Pacific Design Automation Conference (ASPDAC), pages 238-243, Yokohama, Japan, 2004.

[5] M. Radetzki. Synthesis of digital circuits from object-oriented specifications, Ph.D. Thesis, Univerisität Oldenburg, Germany, 2000.

[6] M. Goudarzi, S. Hessabi. Synthesis of Object- Oriented Descriptions Modeled at Functional- Level. World Scientific and Engineering Academy and Societ Transactions on Computers, Athens, 2003.

[7] Fu-Chiung Cheng, Hung-Chi Wu. Design and Implementation of Software Objects in Hardware. In International Conference on Computer Design (ICCD), Oct 2006.

[8] P.G. Paulin et al. Distributed Object Models for Multi-Processor SoC's, with Application to Low-Power Multimedia Wireless Systems. In Design Automation Conference, Mar 2006.

[9] A. Rajawat, M. Balakrishnan, A. Kumar. Interface Synthesis: Issues and Approaches. In Proc. Of the International Conference on VLSI Design, 2000.

[10] K.V. Rompaey, D. Verkest, I. Bolsens and H. Man. CoWare- A design environment for heterogeneous hardware/software systems. Design Automations for Embedded systems, 1(4), 357-386, 1996.

[11] M. Henning and M. Spruiell. Distributed Programming with Ice. Available at: http://www.zeroc.com/ice.html

[12] Yin-Tsung Hwang and Sung-Chung Lin. Automatic protocol translation and template based interface synthesis for IP reuse in SoC. In Proc. Of the 2004 IEEE Asia-Pacific Conference on Circuits and Systems, 2004.

* This work was supported by the Spanish Ministry of Education under Grants TIN2005-08719 and by Junta de Comunidades de Castilla-La Mancha under Grants PBI-05-049, and PBC-05-009.