Defining Platform-Based Design - PowerPoint PPT Presentation

Loading...

PPT – Defining Platform-Based Design PowerPoint presentation | free to download - id: 7ad3f8-YzEyN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Defining Platform-Based Design

Description:

Defining Platform-Based Design – PowerPoint PPT presentation

Number of Views:23
Avg rating:3.0/5.0
Slides: 43
Provided by: Alberto371
Learn more at: http://www.inf.ufrgs.br
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com