Service Dependency Graph, an Efficient Model for Hardware ... - cs.York

Service Dependency Graph, an Efficient Model for Hardware/Software Interfaces Modeling and Generation for SoC Design Adriano Sarmento, Lobna Kriaa, Arnaud Grasset, Mohamed-Wassim Youssef, Aimen Bouchhima, Frederic Rousseau, Wander Cesario, Ahmed Amine Jerraya TIMA Laboratory, SLS Group 46, avenue Felix Viallet Grenoble CEDEX 38031 France

{firstname.surname}@imag.fr available one can try to apply also automatic model refinement techniques [2][3] to reduce further the design time. In this paper, we concentrate on model generation techniques for SoC design.

ABSTRACT Complex systems-on-chip are designed by interconnecting predesigned hardware (HW) and software (SW) components. During the design cycle, a global model of the SoC may be composed of HW and SW models at different abstraction levels. Designing HW/SW interfaces to interconnect SoC components is a source of design bottlenecks. This paper describes a service-based model enabling systematic design and co-simulation of HW/SW interfaces for SoC design. This model, called Service dependency graph (SDG) allows modeling of complex and applicationspecific interfaces. We present also a model generator that can automatically build HW/SW interfaces based on service and resource requirements described by the SDG. This approach has been applied successfully on the design of an MPEG-4 encoder. Additionally the SDG seems to be an excellent intermediate representation for the design automation of HW/SW interfaces.

Figure 1 shows a simplified design flow starting with a high-level system specification that is refined to RTL. It starts with a functional decomposition of the system as shown in Figure 1a. Computation is specified by implementation-independent functional models and communication uses message-passing interfaces (MPI [4]). : component

: execution

environment

Instruction-set simulator SW1

: interface

S1 SW1 S1 S2

F1

F2

MPI execution environment

Categories and Subject Descriptors

(a)

C.3 [Special Purpose and Application-Based Systems]: Realtime and embedded systems, Microprocessor systems.

High-level SW execution environ.

F3

S2

Middleware SW execution environ. Instruction-set execution environment

H3

…

H3

…

TL bus model execution environment (b)

RTL bus model execution environment (c)

Figure 1. (a) Functional model, (b) Transaction-level model, (c) RTL co-simulation model In a later design step, some architecture decisions are made (see Figure 1b), such as selecting the bus to interconnect subsystems, and the HW/SW partitioning. HW and SW subsystems may interact by exchanging transactions through a Transaction-level bus model (TLM [5]). Inside the SW subsystem, sequential execution and communication are ensured by a high-level SW execution environment. In order to execute this SoC model, two types of interfaces are required: one to access the SW execution environment and the other one to access the TL-model of the bus.

General Terms: Design, Experimentation. Keywords: Systems-on-Chip, Hardware/Software interfaces, Service-based model, Interface design automation.

1. INTRODUCTION The complexity of systems-on-chip (SoCs) makes component reuse mandatory. The design difficulty is shifting from component design to component integration, mainly due to the heterogeneity of these pre-designed components. The use of standardized component interfaces is very difficult in practice and can only lead to efficient solutions for a restricted domain of applications. Another solution is to use pre-defined, customizable architecture platforms [1]. However, the efficiency of the solution depends on the suitability of the platform for the application. In the case where the application imposes performance/cost constraints, a design customization is required. Doing it manually induces a design time overhead that is not compatible with SoC time-to-market constraints. Automatic model generation can help to design SoCs that comply with both time-to-market and performance/cost constraints. Ideally, once model generation is

In a further design stage, the system is refined to RTL (see Figure 1c). SW components have to be adapted to run over a middleware execution environment, on top of an instruction-set execution environment. The bus model is refined to RTL, so there is a need for different interfaces for the HW subsystem. In order to execute this global RTL SoC model, three types of interfaces are required: one to access the middleware SW execution environment, a second one to access the instruction-set execution environment and a third one to access the RTL-model of the bus. As shown in Figure 1, designing interfaces for SoC design is a difficult and time-consuming task. Moreover, these interfaces must be efficient and must respect cost constraints. This paper proposes a unified model to represent all these kinds of interfaces, called Service-Dependency Graph (SDG). This model is based on the concept of services, an interface is specified using the set of services it requires and provides. The general goals for this model are: (1) handling heterogeneous components at different

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CODES+ISSS’05, Sept. 19–21, 2005, Jersey City, New Jersey, USA. Copyright 2005 ACM 1-59593-161-9/05/0009...$5.00.

