1 / 21

Communication synthesis

2 / 21

Motivation

• Architecture of embbeded systems is becoming very complex• hardware and software components, RTOS, communication

networks

• Design of embedded systems is also becoming very complex• rapid exploration of the architectural design space

• heterogeneous specification and validation

• automatic synthesis of software and hardware

• Time-to-market• IP reuse as a solution

3 / 21

IP-based design

• Electronic market of IP providers and consumers• hard and soft IP components

• software IP

• Bus and core standards improve reuse of homogeneous components

• System platforms also improve reuse• architectural templates

• design of derivatives

• Heterogeneous components• synthesis of hw / sw interfaces

4 / 21

Design methodologies and styles

• Separation between computation and communication• interface-based design

• Consolidation of abstraction levels• system, abstract architecture, RTL or micro-architecture

• Platform-based design• reuse of HW / SW components that fit an architectural template

• mapping of different functions to the same architectural templates

• platform = reuse of system design expertise

• HW platform abstracted so that application SW sees an API

• designing derivatives = configuring hardware + developing application software

5 / 21

IP reuse process

IP creation

IP provider

IP consumer = SoC designer

IP qualification

IP classification

IP search

IP evaluation

IP integration

IP transfer

• providers and consumers may belong – to the same organization – related by an intranet – to different organizations – electronic market – related by the internet

• legal issues• business models• IP protection

6 / 21

IP integration

• Problem: diversity of IP providers, component types, architectural templates, communication structures• hardware and software interfaces must be designed

• OS’s must be targeted to the final architecture

• Design of interfaces• generate synthesizable RTL from a high-level component

description

• cycle-and-pin-accurate descriptions: too many low-level details

• manual design of interfaces is tedious and error-prone• requires extensive validation

• rapid architectural exploration becomes impossible

7 / 21

Bus-based design

• IP components adapt to a bus specification• either directly or through a wrapper

• IBM CoreConnect family of buses – PLB, OCB, DCR• BlueLogic Core Library

• ARM AMBA family of buses – AHB, ASB, APB• AMBA Design Kit – set of basic components + development and

simulation environment

• Sonics Silicon Backplane MicroNetwork• highly configurable, on-chip network • unifying data flow, control flow, and manufaturing test signaling• cores connected through a communication-independent OCP socket• SOCCreator development environment for configuration,

evaluation, and synthesis of the MicroNetwork

8 / 21

Coral• IBM – Bergamaschi et al. – DAC’2000, IEEE D&T Sept/Oct

2001• SoC design around the CoreConnect bus• Encapsulation of structural and functional information of cores

through virtual components with virtual interfaces• virtual interface aggregates several real pins

• Pin properties define functionality and taxonomy• interconnection engine compare pin properties and decide whether they

can be interconnected

• automatic synthesis of glue logic that is still needed

• configuration engine for programming virtual component parameters• clocking, address and interrupt maps, DMA channel assignment,

priorities

9 / 21

Core-based design

• IP core has a standard, bus-independent interface• interface contains only functions that are relevant to the core• adapters for connecting cores to different communication

structures• direct point-to-point communication between cores is also

possible

• VSIA• VCI – Virtual Component Interface

• Open Core Protocol – OCP-IP • configurable protocol according to core’s needs• basic signals, pipelined and burst transfer modes• CoreCreator development environment for OCP-compliant cores

10 / 21

Generating hardware wrappers – PIG

• Berkeley – Passerone, Rowson, Sangiovanni-Vincentelli – DAC’98

• Generates Verilog code of an FSM interface between arbitrary protocols

• Protocols must be described as regular expressions• regular expressions are translated into FSMs

• Transfer latency is minimized

• Limitations• only for point-to-point communications

• interface stores data in an internal register

• data types must be compatible

• both components must be fully synchronous and driven by the same clock

11 / 21

Generating hardware wrappers – POLARIS

• Stanford – Smith and DeMicheli – DAC’98

• Generates cycle-accurate Verilog description of an interface between two or more IP’s• multiple producers and multiple consumers are possible

• IP’s may be connected by busses

• Inputs are the Verilog descriptions of the IP’s, including their interface protocols

• Protocols are mapped into a standard communication scheme, implemented by a standard interface architecture• state machines for protocol conversion +

• internal standard protocol +

• send and receiver buffers (queue sizes are manually defined) +

• arbiter (default is round-robin)

12 / 21

Software IP’s

• RTOS for embedded systems• several academic and commercial solutions

• No current standards for the API• newly created VSIA DWG on HdS

Application softwarewith software IP’s

API abstracting hardware platform

API implementationhardware and software

RTOS, other HdS

SW reuse

SW reuseSW synthesis

directcoupling

SWre-targeting

13 / 21

Generating software wrappers – IPChinook

• Univ. of Washington – Chou, Borriello et al. – DAC’99• Input description

