Communication synthesis

1. Communication synthesis

2. 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. 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. 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. IP reuse process IP creation • 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 IP qualification IP provider IP classification IP search IP transfer IP evaluation IP consumer = SoC designer IP integration

6. 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. 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. 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. 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. 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. 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. Software IP’s • RTOS for embedded systems • several academic and commercial solutions • No current standards for the API • newly created VSIA DWG on HdS SW reuse Application software with software IP’s direct coupling SW re-targeting API abstracting hardware platform API implementation hardware and software RTOS, other HdS SW reuse SW synthesis

13. 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. 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. 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. 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. 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. 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) : wrapper : module : SW task : configuration parameters : virtual component : virtual port : virtual channel

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

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

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