261

which impact system efficiency. This may also limit the flexibility by requiring greater efforts from the designer if changes are made.

abstraction levels; (2) being independent of specific “standards”; (3) hiding details and delaying decisions by using abstract models; (4) allowing different and sophisticated adaptation schemes; (5) allowing automation for application-specific (and/or target architectures) interfaces. In this paper, the SDG model is the input of a model generator that can automatically build component interfaces based on the services and resources requirements stated in the interface model. The main contributions of this work are: -

The use of a flexible interface representation to describe a large class of interfaces (HW, SW or Functional). This unified model allows to perform extra optimizations and architecture exploration by using trade-offs when partitioning interface implementation between HW and SW.

-

The interface model has a high abstraction level; it imposes neither the communication architecture nor the implementation style, thus it can easily be adapted to different standards.

CoWare [14] proposes an interface composition method that uses a static communication graph based on master-slave communication, restricting the target architecture to a single processor. More recently, this architecture was extended to handle multiple processors using a system bus, which is based on AMBA bus, thus limiting the utilization of user-defined interfaces. Zitterbart [15] proposes a service-based interface composition method well suited for embedded SW used in telecommunication systems. The goal of our work is to generalize it and apply it for SoCs. Thus, we propose a unified, abstract, service-based interface model targeted specifically to solve the problem of component integration for SoC Design.

3. SERVICE-BASED ABSTRACT INTERFACE MODEL Different subsystems may manipulate different communication concepts (protocols, abstraction levels, etc.). Figure 2a represents these concepts as APIs (Application Programming Interface). Our focus is on modeling interface adaptation between different communication-APIs while respecting design constraints. Additionally, this modeling should ease architecture exploration and systematic design of adaptation interfaces.

-

Automatic generation of efficient interface might be possible because each interface implements the minimal set of required services. Thus, it is possible to avoid the overhead due to unnecessary service implementation. This paper is organized as follows: section 2 discusses related works, section 3 explains the SDG model, section 4 describes a model generator for building service-based abstract interfaces, section 5 presents a case study that shows how this model can be used to build abstract interfaces for an MPEG-4 encoder and section 6 gives our conclusions.

Subsystem1

Subsytem 2

API

API

Abstract Interface

Abstract Interface

API

2. RELATED WORKS

API

P1

…

PN

Internal Ports

P’1

…

P’M

External Ports

Execution Environment

The literature includes many works related to HW, SW and functional interfaces; they can be classified in three categories: bus-based, standard interfaces-based and composition methods.

(a)

(b)

Figure 2. a) Abstract SoC Architecture b) Abstract Interface Our approach consists first in abstracting the way we adapt these APIs by using the concept of abstract interfaces (see Figure 2b). Then we provide a model for adapting different APIs. This model is called Service Dependency Graph (SDG) model and its components are defined by a set of well-delimited atomic units that we call interface elements (or elements in short) that provide services. We can mix and match these elements to implement the required API adaptation.

IBM CoreConnect [6], ARM AMBA [7] and Vercauteren et al [8] are bus-based approaches in which subsystems communicate through one or more fixed buses protocol. They offer component libraries, specialized development and simulation environments for designing systems around these buses. These approaches are well suited for a restricted set of communication protocols. VCI [9] and OCP [10] are standard interfaces-based design approaches in which subsystems are components that are compliant to a bus-independent and standardized interface and can be directly connected to each other. These subsystems may also be interconnected through a bus, in which case standard abstract interfaces can adapt the subsystems interfaces to the bus. Sonics [11] and StepNP [3] follow this later approach, proposing abstract interfaces to adapt the bus-independent OCP-based socket to the µNetwork bus and STBus respectively. These approaches may limit the flexibility of the system by requiring that the different subsystems have standard interfaces.

