Multi-level Communication Synthesis of Heterogeneous ... - CiteSeerX

Multi-level Communication Synthesis of Heterogeneous Multilanguage Specification F. Hessel, P. Coste, G. Nicolescu, P. LeMarrec, N. Zergainoh, A. Jerraya TIMA Laboratory, 46 Av. Félix Viallet – 38031 – Grenoble Cedex – France

[email protected] ABSTRACT

need to be used within the same design. Multilanguage

The complexity of modern embedded systems requires the

design constitutes an important step towards this direction

cooperation of several teams belonging to different cultures

and offers many advantages including efficient design flow

and using different languages as well as the reuse of

from system-level specifications, and shorter time-to-

software, hardware and communication IP modules at the

market and design cycle.

early design steps. The key issue for the design of such

A multilanguage system is defined by a set of subsystems

systems is the overall system validation and the synthesis of

based on different concepts. A coordination file specifies

the communication between the different subsystems. In

the inter-module interactions. This may be specified at

this paper, we focus on the problem of multi-level

different levels ranging from the physical level to the

communication synthesis and show the results of the

application level. Table 1 shows three levels of inter-

application of this methodology on an example. Designers

module communications.

get feedback at all design steps via the cosimulation engine that permits fast evaluation.

Net

Interface Port

Communication Primitives

Application level

Abstract Channels

Service Access Points (Accesses)

High-level primitives

Driver level

Abstract Wires

Logical Ports

Read/write operations

Physical level

Wires

Physical Ports

Set/reset signals

Keywords Multilanguage, Codesign, Communication Synthesis.

1. INTRODUCTION The complexity of modern embedded systems keeps increasing

exponentially,

even

faster

than

industry

Table 1. Abstract levels of inter-module communications

specialists often predict [1]. Due to this increase and the

At the application-level, the interface is made of service

time-to-market constraints, the design of such systems

access points called accesses and communication is carried

requires the cooperation of several teams belonging to

out through high-level primitives. At this level, the

different companies and using different design methods,

communication

languages, and tools in order to cope with the demands of

communication procedures. This allows us to specify a

an extremely competitive market. The characteristic of

module regardless to the communication protocol that will

these systems is the coexistence of a large number of

be used later. The next level may be called the driver level.

components with disparate types and functions specified in

Interfaces are made of ports and the communications are

different languages and described at different abstraction

performed through read/write operation on I/O registers.

levels. New specification and design methods are needed to

These operations may hide physical address decoding and

handle these cases where different languages and methods

interrupt

protocol

management.

may

At

the

be

hidden

lowest

by

level,

the

all

implementation details of the protocol are known and

levels. However, these approaches realize the interface

communication is performed using operations on simple

synthesis for a unified representation of the system.

wires. The interface corresponds to physical ports.

In [8], Ecker presents a method for transforming and

The complexity of the communication synthesis depends on

optimizing protocols. In [9], Narayan addresses the

the level of the inter-module communication. When

problem of bus interface generation between two different

designing complex heterogeneous systems, two kinds of

hardware modules of a partial specification. The focus is to

communication synthesis are required:

optimize the use of a bus by keeping different point-to-point

•

the

communications on it. As described in [10,11], Lin and

refinement of interactions between modules described

Narayan consider the problem of interfaces synthesis with

at the same abstraction level. This includes the

automatic protocol conversion with one or both sides

transformation of channels or abstract nets connecting

having a fixed interface. In [12], a new design methodology

accesses or ports of the same kind. This kind of

based on interface design was proposed that treated

communication synthesis is needed when refining a

behavior and communication as orthogonal elements. The

system-level

goal is to make it easier to reuse communication

Homogeneous

communication

model

(such

synthesis

as

SDL)

i.e.

into

an

components.

implementation. •

SpecSyn

[13]

generates

buses

for

communication between two processes using a technique Heterogeneous

(or

Multi-level)

communication

synthesis. This addresses the refinement of interaction between modules described at different abstraction levels and need to handle the transformation of channels or abstract nets that connect ports or accesses from

different

communication

abstract synthesis

levels. is

This

needed

kind when

of the

specification includes modules described at different abstraction levels or using different languages.

called interface refinement. Analyzing the size of data communicated with rate of data generation, they determine the bandwidth of the generated bus and merge the communication channels onto the bus. Yen and Wolf [14] looked at communication synthesis in the context of derivation

from

heterogeneous

distributed

system

