Defining Platform-Based Design

1. Defining Platform-Based Design

2. Outline • A brief history of GSRC Platform-based Design • Principles: Latest view • Metropolis • Two examples • Pico-radio network • Unmanned Helicopter controller

3. Platform Based DesignWhat is it? • Question: • How many definitions of Platform Based Design are there? • Answer: • How many people to you ask? • What does the confusion mean? • It is a definition in transition. Or • Marketing has gotten involved….

4. Platform-Based Design Definitions:Three Perspectives • Systems Designers • Semiconductor • Academic (ASV)

5. System Definition Ericsson's Internet Services Platform is a new tool for helping CDMA operators and service providers deploy Mobile Internet applications rapidly, efficiently and cost-effectively Source: Ericsson press release

6. Semiconductor Definition We define platform-based design as the creation of a stable microprocessor-based architecture that can be rapidly extended, customized for a range of applications, and delivered to customers for quick deployment. Source: Jean-Marc Chateau (ST Micro)

7. Service Cisco: ONS 15800  DWDM Platform Ericsson: Internet Services platform Application Nokia: Mobile Internet Architecture Intel: Personal Internet Client Architecture Sony: Playstation 2 System TI: OMAP Philips: Nexperia ARM: PrimeXSys SW HW Implementation Fabrics Xilinx: Virtex II eASIC: eUnit Manufacturing Platforms Platforms Examples

8. Hardware Software Applications MiddlewareJavaTV, TVPAK, OpenTV, MHP/Java, proprietary ... Kernel: pSOS, VxWorks, Win-CE Streaming and Platform Software Nexperia Hardware Platform Architectures: Philips Nexperia MIPS™ TriMedia™ SDRAM MMI MIPS CPU TriMedia CPU D$ PRxxxx TM-xxxx D$ I$ I$ DEVICE IP BLOCK DEVICE IP BLOCK DEVICE IP BLOCK DEVICE IP BLOCK . . . . . . DVP MEMORY BUS PI BUS PI BUS DEVICE IP BLOCK DEVICE IP BLOCK DVP SYSTEM SILICON Source: Philips