3.1 Abstract Interfaces An effective way for representing heterogeneous systems is given by the concept of abstract architecture [12] as shown in Figure 2a. The key idea behind this concept is to abstract subsystems’ interfaces and system interconnects. The system can be represented as a set of subsystems wrapped in abstract interfaces and connected through an execution environment. This execution environment is an abstract entity that can be a co-simulation bus, NoC, or any data transport model. An abstract interface (see Figure 2b) can be viewed as a hierarchical port that is divided into two parts: one related to the subsystem interface (ports P1 … PN) and the other one related to the execution environment interface (ports P1 … PM). This abstract interface enables subsystems communication by adapting subsystems interfaces to the execution environment interface.

In COSY [2], interfaces are composed of communication elements that are in a library. These elements can be implemented in HW or SW. Cesario et al [12] provide different tools for generating HW/SW/Functional interfaces. Different models are used for generating each type of interface. Abdi et al [13] propose a way for integrating heterogeneous subsystems by using an abstract interface. In these approaches, the coarse granularity of the library elements may provide unnecessary functionalities,

An abstract interface specifies a set of provided and/or required services for different purposes: synchronization, data conversion,

262

arbitration, etc. By abstracting interfaces and interconnects, no restriction is made about their implementation. This work proposes a service-based model to implement abstract interfaces. Then, we present examples of different implementations of abstract interfaces. These examples were generated from the design of the MPEG-4 encoder discussed in section 5.

Subsystem API P1

…

PN

SSP

Abstract interface

S1 E1

Requires Service

SAP

Provides Service

Port Access

E2 Execution environment Port

3.2 Service Dependency Graph Model

S5

Subsystem Port

S6

We define a service-based interface model as two sets of logical ports (subsystem ports and execution environment ports) connected through a Service Dependency Graph (see Figure 3).

P1

…

PM

Interface element

EEP

Service

Execution environment API

Figure 3. Elements/Services Relationship

A logical port may hold a list of services and it may be hierarchical (i.e. may have sub-ports). A service defines a function or a communication primitive. Each service may be provided by one or more interface element. The set of services constitutes what we call the port communication APIs.

One restriction of this model is that when defining an element, service accesses through SAPs or Port Accesses should be explicitly differentiated as presented in the next sections examples.

An interface element is an atomic unit that provides and/or requires one or more services. It may have one or more HW or SW implementations. Elements require/provide services through:

3.3 Implementing a Functional Interface Figure 4 shows the implementation of a functional interface. We consider a functional subsystem and an execution environment having communication APIs at different abstraction levels. The interface of Subsystem has two ports (Pdata and Padr) described at RTL (the services provided are Read and Write value on these ports). These two ports are part of a hierarchical port P that requires a service called GetData. The execution environment interface has only one port described at TLM (P’). The service provided by this port is the ReadAdr.

-

Service Access Points (SAPs) – for services implemented by another element; Port Accesses - for services implemented by a logical port (for instance, in Figure 3, when E2 request S6 that is provided by the logical port EEP ). A node of the SDG can be a logical port, a service or an interface element. The arcs in the SDG define the dependency relation between logical ports or interface elements and services. A dependency relation exists when a logical port or an interface element requires or provides a particular service. In the example shown in Figure 3, port SSP requires service S1 through a SAP, S1 is provided by element E1 which requires service S5. Then S5 is provided by E2, which in turn requires service S6 (through a port access) provided by port EEP.

Subsystem Interface (RTL) Write Pdata

Padr

Read

void NetworkAccessProvider::GetData { while(true) {

P

bit8 a = Padr .Read(); int adr = Converter.DataConv(a);

GetData

int data = P’.ReadAdr(adr); Network Access Provider

Adapting different communication APIs is made by composing interface elements. The composition must ensure that all services required by the subsystem are provided by the interface elements. Adaptation, then, can be modeled as a SDG representing the functional decomposition of the overall adaptation function. The SDG model does not impose any implicit order of service processing. As an example, if an element requires two services, these two services may be executed in parallel depending on their implementation. Another important point is that the final interface implementation provides only the services required in the SDG. This feature reduces unnecessary overhead in the adaptation.

Wait Synchronizer

bit32 d = Converter.DataConv(data); Pdata.Write(d);

DataConv

Synchronizer.Wait(); Converter

ReadAdr P’ Execution Environment (TLM)

} }

Port Access

SAP

