Transcript Systems-on-Chip: Challenges and Models of Computation

Defining Platform-Based Design
Outline
A brief history of GSRC Platform-based Design
Principles: Latest view
Metropolis
Two examples

Pico-radio network

Unmanned Helicopter controller
2
Platform Based Design
What 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….
3
Platform-Based Design Definitions:
Three Perspectives
Systems Designers
Semiconductor
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 costeffectively 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
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: PrimeXSys
Implementation
Fabrics
Manufacturing
Xilinx: Virtex II
eASIC: eUnit
7
Platform Architectures: Philips Nexperia
MIPS CPU
D$
SDRAM
TriMedia™
MMI
TriMedia CPU
PRxxxx
I$
D$
TM-xxxx
DEVICE IP BLOCK
PI BUS
.
.
.
DEVICE IP BLOCK
.
.
.
DEVICE IP BLOCK
DVP SYSTEM SILICON
Hardware
Middleware
JavaTV, TVPAK, OpenTV,
MHP/Java, proprietary ...
DEVICE IP BLOCK
PI BUS
DEVICE IP BLOCK
DVP MEMORY BUS
DEVICE IP BLOCK
I$
Applications
Streaming and
Platform Software
Kernel: pSOS, VxWorks, Win-CE
MIPS™
Nexperia Hardware
Software
Source: Philips
8
Platform Types
“Communication Centric Platform”

SONIC, Palmchip

Concentrates on communication


Delivers communication framework plus peripherals
Limits the modeling efforts
SONICs Architecture
DMA
CPU
DSP
MPEG
{
MultiChip
Backplane™
SiliconBackplane™
(patented)
Open Core
Protocol™
C
MEM
I
O
SiliconBackplane
Agent™
Source: G. Martin
9
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
Triscend A7
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!
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
13
Software Platforms
Platform API
Application Software
Software
Software Platform
Hardware Platform
Input devices
Hardware
Output Devices
I
O
RTOS
Software Platform
Device Drivers
BIOS
Network
Communication
Network
14
ASV Triangles (1998)
Application Space
Application Instance
Platform
Mapping
System
Platform
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
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
A brief history of GSRC Platform-based Design
Principles: Latest version
Meta-model and Metropolis
Two examples

Pico-radio network

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
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
Silicon Implementation
Application
Silicon Implementation
20
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
21
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
22
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!
23
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
24
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.
25
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
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...
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
28
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?
29
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)
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:
- CS1:
Lossy Broadcast
Error rate: 33%
Max Delay: 30 ms
- CS2:
…
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 m1, m2, m3
• Quality of Service (platform parameters):
• Losses: 1 ( m3)
• Error rate: 33%
• In-order delivery
er11, er12
es1, es2, es3
• D(m3) = t(er23) – t (es3) = 30 ms
er21, er22, er23
event trace:
34
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
S
C
C
S
Multi-hop message delivery
35
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)
36
Platform-Based Design of Unmanned Aerial
Vehicles
I
PlatformBased 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
 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
40
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)
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
 Device Platform



Isolates details of sensor/actuators
from embedded control programs
Control Applications
Communicates with each
(Matlab)
sensor/actuator according to its own
Synchronous
data format, context, and timing
Embedded
requirements
Programming
Presents an API to embedded control
(Giotto)
programs for accessing
sensors/actuators
Language Platform
Application Space
 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
Architectural Space
Sensors: INS, GPS
Actuators: Servo Interface
Vehicles: Yamaha R-50/RMax
Device Platform
Virtual Avionics
Platform
42