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 DefinitionsThree
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
Platforms
Platforms
Examples
8
Platform Architectures Philips Nexperia
MIPS
TriMedia
SDRAM
TriMedia CPU
MMI
MIPS CPU
TM-xxxx
D
PRxxxx
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

• Hardware Software

Source Philips
9
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
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
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
Software Platforms
Compilers
15
ASV Triangles (1998)

Application Space
Application Instance
Platform Mapping
System
Platform
Platform Design-Space Export
Platform Instance
Architectural Space
16
A Discipline of Platform-Based Design
Architectural Platform
S
S
V
V
S
G
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
ASV Platforms
In general, a platform is an abstraction layer
that covers a number of possible refinements into
a lower level.
19
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
Metropolis Framework
Design Constraints
Architecture (Platform) Specification

• 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 all design 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
A Hierarchical Application of the ParadigmThe
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 lt 100 uW, BER 0
C
S
Network Layer
S
C
S
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
Platform-Based Design of Unmanned Aerial Vehicles
38
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
GPS
INS
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
Platform Based Design for UAVs
Control Applications (Matlab)

• Goal
• Abstract details of sensors, actuators, and
  vehicle hardware from control applications
• How?
• Synchronous Embedded Programming Language (i.e.
  Giotto)
• Platform

Sensors INS, GPSActuators Servo
InterfaceVehicles Yamaha R-50/R-Max
42
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