Figure 4. Example of Functional Interface Implementation Service GetData is provided by NetworkAccessProvider. This element requires five services: DataConv (for data conversion), Wait (to synchronize the data access), Read (to read the address), Write (to write the value back to the subsystem) and ReadAdr (to read data from the execution environment). The first two services are provided respectively by Converter and Synchronizer through SAPs, while the last three services are provided respectively by ports Padr , Pdata and P’ through Port Accesses.

Additionally, the SDG model eases design exploration, first by not restricting the kind of implementation (SW or HW) and second by its fine granularity. Changing a communication API or the kind of implementation (HW, SW or Functional) does not imply in a great effort for changing the adaptation. In this case, one needs to describe a new SDG, or create some new elements if new services are required. The proposed model is flexible enough to deal with a wide application domain. As elements’ implementations can be functional, SW or HW. This is the key point to be able to generate HW/SW/Functional interfaces using the same model.

The right side of Figure 4 shows how service GetData provided by NetworkAccessProvider is implemented. Notice the difference between service invocation for Port Accesses (call of a port’s method) and SAP’s (call of an element’s method). This is necessary to guarantee that some services will be provided by elements having ports. This characteristic assures that this model can be used either by SW elements or by HW elements.

3.4 Implementing a SW Interface The SDG model can be employed to implement a SW-only interface as shown in Figure 5. The SW subsystem

263

communication API requires blocking I/O operations for accessing a video memory bank (details are given in section 5). The service required by this subsystem is the ReadAdr. As this subsystem must communicate with the rest of system through the processor bus at RTL (the execution environment), adaptations are required.

Processor Bus Interface (RTL) PdataIn

Padr P

PRW

Pdata

Padr

32 bits

NWInterfaceWrite

Pdata

PRW

NW InterfaceWrite

32 bits

Padr

(Port Access)

PRW

Addr_Decoder Addr_Decoder

Penable

Count

ReadAdr is provided by DeviceDriver, which requires four services: Block (to stop task execution), UnBlock (to resume task execution), Low_Read (for a low-level read from a given address) and Ok_Read (to know if a read is possible). Block and UnBlock are provided by Synchronizer. It requires service CxtSwitch for performing task context switch. This service is provided by Scheduler. Notice that all these services are accessed through SAPs. Low_Read and Ok_Read are provided by LowIOProvider. This element requires three services: DataConv (for data conversion), EnRead (to read data from a RTL port), and Write (to write the address to a RTL port). While the first service is provided by a SW element, the other ones are provided by HW ports.

Penable

Counter

Counter Put

2 bits

FIFO

Pdata’

Pdata’

FIFO Write Pdata1”

Pdata1”

Write Pack1

Execution Environment (RTL)

2 bits

Pdata1’’

Figure 6. Example of HW Interface Implementation

4. MODEL GENERATOR FOR BUILDING INTERFACES In this section, we present an automatic model generator for building interfaces based on the SDG interface model (see Figure 7). The flow for this generation is composed of:

SW API (TLM)

-

HW/SW/Functional Interface Analyzers – Tools that are in charge of reading the specification and analyzing which adaptations are necessary to enable communication. Depending on the nature of the interface, a different analysis is performed. For instance, the processor type may be relevant for deciding the implementation of HW and SW interfaces, but not for Functional interfaces. So an interface analyzer should be implemented for each kind of interface. HW/SW/Functional Resource Libraries – For each kind of interface, there is a specific library that contains all elements and services definition as well as their implementation. SDG Generator – Tool that generates the elements/services dependency graph for the required adaptation. As HW/SW/Functional interfaces are modeled in the same way (SDG model), this tool may be employed to generate them. HW/SW/Functional Code Generators – Tools that have as output the actual code of the interface. For each type of interface, there must be a specific code generator. The model generation starts with the system specification. We are assuming that the input specification language (or model) is able to describe precisely a heterogeneous system in terms of abstraction levels, communication protocols, processor types, etc. We used as specification language an extension of SystemC [16] that allows describing hierarchical ports (abstract interfaces). Each interface analyzer reads this specification and identifies the required adaptations. Then it outputs the list of configuration parameters to the SDG Generator. This list of parameters varies from one kind of interface to another. For example, for HW interfaces some parameters would be: processor type, interconnect type, data size, etc. One thing in common is the parameters relative to services required/provided by subsystems and the execution environment. The SDG Generator has as inputs the list of configuration parameters provided by one of the interface analyzers, and the list of elements and services that are available in the related Resource library. It first builds a SDG with elements that provide the required services. This graph may have elements that are not compatible with the implementation choices. So, the next step is traversing this graph recursively and eliminating graph cycles and