architectures with an arbitrary topology. Ortega and Borriello [15] addressed the problem of synthesizing the communication for an arbitrary bus topology specified by

Most current approaches in communication synthesis for

the system architect. The synthesis processes make a map of

codesign have focused on interface synthesis for a

high-level functions to the computational components of a

homogeneous system specification (same abstraction level

particular architecture. An application-specific real-time

as inter-module communications) [2,3,4]. In [5], Vahid

operating system is generated for each processor in the

presents an object-oriented communication library for

system. An extension of this approach that takes into

hardware-software codesign. The PIA co-simulation tool

account IP modules, is presented in [16]. Daveau [17] takes

[6] allows to specify multiple communication models for

a behavioral description and automatically selects a

each interface of the system and to switch dynamically to

protocol from a library to implement the communication.

another communication model during the simulation run.

But,

The CoWare [7] environment allows the designer to specify

homogeneous systems.

and simulate communication channels at various abstraction

this

approach

solved

only

the

problem

for

To our knowledge, none of these existing works have

are exchanged between the Matlab subsystem and the SDL

specifically addressed the problem of communication and

subsystem. Each motor reads the speed order sent by the

interfaces synthesis between modules described at different

controller and calculates its current position. This parameter

abstraction levels. This paper gives the details of the multi-

is sent to the controller, in order to calculate the next speed

level

heterogeneous

order. Using the information about the robot arm trajectory,

multilanguage systems and shows the results of the

the controller computes the distance to go for each motor.

application of this methodology on an example. This

This will be compared with the current position in order to

methodology

generate the new speed value.

communication

allows

synthesis

to

specify

for

the

inter-module

communications at different abstraction levels (multi-level

The SDL specification is composed of three main blocks

communications). This work is part of the multilanguage

(figure 1):

design methodology described in [19].

•

The Host Machine represents the controller testbench.

The paper is organized as follows. Section 2 introduces a

It initializes the controller by sending the information

motivational example. A short description of the design

concerning the trajectory that the robot arm must

flow is presented in section 3. More information about the

realize to the controller.

design flow is given in [19]. Section 4 details the heterogeneous communication synthesis. Section 5 presents

•

The Controller block calculates the speed required for each motor in order to make all the motors reaching the

the obtained results for the given example. Finally, section

desired position in the same time. This block is

6 provides our conclusions.

composed of three processes: Dist, Ctrl1 and Ctrl2.

2. MOTIVATIONAL EXAMPLE

Dist receives the information concerning the trajectory

The application is a multi-motor controller of a robot arm.

that the robot arm must realize. It identifies for each

The control is intended to avoid discontinuous motor

motor the distance to go. Ctrl1 and Ctrl2 store up-to-

operation problems. The system receives from a host

date information about the current position of each

machine, the information about the movement that the robot

motor. Comparing the current position of each motor

arm must realize. Using this information, the controller

with the required position, these processes generate the

adjusts the speed of each motor, for a continuous movement

speed orders for the motors.

of the arm. In order to allow a clear explanation, we will

•

The Sampler block is the interface between the

restrict the model to two motors only. Despite this

controller and the two motors. It is responsible for the

simplification, the robot arm controller constitutes a quite

transformation of the continuous signals sent by Matlab

complex system.

block, in discrete signals for the SDL block.

The robot arm controller is a complex system composed of

The interface of the SDL subsystem is composed of high-

two communicating subsystems: an electronic part, the

level ports, named accesses, which are used by high-level

controller, and a mechanical part, the two motors. Because

communication primitives. Each access will be refined

of the nature of the behavior performed by these two

during the communication synthesis into several ports

subsystems, different languages are needed. SDL is used to

according to the selected protocol.

model the controller and Matlab is used to model the physical behavior of the motors (IP module). Four signals

The connector concept [20] hides detailed interfaces (set of

C trl 1

S am p ler C ons1

A dr H os t

interconnection of modules with heterogeneous interfaces.

M otor 1 speed

C on tro ller H o st M ac hine

Speed1

M otor 1 P osition

Sam p le r 1

connect modules communicating via different protocols.

D ist

Init

C ons2

Sp eed2

Sam p le r 2

physical ports). The heterogeneous channel allows to

M otor 2 P osition

The SDL and Matlab subsystems are interconnected through four heterogeneous channels (M1 speed, M2 speed,

C trl 2

M otor 2 speed

M1 position, M2 position). Each heterogeneous channel links an access belonging to the SDL subsystem with a

