part2: platform-based design - donald pederson platform-based design p ... ericsson's internet...

1EE249Fall03

Part2: Platform-based Design

PPlatform

Design-SpaceExport

PlatformMapping

Architectural Space

Application SpaceApplication Instance

Platform Instance

System (Software + Hardware)Platform

ASV Triangles

2EE249Fall03

Outline

• A brief history of GSRC Platform-based Design

• Principles: Latest view

• Metropolis

• Three examples

– Pico-radio network

– Unmanned Helicopter controller

– Engine Controller

3EE249Fall03

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

4EE249Fall03

Platform-Based Design Definitions:Three Perspectives

• Systems Designers

• Semiconductor

• Academic (ASV)

5EE249Fall03

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

6EE249Fall03

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)

7EE249Fall03

Platforms

Platforms ExamplesCisco: ONS 15800 DWDM PlatformEricsson: Internet Services platformService

Nokia: Mobile Internet ArchitectureIntel: Personal Internet Client ArchitectureSony: Playstation 2

Application

TI: OMAPPhilips: NexperiaARM: PrimeXSys

System

HW

SW

Xilinx: Virtex IIeASIC: eUnit

Implementation

Fabrics

Manufacturing

8EE249Fall03

Platform Architectures: Philips Nexperia

Hardware Software

MiddlewareJavaTV, TVPAK, OpenTV, MHP/Java, proprietary ...

Applications

Nexperia Hardware

Streaming andPlatform Software

Streaming andPlatform Software K

erne

l: pS

OS

, VxW

orks

, Win

-CE

TM-xxxxD$

I$

TriMedia CPU

DEVICE IP BLOCK

DEVICE IP BLOCK

DEVICE IP BLOCK

.

.

.

DVP SYSTEM SILICON

PI B

US

MMI

DVP

MEM

OR

Y B

USDEVICE IP BLOCK

PRxxxxD$

I$

MIPS CPU

DEVICE IP BLOCK.

.

.DEVICE IP BLOCK

PI B

US

MIPS™ TriMedia™SDRAM

Source: Philips

9EE249Fall03

Platform Types

“Communication Centric Platform”– SONIC, Palmchip

– Concentrates on communication

– Delivers communication framework plus peripherals

– Limits the modeling efforts

SiliconBackplaneAgent™

Open Core Protocol™

SiliconBackplane™

(patented)