I/O Element int DeviceDriver::ReadAdr (int adr) {

ReadAdr

int data; Device Driver Block

if (! LowIOProvider .Ok_Read()){ Synchronizer.Block();

UnBlock Low_Read Ok_Read }

Synchronizer

LowIOProvider

Cxt_ Switch

DataConv Converter

Scheduler Read

Pdata

Write Padr

EnRead

Synchronizer.UnBlock(); LowIOProvider.Low_Read(adr,&data); return data; }

PRW

SAP

Execution Environment (RTL)

Figure 5. Example of SW Interface Implementation The right side of Figure 5 shows how service ReadAdr from the element DeviceDriver is implemented.

3.5 Implementing a HW Interface Figure 6 shows the implementation of an HW interface using the SDG model. Here, we consider that we want to enable communication between the processor bus and the network (execution environment). Consider also that the processor sends data to the network by 2 or more output channels. The choice of the output channel depends on the address port value (P adr) of the processor. For a particular address value, a counter is incremented and its value is sent to the network. In this case, we assume that the output channel accessed by the Pdata1” port is chosen. Hierarchical port P requires the NWInterfaceWrite service provided by Addr_Decoder through a Port Access. Addr_Decoder requires a service Count provided by Counter, which requires a Put (to store the counter value). This service is provided by FIFO, which requires the service Write provided by port Pdata1”. The right side of Figure 6 shows the HW interface implementation. Notice that all elements are implemented as subsystems. Accesses to the services that they provide are made through Port Accesses. For example, Addr_Decoder provides the NWInterfaceWrite service which is accessed through a hierarchical port which contains sub-ports Pdata, Padr and PRW.

264

memories. Peripherals tasks include performing reads/writes data from/to files, combining the processed parts of the image, etc.

invalid elements/services using a colored graph technique as described in [16]. It uses two mutually recursive functions. The first one treats elements and the other one services. For each service, the SDG generator searches an element that is compatible with the implementation choices. When it finds one, it eliminates all elements that provide the same service but have non valid implementations. The output graph may still have valid elements that provide the same service. Currently, it is up to the designer choosing which elements he wants to use. But we are working on making this selection automatic based on a performance metric. This graph is output to a specific (HW, SW or Functional) Code Generator. The specific Code Generator gets elements implementations from the Resource Library based on the provided SDG and then generates the final code. The Resource Library has the list of available elements/services, the elements implementation and also elements/services definitions. These definitions state the relationship between different services and elements, and guide the SDG and Code Generators. We have developed an intermediate language for defining services and elements. An element definition includes: required/provided services, implementation parameters (language, processor specific implementation, quality of service, etc), source file, element type (SW or HW), etc.

Func. Interface Analyzer

Figure 8. Abstract Architecture of MPEG-4 Encoder Figure 8 shows the abstract architecture of the MPEG-4 encoder. The processors were specified at TLM in order to delay implementation decisions concerning their local architecture to a further design step. As the DMA/peripherals were implemented by existing IPs, they use RTL communication primitives.

5.1 Design Flow and Results The design flow for the MPEG-4 encoder started with the abstract architecture specification and had 3 main steps. STEP 1 In this step, mixed-level validation was performed to check whether subsystems’ interaction after system’s partitioning were correct. This required only the generation of functional interfaces as depicted in Figure 9a. Four types of functional interfaces (Func. Intf) were built. Func. Intf1 enables data transfers between DMA and VProc (example presented in section 3.3). Func. Intf2 enables data transfers between DMA and VLC (same example, except for the implementation of the TLM port). Func. Intf3 adapts control communication between VProc and DMA. It tells DMA that the processors are initialized and ready to receive data, or that data has been processed. The number of events that the processor sends to DMA determines DMA’s next action. Func. Intf4 enables control communication among DMA, VProc and VLC. It tells VProc and VLC that they can start processing. Func. Intf3 and Func. Intf4 use the same type of port for receiving and sending events.

SW Interface Analyzer

Conf. Parameters

Conf. Parameters

Conf. Parameters

SDG Generator Elements List Subsystems

HW Code Generator HW Interface