Figure 1. Description of the robot arm controller in SDL

connector belonging to the Matlab subsystem.

The Matlab specification is composed of two independent SDL Subsystem

processes that describe the motor behavior. On the Matlab side, communication is made through physical ports

M atlab Subsystem

get/M 2 p osition

connected to wires. In this application, the interface is composed of five ports. Three ports are used to receive the

sp eed 1 connector

m otor 1 m otor 2 m otor 1 m otor 2 speed access speed access position access position access

speed data using a handshake protocol. These ports are

position 1 connector

position 2 connector

M 1 speed

specified as a connector called connector_speed. The other

M 2 speed

two ports are used to send the position information to the

M 1 position M 2 position

SDL subsystem. These ports are specified as a connector

Figure 3. SDL-Matlab Coordination File

called connector_position. Figure 2 shows the Matlab schema for one of the two motors.

sp eed 2 connector

In this case, the two subsystems make use of interfaces at different abstraction levels. Matlab communicates through physical ports and SDL communicates through accesses. The heterogeneous channels jointed different abstraction levels of communication. The interpretation of the link between the two subsystems will need a specific communication synthesis step. For this example, the SDL part will be refined to implementation through several steps while the mechanical part will be used as a testbench during all design process.

Figure 2. Motors Matlab Specification

The graphical representation of the coordination file for this application is presented in figure 3. We used SOLAR intermediate form [18] for the description of the coordination between subsystems specified in different languages. SOLAR was extended to provide the concepts of the heterogeneous channel and connector for the

3. THE DESIGN FLOW The design flow combines three basic techniques (figure 4): •

The refinement of the high-level specification into an implementation: the electronic part will be refined into a hardware/software implementation, other subsystems may also be refined. However, in this paper we will

•

•

restrict this step to the electronic part described in

implemented in conformity with the chosen communication

SDL.

protocol. After this step, cosimulation at the architectural

The communication refinement: this technique allows

level is used again in order to validate the produced model

to refine the coordination between the different

and communication protocol. During the next step, the

subsystems.

design is refined at the cycle true level. Hardware is refined

The cosimulation: this technique allows the validation

the final processor. The final step is the prototyping.

of the overall system at different design stages. SDL

4. HETEROGENEOUS COMMUNICATION

O th er L an gu ag es

M atla b

as an RTL model and software is executed on a model of

SYNTHESIS S ystem -level cosim u latio n

The input to the communication synthesis tool is a set of subsystems

C od esign

VH DL

C

C

through

heterogeneous

communication channels (figure 3). The heterogeneous

O th er L an gu ag es

M atla b

interconnected

channels link the different interfaces of the subsystems. The result of communication synthesis is a system composed of

A rch itectu re cosim u la tio n

a set of modules interconnected by signals. Extra modules T arg etin g

can be automatically inserted during the communication A S IC

µC on troller

µC on troller

synthesis step in order to allow the communication

D S P cod e

controller and protocol adaptation. C ycle-true co sim ulatio n

The communication synthesis uses a communication Figure 4. Design Flow

library. This library contains a set of communication units

The design starts with an analysis of the system

(figure 5). It allows the designer to choose the adapted

requirements and a high-level definition of the various

protocol to implement a heterogeneous channel. The library

functions of the system. At this stage we obtain a

may contain several implementations of the

multilanguage system-level model. The validation includes

communication unit according to data transfer rates,

cosimulation and verification. This step ensures the

memory buffering capacity and adaptation functions for

functional validation of the system. The cosimulation tool

different

interprets

communication unit is composed of an interface that

the

abstract

communication

between

the

subsystem

interfaces

and

same

formalisms.

A

subsystems.

specifies the communication primitives and the connectors,

The next step is the refinement of the electronic part and

and a module that specifies the interconnections and the

communication synthesis. The electronic part is refined into

controller of the communication protocol.

an implementation composed of software/hardware blocks. This step generates a software model described in C and a hardware model described in VHDL communicating

C om m . U n it In te ge r G e t_ in te g e r(X )

C om m . U n it S ér ie

con n ecto r

R S 23 2

R S 23 2

In te rfa ce

In te rfa ce

C trl_ in te g e r

N e t_ c o n n e c tio n s

through signals [17]. During the communication synthesis, the heterogeneous channels are mapped on explicit communication protocols. Each heterogeneous channel is

Figure 5. Heterogeneous Communication Units

Two steps are needed to make the communication

S D L S ubsystem