9. DMA DSP CPU MPEG Open Core Protocol™ { MultiChip Backplane™ SiliconBackplane™ (patented) C MEM I O SiliconBackplane Agent™ Platform Types “Communication Centric Platform” • SONIC, Palmchip • Concentrates on communication • Delivers communication framework plus peripherals • Limits the modeling efforts SONICs Architecture Source: G. Martin

10. Triscend A7 Platform Types “Highly Programmable Platform” • Triscend A7. Altera Excalibur, Xilinx Platform FPGA, Chameleon • Concentrates on reconfigurability • Delivers reconfigurable processor plus programmable logic • Modeling efforts undetermined because of programmable parts Xilinx Vertex II Platform FPGA

11. IP Block Performance Inter IP Communication Performance Models IP Blocks SDF Wire Load RTL Clusters SW Models RTL Gate Level Model Capacity Load Transistor Model Capacity Load cluster cluster cluster abstract abstract abstract abstract 1970’s 1980’s 1990’s Year 2000 + ASV: The Next Level of Abstraction in the Architecture Space

12. Hardware Platforms (1998) A Hardware Platform is a family of architectures that satisfy a set of architectural constraints imposed to allow the re-use of hardware and software components.

13. Hardware Platforms Not Enough! • Hardware platform has to be “extended” upwards to be really effective in time-to-market • Interface to the application software is an “API” • Software layer performs abstraction: • Programmable cores and memory subsystem with (RT)OS • I/O subsystem via Device Drivers

14. Platform API Application Software Software Software Platform Hardware Platform Hardware Input devices Output Devices I O Network Software Platform Network Communication RTOS Device Drivers BIOS Software Platforms Compilers

15. ASV Triangles (1998) Application Space Application Instance Platform Mapping System Platform Platform Design-Space Export Platform Instance Architectural Space

16. Application Programming Model: Models/Estimators Kernels/Benchmarks Architecture(s) Microarchitecture(s) G V V S S S Cycle-speed, power, area Functional Blocks, Interconnect Circuit Fabric(s) Manfacturing Interface Delay, variation, SPICE models Basic device & interconnect structures Silicon Implementation A Discipline of Platform-Based Design Architectural Platform V G V S S S Silicon Implementation Platform S V S • G V S Source: R. Newton

17. Outline • A brief history of GSRC Platform-based Design • Principles: Latest version • Meta-model and Metropolis • Two examples • Pico-radio network • Unmanned Helicopter controller

18. { Platform Platform stack Mapping Tools Platform ASV Platforms In general, a platform is an abstraction layer that covers a number of possible refinements into a lower level.

19. Upper layer of abstraction Constraints Performance Annotation Lower layer of abstraction ASV Platforms • The design process is meet-in-the-middle: • Top-down: map an instance of the top platform into an instance of the lower platform and propagate constraints • Bottom-up: build a platform by defining the “library” that characterizes it and a performance abstraction (e.g., number of literals for tech. Independent optimization, area and propagation delay for a cell in a standard cell library) • The library has elements and interconnects For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.

20. Platform-Based Implementation • Platforms eliminate large loop iterations for affordable design • Restrict design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass success • The number and location of intermediate platforms is the essence of platform-based design Application Application Silicon Implementation Silicon Implementation

21. Platform-Based Design Process • Different situations will employ different intermediate platforms, hence different layers of regularity and design-space constraints • Critical step is defining intermediate platforms to support: • Predictability: abstraction to facilitate higher-level optimization • Verifiability: ability to ensure correctness Architecture Logic Regularity Component Regularity and Reuse Regular Fabrics Geometrical Regularity Silicon Implementation

22. Implementation Process • Skipping platforms can potentially produce a superior design by enlarging design space – if design-time and product volume ($) permits • However, even for a large-step-across-platform flow there is a benefit to having a lower-bound on what is achievable from predictable flow Architecture Logic Regularity Component Regularity and Reuse Regular Fabrics Geometrical Regularity Silicon Implementation

23. Tight Lower Bounds • The larger the step across platforms, the more difficult to: predict performance, optimize at system level, and provide a tight lower bound • Design space may actually be smaller than with smaller steps since it is more difficult to explore and restriction on search impedes complete design space exploration • The predictions/abstractions may be so wrong that design optimizations are misguided and the lower bounds are incorrect!

24. Design Flow • Theory: • Initial intent captured with declarative notation • Map into a set of interconnected component: • Each component can be declarative or operational • Interconnect is operational: describes how components interact • Repeat on each component until implementation is reached • Choice of model of computations for component and interaction is already a design step! • Meta-model in Metropolis (operational) and Trace Algebras (denotational) are used to capture this process and make it rigorous

25. Consequences • There is no difference between HW and SW. Decision comes later. • HW/SW implementation depend on choice of component at the architecture platform level. • Function/Architecture co-design happens at all levels of abstractions • Each platform is an “architecture” since it is a library of usable components and interconnects. It can be designed independently of a particular behavior. • Usable components can be considered as “containers”, i.e., they can support a set of behaviors. • Mapping choses one such behavior. A Platform Instance is a mapped behavior onto a platform. • A fixed architecture with a programmable processor is a platform in this sense. A processor is indeed a collection of possible bahaviors. • A SW implementation on a fixed architecture is a platform instance.

26. Outline • A brief history of GSRC Platform-based Design • Principles: Latest view • Meta-model and Metropolis • Three examples • Pico-radio network • Unmanned Helicopter controller • High-performance micro-processors

27. Function Specification Metropolis Framework Architecture (Platform) Specification Design Constraints • Metropolis Infrastructure • Design methodology • Meta model of computation • Base tools • - Design imports • - Meta model compiler • - Simulation • Analysis/Verification • Static timing analysis of reactive systems • Invariant analysis of sequential programs • Refinement verification • Formal verification of embedded software • Synthesis/Refinement • Compile-time scheduling of concurrency • Communication-driven hardware synthesis • Protocol interface generation

28. Models of Computation: And There are More... • Continuous time (ODEs) • Spatial/temporal (PDEs) • Discrete time • Rendezvous • Synchronous/Reactive • Dataflow • ... Each of these provides a formal framework for reasoning about certain aspects of embedded systems. Tower of Babel, Bruegel, 1563 Source: Ed Lee

29. Metropolis Meta Model • Do not commit to the semantics of a particular Model of Computation (MoC) • Define a set of “building blocks”: • specifications with many useful MoCs can be described using the building blocks. • unambiguous semantics for each building block. • syntax for each building block èa language of the meta model. • Represent objects at alldesign phases (mapped or unmapped) Question: What is a good set of building blocks?

30. Outline • A brief history of GSRC Platform-based Design • Principles: Latest view • Embedded Software • Meta-model and Metropolis • Two examples • Pico-radio network (BWRC and Nokia) • Unmanned Helicopter controller (Honeywell)

31. Functional & Performance Requirements Functional & Performance Requirements Functional & Performance Requirements Network Architecture Node Architecture Network Architecture Radio Node Level Performance analysis Performance analysis Performance analysis A Hierarchical Application of the Paradigm:The Fractal Nature of Design! Network Level Constraints Constraints Module Level Source: Jan Rabaey

32. Network Platforms NP components: node link port NPI I/O port • Network Platform Instance: set of resources (links and protocols) that provide Communication Services • Network Platform API: set of Communication Services • Communication Service: transfer of messages between ports • Event trace defines order of send/receive methods • Quality of service

33. Network Platforms • Communication • Services: • CS1: • Lossy Broadcast • Error rate: 33% • Max Delay: 30 ms • CS2: • … Network Platform API Performance Estimates Constraints Budgeting NP components: node link port NPI I/O port Network Platform Instance

34. Network Platforms API • NP API: set of Communication Services (CS) • CS: message transfer defined by ports, messages, events (modeling send/receive methods), event trace • Example • CS: lossy broadcast transfer of messages m1, m2, m3 • Quality of Service (platform parameters): • Losses: 1 ( m3) • Error rate: 33% • In-order delivery • D(m3) = t(er23) – t (es3) = 30 ms er11, er12 es1, es2, es3 er21, er22, er23 event trace:

35. Picoradio Network Platforms Application Layer C C S S S S Push Pull C S = Power < 100 uW, BER ~ 0 C S Network Layer S S C S S C Multi-hop message delivery

36. Outline • A brief history of GSRC Platform-based Design • Principles: Latest view • Embedded Software • Meta-model and Metropolis • Three examples • Pico-radio network (BWRC and Nokia) • Unmanned Helicopter controller (Honeywell) • Micro-processor and Chip Design (Intel and Cypress)

37. I II III Synchronous Embedded Control Synchronous Platform Based UAV Design Platform-Based Design UAV System Platform-Based Design of Unmanned Aerial Vehicles

38. R-50 Hovering INS GPS Card GPS Antenna II. UAV System: Sensor Overview • Goal: basic autonomous flight • Need: UAV with allowable payload • Need: combination of GPS and Inertial Navigation System (INS) • GPS (senses using triangulation) • Outputs accurate position data • Available at low rate & has jamming • INS (senses using accelerometer and rotation sensor) • Outputs estimated position with unbounded drift over time • Available at high rate • Fusion of GPS & INS provides needed high rate and accuracy

39. II. UAV System: Sensor Configurations • Sensors may differ in: • Data formats, initialization schemes (usually requiring some bit level coding), rates, accuracies, data communication schemes, and even data types • Differing Communication schemes requires the most custom written code per sensor Software Software Request Shared memory d d INS GPS GPS INS Pull Configuration Push Configuration

40. III. Synchronous Control • Advantages of time-triggered framework: • Allows for composability and validation • These are important properties for safety critical systems like the UAV controller • Timing guarantees ensure no jitter • Disadvantages: • Bounded delay is introduced • Stale data will be used by the controller • Implementation and system integration become more difficult • Platform design allows for time-triggered framework for the UAV controller • Use Giotto as a middleware to ease implementation: • provides real-time guarantees for control blocks • handles all processing resources • Handles all I/O procedures

41. Synchronous EmbeddedProgramming(Giotto) Application Space Architectural Space Platform Based Design for UAVs • Goal • Abstract details of sensors, actuators, and vehicle hardware from control applications • How? • Synchronous Embedded Programming Language (i.e. Giotto) • Platform Control Applications (Matlab) Sensors: INS, GPSActuators: Servo InterfaceVehicles: Yamaha R-50/R-Max

42. Control Applications (Matlab) Synchronous EmbeddedProgramming(Giotto) Language Platform Application Space Architectural Space Device Platform Virtual Avionics Platform Sensors: INS, GPSActuators: Servo InterfaceVehicles: Yamaha R-50/R-Max Platform Based Design for UAVs • Device Platform • Isolates details of sensor/actuators from embedded control programs • Communicates with each sensor/actuator according to its own data format, context, and timing requirements • Presents an API to embedded control programs for accessing sensors/actuators • Language Platform • Provides an environment in which synchronous control programs can be scheduled and run • Assumes the use of generic data formats for sensors/actuators made possible by the Device Platform