HW Library

Elements List Func Code Generator

Logical Elements Channels

Logical Elements

Func. SW Library Library

Elements List

SW Code Generator

Func Interface

VLC (TLM) SW

Execution Environment (TLM)

Abstract Architecture

HW Interface Analyzer

DMA + Peripherals (RTL) HW

SW VProc SW 11 (TLM) (TLM) (TLM) SW

STEP 1

STEP 2

SW Interface

Figure 7. Flow for Building Interfaces VProc

The main benefit of this flow is that a single tool (SDG Generator) can configure interfaces independently of their implementation (HW, SW or Functional). Another benefit is its modularity and thus flexibility. For instance, changing the required final code language implies only the addition of the required language implementations in the library and the corresponding modification of the code generator. No changes are made on the other tools.

DMA+ Peripherals RTL-TLM Interconnect (TLM)

(a)

VLC

STEP 3

VProc

VLC

VProc

VLC

OS HAL (Host)

OS HAL (Host)

OS HAL (ARM7)

OS HAL (ARM7)

CPU

CPU

Co-Proc

CPU DMA+ Peripherals Co-Proc Interconnect (RTL)

Co-Proc

(b)

CPU DMA+ Peripherals Co-Proc Interconnect (RTL)

(c)

Figure 9. MPEG-4 Encoder Design Flow (a) Mixed-level validation (b) HW/SW Interface Generation for Native Execution (c) SW Interface Generation for ARM7 These interfaces were built by the model generator using the SDG model. They are composed of: data converters, ports, synchronizers, etc. We are considering that all libraries are empty in the beginning. Nine elements were implemented (162 lines-C code) to build these interfaces. Func. Intf1 required four elements (62 lines-C code). Only one more element (19 lines-C code) was implemented to build Func. Intf 2. This shows the flexibility of the SDG model. Changing the protocol only required one additional element. Similar reasoning for Func. Intf3 and Func. Intf4. Two elements (26 lines-C code) were implemented for Func. Intf3 and only one more (9 lines-C code) for Func. Intf4.

5. CASE STUDY: MPEG-4 ENCODER Our case study is designing an MPEG-4 video encoder. To achieve better performance, the MPEG-4 video encoder algorithm was parallelized to run on 5 processors (ARM7TDMI – 60 MHz), four of them to perform image treatment (VProc) and the other one to compress the image (VLC). Each processor has 2 tasks running on it (Computation and Communication). In the final architecture each processor has internal memory banks in which the data needed for computations are stored. The resulting system consisted of: five processors (four VProc and one VLC), a DMA and some peripherals. The DMA allows data transfer among all

STEP 2 This step, shown in Figure 9b, consisted in refining SW to run on top of a generic OS. To do that we had to: (1) generate SW

265

Functional and SW interface generation is fully automated, while HW interface generation is semi-automated. The HW Interface Analyzer is not implemented yet. The fact that this approach is library-dependent is a limitation. We can not guarantee that a particular element implementation can provide an efficient interface. Another limitation is that we take the bottom-up approach for composing interfaces, so the global optimal solution may not be provided (we can optimize single elements, not the whole interface). Thus, this approach eases the local optimal solution. Finally, elements selection is not yet based on any specific performance metric. But we are working on it.

interfaces to enable native tasks execution on the host processor; (2) refine interconnects to RT-level; (3) generate HW interfaces (Co-processors in Figure 9b) to adapt the processor bus to system’s interconnects. The generated SW interfaces include a part of the operating system that is HW independent (which we call OS) and one that is HW-dependent (HAL). The generated OS uses a pre-emptive round-robin scheduling mechanism. The SDG for the I/O service ReadAdr is shown in Figure 5. Fifteen elements (914 lines-C code) were implemented to build the whole SW interface for VProc. For VLC, only one more (15 lines of C code) was implemented. Once more, the flexibility of the approach reduces designers’ effort.

6. CONCLUSIONS

HW interfaces were generated for VProc and VLC. Three elements were implemented (96 lines-VHDL). HW interfaces for VProc and VLC are the same because both are ARM7 processors and use the same kind of interconnect. Few elements were used in this interface due to its simplicity. Even so, efficiency is implicit because only the required services were used.

