Communication synthesis 1 Motivation Architecture of embbeded systems

Communication synthesis 1

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 2

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 3

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 4

IP reuse process • providers and consumers may IP creation IP qualification belong – to the same organization – related by an intranet – to different organizations – electronic market – related by the internet IP provider IP classification IP search IP evaluation IP integration IP transfer • legal issues • business models • IP protection IP consumer = So. C designer 5

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 6

Bus-based design • IP components adapt to a bus specification • either directly or through a wrapper • IBM Core. Connect family of buses – PLB, OCB, DCR • Blue. Logic Core Library • ARM AMBA family of buses – AHB, ASB, APB • AMBA Design Kit – set of basic components + development and simulation environment • Sonics Silicon Backplane Micro. Network • • 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 Micro. Network 7

Coral • IBM – Bergamaschi et al. – DAC’ 2000, IEEE D&T Sept/Oct 2001 • So. C design around the Core. Connect 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 8

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 • Core. Creator development environment for OCP-compliant cores 9

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 10

Generating hardware wrappers – POLARIS • Stanford – Smith and De. Micheli – 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) 11

Software IP’s SW reuse Application software with software IP’s direct coupling SW re-targeting API implementation hardware and software RTOS, other Hd. S API abstracting hardware platform SW reuse SW synthesis • RTOS for embedded systems • several academic and commercial solutions • No current standards for the API • newly created VSIA DWG on Hd. S 12

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 13

Generating software wrappers – TERec. S • 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 14

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 p. SOS 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 15

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 16

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 System. C • high-level communication primitives • OS and wrappers offer an efficient platform implementation • application software does not need to be retargeted 17

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 : wrapper : module blackbox (IP) : SW task : configuration parameters : virtual component : virtual port : virtual channel 18

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 Application CSAPI OS services (scheduler, IT, I/O, …) Drivers HW Wrapper (CC) Mem MPU (MPU/DSP/IP) bus adaptor A. D. internal bus MCU IP DSP Protocol Ctrl #4 Ctrl #3 Ctrl #2 Ctrl #1 wrapper Communication interconnect 19

ROSES – Design flow Extended System. C Co-simulation library Colif A Executable co-simulation model Co-simul. generation C OS library B API’s HW wrapper library PA (ARM 7) HWS (timer) CA (hsk) send HW wrapper generation fifo A CA Emulation Platform TS . . . Device Drivers RTL Architecture µP 1 µP 2 CA . . . Comm. /Sys. Services OS generation wr Proc. Adapter recv HW Wrapper B C SW wr. HW wr. Comm. network Synthesis Co-sim. generation SW Wrapper . . . rd Processor Application CSAPI I/O & IT services Dev. Drivers Executable co-simulation model 20

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 (femto. Java) • Wrappers de co-simulação x wrappers de síntese 21