part2: platform-based design - donald pederson platform-based design p ... ericsson's internet...
Post on 30-May-2018
219 Views
Preview:
TRANSCRIPT
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
• A brief history of GSRC Platform-based Design
• Principles: Latest view
• Metropolis
• Three examples
– Pico-radio network
– Unmanned Helicopter controller
– Engine Controller
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
Silicon Implementation
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
Silicon Implementation
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
Silicon Implementation
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
• 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
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
• 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)
– Engine Controller
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
Performance analysis
Functional & PerformanceRequirements Network Architecture
Performance analysis
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
• 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)
– Engine Controller
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
• A brief history of GSRC Platform-based Design
• Principles: Latest view
• Metropolis
• Three examples
– Pico-radio network
– Unmanned Helicopter controller
– Engine Controller
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
Output DevicesInput devices
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
Output DevicesInput devices
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
top related