Defining PlatformBased Design Outline u A brief history

Defining Platform-Based Design

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

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

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

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 5

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) 6

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

Platform Architectures: Philips Nexperia MIPS CPU D$ SDRAM Tri. Media™ MMI Tri. Media CPU PRxxxx I$ I$ DEVICE IP BLOCK Middleware Java. TV, TVPAK, Open. TV, MHP/Java, proprietary. . . DEVICE IP BLOCK PI BUS DEVICE IP BLOCK DVP MEMORY BUS DEVICE IP BLOCK . . . D$ TM-xxxx Applications DEVICE IP BLOCK . . . DEVICE IP BLOCK DVP SYSTEM SILICON Streaming and Platform Software Kernel: p. SOS, Vx. Works, Win-CE MIPS™ Nexperia Hardware Software Source: Philips 8

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

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

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

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. 12

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

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

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

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

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

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

ASV Platforms The design process is meet-inthe-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) Upper layer of abstraction Constraints Performance Annotation Lower layer of abstraction 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. The library has elements and interconnects 19

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

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

Implementation Process u. Skipping platforms can potentially produce a superior design by enlarging design space – if design-time and product volume ($) permits u. 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 22

Tight Lower Bounds u. The larger the step across platforms, the more difficult to: predict performance, optimize at system level, and provide a tight lower bound u. 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 u. The predictions/abstractions may be so wrong that design optimizations are misguided and the lower bounds are incorrect! 23

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

Consequences u There is no difference between HW and SW. Decision comes later. u HW/SW implementation depend on choice of component at the architecture platform level. u Function/Architecture co-design happens at all levels of abstractions s s 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 25

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

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

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

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

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

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

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 32

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

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 m 1, m 2, m 3 • Quality of Service (platform parameters): • Losses: 1 ( m 3) • Error rate: 33% • In-order delivery er 1, er 12 es 1, es 2, es 3 • D(m 3) = t(er 23) – t (es 3) = 30 ms 1 er 21, er 22, er 23 event trace: 34

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

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

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

II. UAV System: Sensor Overview R-50 Hovering GPS Card GPS Antenna • 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 INS 38

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 Request Software Shared memory d INS d GPS Pull Configuration INS GPS Push Configuration 39

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

Platform Based Design for UAVs u Goal s Abstract details of sensors, actuators, and vehicle hardware from control applications u How? s Synchronous Embedded Programming Language (i. e. Giotto) s Platform Control Applications (Matlab) Synchronous Embedded Programming (Giotto) Application Space Architectural Space Sensors: INS, GPS Actuators: Servo Interface Vehicles: Yamaha R-50/RMax 41

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