Network Interface Generation for MPSOC: from ... - CiteSeerX

Draft version

Network Interface Generation for MPSOC: from Communication Service Requirements to RTL Implementation Arnaud Grasset, Frédéric Rousseau, Ahmed A. Jerraya SLS Group, TIMA Laboratory 46 avenue Félix Viallet, 38031 Grenoble Cedex, France {Arnaud.Grasset, Frederic.Rousseau, Ahmed.Jerraya}@imag.fr Abstract To deal with the increasing complexity of electronic products, multiprocessor SoCs are more and more used. These systems are designed by composition of components communicating through a communication network, which means that some network interfaces should be inserted to adapt computation components with the communication network. This paper deals with the automatic generation of network interfaces by composition of hardware components. The goal of our methodology is to ease the HW/SW integration. This methodology starts from a description of the communication services the network interface has to provide. This model is then refined to an abstract model of the interface used to generate the architecture. An RTL model is then implemented.

1. Introduction Submicronic technology allows the integration on the same chip of µPs, IP, memories, shared bus ... Such a system is called Multiprocessor System-on-chip (MPSoC). To fulfill the integration of an increasingly large number of components on the same chip, design methods allowing the decoupling of communication and computations have been proposed [1][2]. The design of such a system is done by assembling reusable components, usually described at RT level. As the decisions taken early in the design process are of primary importance for the quality of the system, it is thus necessary to be able to quickly evaluate in an effective way the architectural decisions thanks to prototyping. The automatic architecture generation from a high-level system description frees the designer from the interface details required for the architecture design to focus on more valuable decisions (components allocation, communication synthesis). To connect all these components with the communication network, network interfaces are needed. As the communication becomes more and more complex [3],

the design of network interfaces is more and more difficult and has to be studied thoroughly. Moreover, their design is error-prone and time consuming. Their automatic generation is a challenge and would allow a better architecture exploration by reducing the time of a design/evaluation cycle. We propose a new methodology for the automatic generation of network interfaces from a communication service specification. Our flow is based on a flexible assembly of basic components thanks to the use of an abstract model of the network interface (NI). The goal of this work is to define the basic concepts and the different steps of a network interface generation tool. This tool is being developed. The paper is organized as follows. The second section presents the difficulties of the network interface design. The third section presents the NI specification. Then we propose our flow in the section 4.

2. Design of Network Interfaces 2.1 The problem MPSoC is composed by heterogeneous components in terms of: o implementation: HW or SW o type: computation or communication o protocols o physical interface: bus width, bandwidth, ctrl signals o clock domains: Globally Asynchronous, Locally Synchronous (GALS) The main design problem comes from their assembly. Network Interface design requires much designer knowledge (HW and SW implementation, HW/SW integration, protocols) involved in the system. As the communication should be adapted to the application, the NI has to be redesigned according to the application requirements (message-passing/sharedmemory communication model, high-bandwidth, lowlatency). So their automatic generation is of a particular interest.

Draft version

2.2 Related work The automatic generation of NI has already been studied and we can see two different approaches: by synthesis or by composition. The synthesis approach [4][5][6][7] uses a formal description of the interface (graph based or grammatical) and extracts from it a kind of FSM that could be synthesized after a translation in a HDL. These methods offer higher level of abstraction for the design of NI but they are either still manual, or they limit the interface generated to a point-to-point adaptation. We think that these methods are badly adapted to the GALS approach and to the realization of complex NI. The composition approach [8][9][10] uses component library and a composition tool. These methods take as input the system architecture. They are based on the selection, configuration and assembly of library components. The main drawbacks of this kind of methods are their need of huge libraries and their use of only one assembly model that constrains the design. In the computer network community, the ISO-OSI reference model [11] is the reference model for the communication description. [12] suggests a functionbased model to describe the communication with more flexibility and gives a methodology for its SW implementation. The automatic refinement of such models of communication services into an efficient hardware implementation of NI has never been treated to our knowledge. We think that the previous works are not sufficient to solve all the problems of their automatic generation, more especially as communication becomes more and more complex. In our opinion, the important problems are now: the HW/SW integration, the lack of flexibility in existing methods, the need of more efficient methods to support advanced communication services.

2.3 A composition approach We narrow our contribution to the network interface problem between processor and communication network. We choose a composition approach as we think that such an approach is better suited for the design of complex NI. The goals of our methodology are to: o target the NI to the requirements of the application o decrease the time for the realization of the libraries o decrease the time for the introduction of new components o support advanced communication services (MPI, …) o ease the HW/SW integration Our interface specification is a communication model which could also be used for the SW communication driver generation. The whole