synthesis. The first performs the protocol selection and

M atlab S ubsystem G e t_integ er(X )

Pc all get_integ er

allocation. In this work, we use the protocol selection and allocation strategy described in [17]. The second step

sp eed 1 c onne ctor

m otor 1 m otor 2 m otor 1 speed ac ce ss speed ac ce ss position a ccess

consists in transforming the heterogeneous channel into an

sp eed 2 c onne ctor

position 1 co nne ctor

position 2 co nne ctor

M 1 speed M 2 speed

implementation according to the chosen communication

M 1 position

unit. Three procedures are required to perform the second co nn ec tor

step: the synthesis of the logical interfaces (accesses), the

Interface

synthesis of the connectors and the synthesis of the

C trl

interconnection. The synthesis of the logical interfaces

C om m . U nit integer

transforms the communication primitive calls into specific procedure calls. The called primitives are integrated in the subsystem code and the logical interface is refined into a set of physical ports. The synthesis of the connectors interconnects the ports of the connector with the communication unit and no transformations are applied to the subsystems. The interconnection synthesis inserts a communication controller when needed and optimizes the interconnections between the subsystems linked with the same heterogeneous channel. This transformation is similar to interfacing incompatible protocols [10]. This approach allows to handle a wide range of protocols, from simple handshakes to complex protocols. This flexibility is obtained thanks to the library. Moreover, the inter-module communications can be specified at different

Figure 6. System after Communication Synthesis Step

5. RESULTS In this section we show the results of our approach for the communication synthesis of multilanguage system-level specification. The results regarding the cosimulation and the communication synthesis in the case of the robot arm controller. In this example, the electronic part was refined into an implementation composed of VHDL blocks. Of course, other implementations including both hardware and software are possible. The simulation time of at both system and architecture levels was evaluated. The measurements have been realized on SPARC ultra 1 station, in normal conditions of network loading. Table 2 summarizes the cosimulation results.

abstraction levels (table 1) thanks to the connectors. Starting from the system of figure 3 and the communication

Simulation step

units of figure 5, the result of the communication synthesis

Full simulation cycles

to the heterogeneous channel M2 position is detailed in

Cycles/sec

figure 6. In this case, the access of the SDL module is

Full simulation time

System-level

Architecture-level

(SDL-Matlab)

(VHDL-Matlab)

Transition

Computation step

3280

57000

31

11

1min 45s

1h 30 min

refined to three physical ports. A communication controller

Table 2. Results of cosimulation

is inserted to convert the data types between SDL and

The simulation time results from the granularity of the

Matlab.

simulation step. A step corresponds to a simulation cycle. It has different representations from an abstract level to another:

•

•

At the system-level, a simulation step corresponds to a

6. CONCLUSION

transaction between parallel processes. For our

This work presented a communication and interface

application, a full simulation scenario requires 3280

synthesis for multilanguage specifications. The synthesis

cycles.

task may be performed automatically and allows the

At the architecture-level, a simulation step represents a

designer to map high-level communication primitives

typical behavioral VHDL computation step. In the case

described in different formalisms and notations, to a

of our application a full simulation requires 57000

physical implementation. Since no restrictions are imposed

cycles.

to the communication models, this process can be applied

Given the performance of the cosimulation tool, we are able

to a large class of multilanguage codesign applications.

to perform a full simulation of the application at the system-

7. ACKNOWLEDGMENTS

level in less than two minutes. At the architecture-level, a

This work was supported by France-Telecom/CNET, SGS-

full simulation can be done in about ninety minutes. In this

Thompson, Aerospatiale, PSA, ESPRIT program under

case, the simulation time of the system-level model is 45

project COMITY 23015, MEDEA program under projects

times faster than the architectural model.

SMT

Table

3

shows

the

results

of

the

heterogeneous

communication synthesis concerning the number of communication lines. These results are specific for this application and used communication protocols. In order to show the added value of using high-level communication primitives, we compare the size of the code devoted to communication at different abstraction levels. SDL Model

Number of lines

VHDL Model

Behavior

Comm.

Behavior

Comm.

292

16

2810

646

(5 %)

Increase 962%

(23 %)

Table 3. The size of SDL code and of the VHDL code produced

In the case of this application, at the system-level, the heterogeneous communications represent 5% of the SDL specification and 23% of the VHDL implementation. It is due to in SDL one instruction is sufficient to communicate: the communication protocol, signal routing and queues are implicit. During the refinements steps the communication becomes