This paper described a service-based model enabling systematic design and co-simulation of HW/SW interfaces for SoC design. This model allows designers to implement complex and customized interfaces. We also presented a model generator that can automatically build HW/SW interfaces based on service and resource requirements described by the SDG model. This approach has been successfully applied on the design of an MPEG-4 encoder.

STEP 3 The last step of the flow consisted in refining SW to execute on top of the real ARM7-specific OS. Then, SW interfaces were generated (basically the HAL) as shown in Figure 9c.

7. REFERENCES [1] A. Sangiovanni-Vicentelli “Defining Platform Based Design” EE Design, March 2002 [2] J-Y. Brunel, W. Kruijtzer, H. Kenter, F. Pétrot, L. Pasquier, E. de Kock, W. Smits, “COSY Communication IP’s,” Proc.DAC’00, June 2000. [3] P. G. Paulin, C. Pilkington, E. Bensoudane, “StepNP: A System-Level Exploration Platform for Network Processors”, IEEE Design & Test of Computers, vol. 19, no.6, Nov. 2002. [4] “The MPI Standard” available at http://wwwunix.mcs.anl.gov/mpi/ [5] L. Kai, D. Gajski “Transaction Level Modeling: An Overview”, Proc. CODES+ISSS’03, October 2003 [6] IBM Corp. IBM CoreConnect Bus Architecture: http://www3.ibm. com/chips/products/coreconnect/index.html [7] ARM AMBA: http://www.arm.com [8] S. Vercauteren, B. Lin, H. De Man “Constructing Application Specific Heterogeneous Embedded Architectures from Custom HW/SW Applications”, Proc. DAC’96, June 1996 [9] Virtual Socket Interface Alliance. http://www.vsi.org [10] Open Core Protocol. http://www.ocpip.org [11]Sonics SiliconBackplane µNetwork. http:// www.sonicsinc.com [12] W. Cesario, A.Baghdadi, L.Gauthier, D. Lyonnard, G.Nicolescu, Y.Paviot, S.Yoo, A.A.Jerraya, M.Diaz-Nava, “Component-Based Design Approach for Multicore SoCs”, Proc. DAC ‘02, June 2002 [13] S. Abdi, D. Shin, D.Gajski “Automatic Communication Refinement for System Level Design”, Proc. DAC’03, June 2003 [14] CoWare, Inc. “CoWare N2C ” available at http://www.coware.com [15] M.Zitterbart, “A Model for Flexible High performance Communication Subsystems”, IEEE Journal on selected areas in communication, VOL. 11, NO, 4, MAY 1993. [16] L.Gauthier, S.Yoo, A.A.Jerraya “Automatic Generation and Targeting of Application Specific Operating Systems and Embedded Systems Software”, Proc.DATE’01 ,March 2001

Most of the elements that implement these interfaces were already added to the SW library in step 2. Only a small part was implemented from scratch (basically the HAL), which consisted of five elements. The SW interfaces for VProc had 687 lines of code (426 of C code and 261 of ASSEMBLY code). The five added elements had 402 lines of code (141 of C code and 261 of ASSEMBLY code). No elements were added for the VLC, because all required elements were already in the library. The quality of the generated SW interfaces is good. Generally, the minimum size of commercial OSs is 4 KB, while the size of the produced SW interfaces is 1.5 KB. Performance is also good, as 36 cycles are spent for context switch, latency for HW interrupts is 59 cycles and latency for system calls is 50 cycles.

5.2 Evaluation This case study showed the effectiveness of this approach. The main contributions of this work are: (1) a unified model to handle heterogeneous components at different abstraction levels: interfaces at different abstraction levels were generated using the same model in the case study; (2) being independent of “standards”: designers can define their own service models and corresponding interface elements; (3) hiding details and delaying decisions through the use of abstract models: adaptation is specified (by the SDG) in a implementation independent manner; (4) enabling different and sophisticated adaptation schemes: the SDG model provides a high degree of flexibility, different implementations for the adaptation are possible from the same interface model. It was also shown how this model can improve the quality of such interfaces. This model may lead to HW and SW interfaces that are efficient as manual coded/configured ones, because there are no unnecessary services (5) allowing automation for application-specific (and/or target architectures) interfaces: the model generator used in the case study demonstrates this. A single tool is in charge of composing interfaces regardless of their kind (HW, SW or functional).

266