communication system could be described with this model. To adapt to the application requirements, the critical point is the flexibility in the assembly of the components. The purpose of our work is the definition of a methodology for the selection and composition of library components in accordance with service requirements. Our method allows the use of different types of components and different assembly schemes.

3. Network Interface Specification 3.1 System specification In our methodology, the system is represented by a virtual architecture [1]. This model represents an abstract architecture which is composed of a set of virtual modules interconnected through a communication network (figure 1.a). Each virtual module consists of a module and its wrapper. From the module point of view, the wrapper represents an abstraction of the communications. The wrapper is composed of virtual ports. In our case, the module is a SW component which has to be connected to a RTL communication network. So a virtual port abstracts the communication drivers, the processor and the NI. virtual module

SW component

SW component

a)

b)

tasks OS Driver

Network Interface

tasks OS Driver

module virtual virtual port architecture

Communication Network

µP1

wrapper

µP2

Network Interface

Physical Communication Network

RTL architecture

Figure 1: adopted design flow

3.2 Refinement principle Figure 1.b shows the system refined at the RT level. The SW components are refined in a set of application tasks running on a processor. The wrapper is refined in a SW part and in a HW part. The SW part corresponds to the Operating System and communication drivers. The HW part is the network interface. The objective of the NI refinement is to produce a synthesizable model at the RT level.

3.3 Network interface specification The virtual ports are specified with a communication model as described in [12]. The virtual ports have to offer the services required by the application dealing with the available services of the

Draft version

network. The specification of the virtual ports is composed of protocol functions (figure 2). Each protocol function requires and provides services. A service is a set of functionalities provided by a protocol function to another protocol function. A protocol function is a functional component. It can be implemented in HW or in SW. Application virtual port

VP1

VP2

ASFIFO in

ASFIFO out

SW

µP protocol function service request

medium access

FIFO medium access

hndshk in

HW: NI Specification

hndshk out

Communication network

Figure 2: virtual port specification

The protocol functions realize a set of operations defining the communication protocol. The protocol is a set of rules for the transfer operations and the exchanged data format. A service indicates what a protocol function could do for another protocol function (e.g. transfer a message). The protocol function defines how it is done (synchronization, data format …). The objective of each protocol function is to offer services to other protocol function without they know how they are realized. So the service and the implementation are completely decoupled. Our motivation for the use of such a model is to ease the system design by allowing a clear decoupling between the computation and the communication, and between the HW and the SW. The virtual port VP2 on the figure 2 is an example of a specification for a point-to-point communication by the intermediary of a FIFO. The ASFIFO out protocol function indicates that we use the ASFIFO protocol. This protocol function uses a FIFO which enables the sender/receiver synchronization. The medium access protocol function is responsible of the physical data transfer on the communication network. The specification of the virtual ports contains the list of the operations that the virtual ports have to do to fulfill the communication service requirements. These virtual ports are implemented both in SW (communication drivers) and in HW (NI). For the moment, the designer has to decide the set of the protocol functions that are implemented in SW and in HW. The set of the protocol functions implemented in HW represents the NI specification. This specification does not make any assumptions on the design of the NI. As we use a composition approach, some library components are selected and assembled to generate the NI from the NI specification. It is detailed in the next section.

4. Network Interface Generation Flow 4.1 Our design flow Our goal is the design automation of the NI. Our flow is based on four models and three steps (figure 3). The first refinement called functional analysis transforms the NI specification into an abstract network interface. To enable a better selection and a better assembly of the components, the abstract network interface is more appropriate than the NI specification. The second step generates the architecture of the system. The goal of this step is to explore the design space. It enables the method to generate several architectures. The implementation step selects and configures the RTL components taken from a library. By using libraries, we can generate NI with different architectures. The architecture is mainly limited by the functional analysis step (which keeps the same structure between NI specification and abstract NI) and by the availability of components in the library and their compatibility. So the NI is constrained by the specification, and we can only explore a limited range of possibilities. Another limitation is due to the link between the three libraries. Indeed, one protocol function may correspond to several generic components, and a generic component has at least one RTL implementation. This makes their design difficult as we are supposed to know the content of all libraries. NI specification functional analysis

Protocol Function components

abstract NI architecture generation

generic components