explicit

using

specific

protocols

and

communication controllers. The generated VHDL code size is much bigger, namely it amounts to 962% of the initial SDL code.

AT-403

and

CIME

452

and

CAPES/COFECUB/PUCRS.

8. REFERENCES [1] R. Ortega, L. Lavagno and G. Borriello, “Models and Methods for Hw/Sw Intellectual Property Interfacing”, in NATO-ANSI Workshop on System Level Synthesis, 1998. [2] Jan Madsen and Bjarne Hald, “An Approach to Interface Synthesis”, in Proc. of the 8th ISSS, pp. 16-21, 1995. [3] S. Narayan and Daniel Gajski, “Protocol Generation for Communication Channels”, in Proc. of the 31th DAC, pp.547-548, 1994. [4] Michael Eisenring and Jurgen Teich, “Domain-specific interface generation from dataflow specifications”, in Proc. of the 6th International Workshop on Hardware/Software Codesign (CODES/CASHE’98), pp.43-47, 1998. [5] Frank Vahid and Linus Tauro, “Object-oriented communication library for hardware-software codesign”, in Proc. of the 5th International Workshop on Hardware/Software Codesign(CODES/CASHE’97), pp.81-86, 1997. [6] Ken Hines and Gaetano Borriello, “Dynamic communication models in embedded system cosimulation”, in Proc. of the 34th DAC, pp.395-402, 1994. [7] D. Verkest, K. Van Rompaey, I. Bolsens and H. De Man, “CoWare – A Design environment for Heterogeneuos Hardware/software Systems”, Design

Automation for embedded Systems, vol. 1, no. 4, pp.357-386, 1996.

International Conference on Computer Aided Design, pp.288-294, 1995.

[8] W. Ecker, M. Glesner and A. Vombach, “Protocol merging: A VHDL Based Method for clock cycle minimising and protocol preserving scheduling of IO operations”, in Proc. of the EDAC with Euro-VHDL, pp.624-629, 1994.

[15] R. Ortega and G. Borriello, “Communication Synthesis for Distributed Embedded Systems”, in Proc. of International Conference on Computer Aided Design, pp.437-444, 1998.

[9] S. Narayan and D. Gajski, “Synthesis of System-Level Bus Interfaces”, in Proc. of the EDAC with EuroVHDL, pp.395-399, 1994.

[16] P. Chou, R. Ortega, K. Hines, G. Borriello, “IPChinook: An Integrated IP-based Design Framework for Distributed Embedded Systems”, in Proc. of the Design Automation Conference, 1999.

[10] S. Narayan and D. Gajski, “Interfacing Incompatible Protocols Using Interface Process Generation”, in Proc. of the IEEE Design Automation Conference, pp.157-164, 1995.

[17] J.M. Daveau, G. Marchioro, T. Ben-Ismail and A.A. Jerraya, “Protocol Selection and Interface Generation for Hw-Sw codesign”, IEEE Trans. on VLSI Systems, vol. 5, no.1, pp.136-144, 1997.

[11] B. Lin and S. Vercauteren, “Synthesis of Concurrent System Interface Modules with Automatic Protocol Conversion Generation”, in Proc. of IEEE International Conference on Computer Aided Design, pp.395-399, 1994.

[18] A.A. Jerraya and intermediate format specification”, in Hardware/Software 1992.

[12] J. Rowson and A. Sangiovanni-Vincetelli, “Interfacebased design”, in Proc. of the Design Automation Conference, pp.178-183, 1997.

[19] P. Coste, F. Hessel, P. LeMarrec, Z. Sugar, M. Romdhani, R. Suescun, N. Zergainoh, A. Jerraya. “Multilanguage Design of Heterogeneous Systems”, in Proc. of CODES, Rome, Italy,1999.

[13] D. Gajski, F. Vahid, S. Narayan and J. Gong, Specification and Design of Embedded systems. Prentice Hall, 1994. [14] T. Yen and W. Wolf, “Communication Synthesis for Distributed Embedded Systems”, in Proc. of

K. O’Brien, “SOLAR: An for system-level design and IFIP Inter. Workshop on codesign, Grassau, Germany,

[20] F. Hessel, P. Coste, P. LeMarrec, N. Zergainoh, J.M. Daveau, A.A. Jerraya, “Communication Interface Synthesis for Multilanguage Specifications”, in Proc. of RSP, pp. 15-20, Clearwater, Florida, USA, 1999.