• behavioral description of a system as concurrent modal processes• target architecture: processors, I/O devices, busses, topology• mapping between processes and processors

• Processes must communicate through a common protocol• Abstract Control Types: high-level primitives for control composition

• Automatic synthesis of a scheduler (mode-manager) for a given partitioning of processes• user may choose among several scheduler options

• Synthesis of communication wrappers• generates device drivers, routers• accounts for particular bus protocols, routing requirements, timing

constraints

14 / 21

Generating software wrappers – TERecS

• C-Lab – Böke and Rammig – PART’99• Communication Graph = distribution and communication

behavior of the application• nodes are processes, directed arcs are communications

• Resource Graph = hardware topology• nodes are CPUs and devices, CPU ports define may bus types

• Service Graph = services needed for communication and their dependencies• device drivers, interrupt handlers, other functions• also dependencies between services and hardware components• services are stored in an extendable library DREAMS

• Tool automatically generates code for each CPU • selection of services and devices that are really needed• allocation of services to CPUs• configuration of services and devices

15 / 21

Hw/Sw wrappers – COSY

• Philips and UPMC – Brunel et al. – DAC’2000• Transaction levels

• APP (applic.), SYS (system), VCI (generic bus), PHY (phys. bus)

• Separation between function and architecture, between computation and communication• functions are mapped to architectural components• communications between functions manually mapped to hw/sw

communication schemes defined at SYS level

• Library of hw/sw wrapper IP’s for specific schemes• using FIFOs, DMA, shared memory• on top of the pSOS RTOS, for software parts• on top of VCI, for hardware parts (parameterized VHDL)

• Performance simulation performed with VCC with performance models imported from COSY• delay equations for latency at SYS level

16 / 21

Hw/Sw wrappers – ROSES

• TIMA Laboratory, Grenoble, SLS Group

• Integration of heterogeneous and hard IP components

• Automatic synthesis of hardware and software wrappers

• Generation of a minimal and dedicated OS

• Target architecture • composition of any hardware IP components (processors, memories)

• any communication structure, also seen as an IP

17 / 21

ROSES

• Wrapper library• library of basic modules that fit different component types and

communication structures

• can be extended to various standards

• Architectural-independent API embedded into SystemC• high-level communication primitives

• OS and wrappers offer an efficient platform implementation

• application software does not need to be retargeted

18 / 21

ROSES – Virtual architecture model

• Input to the wrapper and OS generation processes

• Basic model: abstract netlist of virtual components

• Module wrapper isolates computation from communication

• Virtual port: set of hierarchical internal/external ports to request / provide communication services

blackbox(IP)

: configuration parameters

: wrapper

: module

: SW task

: virtual port

: virtual channel

: virtual component

19 / 21

ROSES – Wrapper architecture• Dissociates communication from computation

• HW wrapper: multi-point, multi-protocol• SW wrapper: multitask OS with preemption

• Application-specific on-chip HW-SW communication• component-based assembly approach for HW and SW wrappers

• extensible libraries of basic wrapper sub-modules

IP DSPMCU

wrapper

Communication interconnect

wrapper wrapper

HW Wrapper (CC)

internal bus

(MPU/DSP/IP)bus adaptor

ProtocolCtrl #1

ProtocolCtrl #4

ProtocolCtrl #3

ProtocolCtrl #2

CSAPI

Drivers

Application

OS services(scheduler, IT, I/O, …)

MPU

A.D.

Mem

20 / 21

ROSES – Design flow

Proc. Adapter

CA CA

HWWrapper

PA (ARM7)

HWS(timer)

CA(hsk)

HW wrapper library

Co-simulation library

Co-simul. generation

Executableco-simulation

model

Application

Processor

SWWrapper

send recv

fifo TS ...

wr rd ...

...

API’s

Comm./Sys. Services

Device Drivers

OS library

CSAPII/O & IT services

Dev. DriversCo-sim.

generationExecutable

co-simulationmodel

OS generation

HW wrappergeneration

SW wr.SW wr.

RTL Architecture

Comm. network

HW wr.

A B

HW wr.

C

µP1 µP2

ExtendedSystemC

ColifA

B

C

Emulation Platform

Synthesis

21 / 21

Tangram

• UFRGS – Sperb, Souza, Mello, Wagner – 2003

• Ambiente de suporte à integração de componentes IP heterogêneos num modelo de co-simulação distribuído• heterogeneidade de linguagens e de interfaces

• Baseado no DCB – Distributed Co-simulation Backbone

• Permite a interconexão virtual entre componentes com interfaces heterogêneas

• Adaptação automática entre linguagens

• Suporte à construção semi-automática de wrappers• reuso num ambiente de modelagem orientado a objetos

• biblioteca de wrappers e de templates para padrões (OCP) e componentes (femtoJava)

• Wrappers de co-simulação x wrappers de síntese