architecture

implementation

RTL components

RTL Network Interface

Step Model Library

Figure 3: our generation flow

4.2 The different steps The NI specification describes the communication requirements without assumptions on its HW design. The functional analysis refines it in an abstract network interface. The abstract NI defines the basic operations (address translation, error detection, arbitration…) required to realize in HW the protocol functions, and the link between basic operations. Each elementary operation is described as an abstract component. Its

Draft version

behavior is known. As the resource allocation has not been done yet, these basic operations are named abstract components. The communication between abstract components is decided. The functional analysis lists the abstract components in order to respect the NI specification. The functional analysis has to be done accordingly to the quality of service required. The abstract interface model is useful for an efficient selection and composition of the HW library components. The architecture generation maps the different abstract components of the abstract NI on an architecture. To do this we need to assign the abstract components to generic components and to generate the interconnect topology between generic components. The protocol, the clock and reset signal are still abstracted. A generic component is a component which the behavior and the ports are fixed but not yet implemented. This step does architecture exploration. The third step of the flow is the implementation which generates a synthesizable RTL model of the network interface. For each generic component, a RTL component is selected in a library of RTL components and then configured accordingly to the application (bus size, FIFO size …). These components are then assembled. The selection must be made in order to have compatible components in terms of protocol, physical ports and of clock domains. With our methodology, a tool should select automatically RTL components to obtain the best trade off between the cost (area) and the performance (critical path). As a result, the designer does not need to know all the implementations available.

4.3 Library needs The presented methodology uses three libraries but we hope that the time for the realization of these libraries will be acceptable. By enabling more flexibility in the selection and assembly of components, the method enables to use smaller components which can be easily reused. As components are smaller, the time to add a component is shorter. By improving the library component reuse, the size of libraries may be fair. As the interface is composed of many different components, the realization of compatible components is an important point which is difficult. The clear breaking down of the flow in three steps eases the design of libraries. Indeed, one can design some generic components even if one does not know which protocol it is used for. It is also possible to model protocol function without to know the RTL components available.

4.4 Status of the work We are working to develop a tool to automatically generate the NI starting from the NI specification. The architecture generation and the implementation could be largely automated but the functional analysis may require more decisions from the designer.

5. Conclusion In this paper, we presented a methodology for the generation of network interfaces. Our contributions are the use of a communication model as specification and a design flow which separates the most important steps. The methodology and the use of library components give a huge flexibility in both the NI architecture and RTL implementation. This method seems promising with advanced communication schemes.

6. References [1] W. Cesário and all, “Component-Based Design Approach for Multicore SoCs”, DAC’02, USA. [2] J. A. Rowson, A. S.-Vincentelli, “Interface-Based Design”, DAC’97, USA. [3] L. Benini, G. De Micheli, “Networks on Chips: A New SoC Paradigm”, IEEE Computer, vol. 35, January 2002. [4] J. Öberg, and all, “Grammar-based design of embedded systems”, Journal of Systems Architecture, Elsevier, vol. 47, n° 3-4, April 2001. [5] A. Seawright and all, “A System for Compiling and Debugging Structured Data Processing Controllers”, Euro-DAC, Geneva, Switzerland, 1996. [6] R. Passerone, J. A. Rowson, A. S.-Vincentelli, “Automatic Synthesis of Interfaces between Incompatible Protocols”, DAC’98, USA. [7] B. Lin, S. Vercauteren, “Synthesis of Concurrent System Interface Modules with Automatic Protocol Conversion Generation”, ICCAD, San Jose, USA, 1994. [8] D. Lyonnard, S. Yoo, A. Baghdadi, A. A. Jerraya: “Automatic Generation of Application-Specific Architectures for Heterogeneous Multiprocessor System–on-Chip”, DAC’01, USA. [9] D. Hommais, F. Pétrot, I. Augé, “A Practical Toolbox for System Level Communication Synthesis”, RSP, Copenhagen, Denmark, 2001. [10] S. Vercauteren, B. Lin, H. De Man, “Constructing Application-Specific Heterogeneous Embedded Architectures from Custom HW/SW Applications”, DAC’96, USA. [11] A. S. Tanenbaum, Computer Networks, Prentice Hall, 1996. [12] M. Zitterbart, B. Stiller, A. N. Tantawy, “A Model for Flexible High-Performance Communication Subsystems”, IEEE Journal on Selected Areas in Communications, vol. 11, n°4, May 1993.