MultiChipBackplane™{

DSP MPEGCPUDMA

C MEM I O

SONICs Architecture

Source: G. Martin

10EE249Fall03

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 IIPlatform FPGA

11EE249Fall03

Platform Architectures: Philips Nexperia

TM-xxxxD$

I$

TriMedia CPU

DEVICE IP BLOCK

DEVICE IP BLOCK

DEVICE IP BLOCK

.

.

.

DVP SYSTEM SILICON

PI B

US

SDRAM

MMI

DVP

MEM

ORY

BUS

DEVICE IP BLOCK

PRxxxxD$

I$

MIPS CPU

DEVICE IP BLOCK.

.

.DEVICE IP BLOCK

PI B

US

TriMedia™MIPS™

Hardware Source: Philips

12EE249Fall03

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.

13EE249Fall03

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”

14EE249Fall03

Platform Architectures: Hardware is not enough!

Hardware

TM-xxxxD$

I$

TriMedia CPU

DEVICE IP BLOCK

DEVICE IP BLOCK

DEVICE IP BLOCK

.

.

.

DVP SYSTEM SILICON

PI B

US

MMI

DVP

MEM

ORY

BUSDEVICE IP BLOCK

PRxxxxD$

I$

MIPS CPU

DEVICE IP BLOCK.

.

.DEVICE IP BLOCK

PI B

US

MIPS™ TriMedia™

MiddlewareJavaTV, TVPAK, OpenTV, MHP/Java, proprietary ...

Applications

Nexperia Hardware

Streaming andPlatform SoftwareStreaming and

Platform Software Kern

el: p

SOS,

VxW

orks

, Win

-CE

Software

SDRAM

Source: Philips

15EE249Fall03

Software Platforms

Output DevicesInput devicesHardware Platform

I OHardware

Software

Network

Software Platform

Application SoftwarePlatform API

Software Platform

RTO

S

BIOS

Device Drivers Net

wor

kC

omm

unic

atio

n

Com

pilers

16EE249Fall03

Quote from Tully of Dataquest 2002

“This scenario places a premium on the flexibility and extensibility of the hardware platform. And it discourages system architects from locking differential advantages into hardware. Hence, the industry will gradually swing away from its tradition of starting a new SoC design for each new application, instead adapting platform chips to cover new opportunities.”

17EE249Fall03

Platform models today: hardware view

• HDL simulation

– HW implementation environment with full HW detail

– SW execution very slow and tied to expensive tool seats

• In-circuit emulation

– HW/SW integration environment with good debug

– Tools (emulators) are very expensive and software is introduced late

• FPGA prototyping

– HW/SW prototyping environment at high speed

– Debug of HW is difficult and SW is introduced late

18EE249Fall03

Platform models today: software view

• Host re-targeting

– SW environment for application development in real time

– No software benchmarking or hardware modeling

• Virtual machine with host software

– SW environment for hardware-specific application development

– No SW benchmarking and hardware models simple

• Software emulators

– SW environment for low-level timing-dependant SW

– No route to hardware implementation and validation

19EE249Fall03

So what is the problem?

• Software developers have a software-centric view

– Silicon prototypes arrive late in design cycle

– High-speed ISS models with simple hardware models

– Software tools do not interact with hardware implementations

• Hardware developers are involved too late

– Software integrated post synthesis or with RTL

– RTL simulations suited only to simple software tests

– Hardware tools are expensive

20EE249Fall03

“Platform-Based Design” concept as a major paradigm shift for Gigascale design

“Sangiovanni-Vincentelli, a key originator of the concept, defines a platform as….."

EETimes, 20th Year Anniversary Edition, September 12, 2002

21EE249Fall03

Electronic Design: A Vision

• Embedded Software will be increasingly critical in the Electronic Industry

• Embedded Software Design must not be seen as a problem in isolation, it is an, albeit essential, aspect of EMBEDDED SYSTEM DESIGN

• The vision is to change radically the way in which ESW is developed today by linking it:– Upwards in the abstraction layers to system functionality

– Downwards in the programmable platforms that support it thus providing the means to verify whether the constraints posed on Embedded Systems are met.

PPlatform

Design-SpaceExport

PlatformMapping

Architectural Space

Application SpaceApplication Instance

Platform Instance

System (Software + Hardware)Platform

Platform-Based Design

22EE249Fall03

Outline



• Metropolis

• Three examples




23EE249Fall03

Platform-Based Design (A. Sangiovanni-Vincentelli, Defining Platform-based Design, EEDesign, Oct. 2002)

• Layers of abstractions are precisely defined and fine tuned to allow only relevant information to pass from below to above.

• Designs built on top of these layers are then isolated from subsystem details that they don't need while they are provided with enough information to fully explore their design space.

• These layers of abstraction are called platforms.

Arch. PlatformDesign-Space

Exploration

API PlatformSpecification

Architectural Space

Application Space

Application Instance

Platform Instance

The system can be presented as the combination of a top-level view, a bottom level view, and a set of tools and methods that map between the layers of abstraction.

24EE249Fall03

Platforms: Evolution

In general, a platform is an abstraction layer that covers a number of possible refinements into a lower level. The platform representation is a library of components including interconnects from which the lower level refinement can choose.

Platform

Mapping Tools

Platform

Platform stack {

25EE249Fall03

Principles of Platform methodology:Meet-in-the-Middle

• Top-Down:– Define a set of abstraction layers

– From specifications at a given level, select a solution (controls, components) in terms of components (Platforms) of the following layer and propagate constraints

• Bottom-Up:– Platform components (e.g., micro-controller, RTOS,

communication primitives) at a given level are abstracted to a higher level by their functionality and a set of parameters that help guiding the solution selection process. The selection process isequivalent to a covering problem if a common semantic domain is used.

26EE249Fall03

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

Silicon Implementation

Application


Application

27EE249Fall03

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

28EE249Fall03

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

Geometrical Regularity Silicon Implementation

Architecture

Logic Regularity

Component Regularity and Reuse

Regular Fabrics

29EE249Fall03

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!

30EE249Fall03

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 isalready a design step!

– Meta-model in Metropolis (operational) and Trace Algebras (denotational) are used to capture this process and make it rigorous

31EE249Fall03

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 chooses 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 bahaviours.

– A SW implementation on a fixed architecture is a platform instance.

32EE249Fall03

A discipline for Platform-based Design

GG

Basic device & interconnect structures

Delay, variation,SPICE models

Silicon Implementation Platform

Functional Blocks,Interconnect

Cycle-speed, power, area

Architectural Platform

Manufacturing Interface


Microarchitecture(s)

Circuit Fabric(s)

S SV V SG

SGS

S

V

V

SS SSVV VV SS

Application

Kernels/BenchmarksProgramming Model:Models/Estimators

Architecture(s)

33EE249Fall03

Articulation Points, Research and Business Opportunities

Silicon Implementation Platform

Architectural Platform

Manufacturing Interface


Basic device & interconnect structures

Delay, variation,SPICE models

Microarchitecture(s)

Circuit Fabric(s)

S SV V SG

SGS

S

V

V

SS SSVV VV SSGG

Application

Architecture(s)

Kernels/BenchmarksProgramming Model:Models/Estimators

Functional Blocks,Interconnect

Cycle-speed, power, area

Distributed Systems and Embedded Software

Traditional Flows

Design for Manufacturing

34EE249Fall03

Outline



• Meta-model and Metropolis

• Three examples



– High-performance micro-processors

35EE249Fall03

Metropolis Framework

Design

Constraints

Function

Specification

Architecture (Platform)

Specification

Metropolis Infrastructure

• Design methodology• Meta model of computation• Base tools

- Design imports- Meta model compiler- Simulation

Synthesis/Refinement• Compile-time scheduling of concurrency• Communication-driven hardware synthesis• Protocol interface generation

Analysis/Verification• Static timing analysis of reactive systems• Invariant analysis of sequential programs• Refinement verification• Formal verification of embedded software

36EE249Fall03

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?

37EE249Fall03

Outline



• Embedded Software


• Three examples

– Pico-radio network (BWRC and Nokia)

– Unmanned Helicopter controller (Honeywell)


38EE249Fall03

A Hierarchical Application of the Paradigm:The Fractal Nature of Design!

Functional & PerformanceRequirements Network Architecture

Performance analysis

NetworkLevel

Radio NodeLevel

Functional & PerformanceRequirements Node Architecture


Functional & PerformanceRequirements Network Architecture


ModuleLevel

Source: Jan Rabaey

Constraints

Constraints

39EE249Fall03

Network Platforms

node

link

port

NPI I/O port

NP components:

• 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

40EE249Fall03

Network Platforms

node

link

port

NPI I/O port

NP components:

Network Platform Instance

CommunicationServices:- CS1:

Lossy BroadcastError rate: 33%Max Delay: 30 ms

- CS2: …

Network Platform API

ConstraintsBudgeting

PerformanceEstimates

41EE249Fall03

Network Platforms API

er21, er22, er23

er11, er12es1, es2, es3

event trace:

• 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

42EE249Fall03

Picoradio Network Platforms

CS S

CS S

Pull Push

Application Layer

SS C

C SS

Multi-hop message delivery

Network Layer

Power < 100 uW, BER ~ 0

C S=

C S

43EE249Fall03

Outline



• Embedded Software


• Three examples

– Pico-radio network (BWRC and Nokia)

– Unmanned Helicopter controller (Honeywell)


44EE249Fall03

Platform-Based Design of Unmanned Aerial Vehicles

Platform-Based Design

I

UAV System

II

Synchronous Embedded Control

III

Synchronous Platform Based UAV Design

45EE249Fall03

II. UAV System: Sensor Overview

R-50 Hovering

• 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

GPS Card

GPS Antenna

INS

46EE249Fall03

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

d dGPSINS

Software Request

Pull Configuration

Software

GPSINS

Sharedmemory

Push Configuration

47EE249Fall03

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

48EE249Fall03

Platform Based Design for UAVs

Sensors: INS, GPSActuators: Servo InterfaceVehicles: Yamaha R-50/R-

Max

Control Applications (Matlab)

• Goal

– Abstract details of sensors, actuators, and vehicle hardware from control applications

Application SpaceArchitectural

Space

Synchronous Embedded

Programming(Giotto)

• How?- Synchronous Embedded Programming Language (i.e. Giotto) Platform

49EE249Fall03

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

Sensors: INS, GPSActuators: Servo InterfaceVehicles: Yamaha R-50/R-

Max

Synchronous Embedded

Programming(Giotto)

Control Applications (Matlab)

Application SpaceArchitectural

Space

Virtual Avionics Platform

Device Platform

Language Platform

50EE249Fall03

Outline



• Metropolis

• Three examples




51EE249Fall03

Power Train Design

52EE249Fall03

The Design Problem

Given a set of specifications from a car manufacturer,

– Find a set of algorithm to control the power train

– Implement the algorithms on a mixed mechanical-electrical architecture (microprocessors, DSPs, ASICs, various sensors and actuators)

53EE249Fall03

Power-train control system design

• Specifications given at a high level of abstraction

• Control algorithms design

• Mapping to different architectures using performance estimation techniques and automatic code generation from models

• Mechanical/Electronic architecture selected among a set of candidates

54EE249Fall03

HW/SW implementation architecture

• a set of possible hw/sw implementations is given by– M different hw/sw implementation architectures– for each hw/sw implementation architecture m ∈{1,...,M},

• a set of hw/sw implementation parameters z– e.g. CPU clock, task priorities, hardware frequency, etc.

• an admissible set XZ of values for z

µControllers Library

OSEKRTOS

I/O drivers & handlers(> 20 configurable modules)

Application Programming Interface

Boot LoaderSys. Config.

TransportKWP 2000

CCP

ApplicationSpecificSoftware

Speedometer

Tachometer

Water tem

p.

Speedometer

Tachometer

Odom

eter---------------

ApplicationLibraries

CustomerLibraries

OSEKCOM

55EE249Fall03

The classical and the ideal design approach

• Classical approach (decoupled design)

– controller structure and parameters (r ∈ R, c ∈ XC)

– are selected in order to satisfy system specifications

– implementation architecture and parameters (m ∈ M, z ∈ XZ)

– are selected in order to minimize implementation cost

– if system specifications are not met, the design cycle is repeated

• Ideal approach

– both controller and architecture options (r, c, m, z) are selected at the same time to

– minimize implementation cost

– satisfy system specifications

– too complex!!

56EE249Fall03

Platform stack & design refinements

Implementation Space

Application Space

Platform 4

Platform 3

Platform 2

Platform 1

implementation instance

application instance

plat.3 instance

plat.2 instance

PlatformDesign-Space

Export

PlatformMapping

Refinement

Platform i platform i instance

Platform i+1 platform i+1 instance

57EE249Fall03

Design MethodologyD

ES

IGN

Power-train SystemBehavior

Power-train System Specifications

FunctionalDecomposition

Capture SystemArchitecture

ElectronicSystem

Mapping

Operationsand MacroArchitecture

PerformanceBack-Annotation

HW and SWComponents

Implementation ComponentsVerify Components

Functions

Capture ElectronicArchitecture

HW/SWpartitioning

Design MechanicalComponents

OperationRefinement

CaptureElectrical/Mechanical

Architecture

Partitioning andOptimization

Functional Network

Operational Architecture (ES)

VerifyPerformance

A2

A3

A4

A5

58EE249Fall03

Implementation abstraction layer• we introduce an implementation abstraction layer

– which exposes ONLY the implementation non-idealities that affect the performance of the controlled plant, e.g.

– control loop delay

– quantization error

– sample and hold error

– computation imprecision

• at the implementation abstraction layer, platform instances are described by

– S different implementation architectures

– for each implementation architecture s ∈{1,...,S},

– a set of implementation parameters p

– e.g. latency, quantization interval, computation errors, etc.

– an admissible set XP of values for p

59EE249Fall03

Platform stack & design refinements

PlatformDesign-Space

Export

PlatformMapping

Implementation Space

Application Space

Platform 2

Platform 1 platform 1instance

Platform n

platform 2instance

implementationinstances

Refinement

(r,c)

(s,p)

(r,c,s,p)

functional layer

implementation abstraction layerimplem. struc. & par. (s,p)

control struc. & par. (r,c)

(r,c,s,p)

hw/sw implementationstruc & par. (m,z)

hw/sw implementation layer

60EE249Fall03

Effects of controller implementation in the controlled plant performance

d

Controller

y Plant wu

r∆w

∆r ∆u +

nu

+

+

nr

nw

• modeling of implementation non-idealities:

– ∆u, ∆r, ∆w : time-domain perturbations

– control loop delays, sample & hold , etc.

– nu , nr , nw :value-domain perturbations

– quantization error, computation imprecision, etc.

61EE249Fall03

Choosing an Implementation Architecture

Output DevicesInput devices

Hardware Platform

I O

Hardware

network

RTO

S

BIOS

Device Drivers

Net

wor

k C

omm

unic

atio

n

DUAL-CORE

Architectural Space (Performance)

Platform Instance

Application Instances

System Platform(no ISA)

Platform Design Space Exploration

Platform API

Software Platform


Hardware Platform

I O

Hardware

network

HITACHIR

TOS

BIOS

Device Drivers

Net

wor

k C

omm

unic

atio

n

HITACHI

RTO

S

BIOS

Device Drivers

Net

wor

k C

omm

unic

atio

n


Hardware Platform

I O

Hardware

network

ST10R

TOS

BIOS

Device Drivers

Net

wor

k C

omm

unic

atio

n

ST10

Application Software

Application Space (Features)

Application Software

PlatformSpecification

DUAL-CORE

62EE249Fall03

Application effort

First Application: 10 months

Successive Application: 4 months

Application code (lines) Calibrations (Bytes)Total Modified Total Modified71,000 1,400 (2%) 28,000 20Modifications due to compiler changeDevice drivers SW(lines) Calibrations (Bytes)Total Modified Total Modified6000 1200 (20%) 1000 10Modifications due to compiler change and new BIOS interface

part2: platform-based design - donald pederson platform-based design p ... ericsson's internet...

Documents