System Level Design: Orthogonalization of Concerns and Platform-Based Design

1
System Level Design Orthogonalization of
Concerns and Platform-Based Design

• K. Keutzer, S. Malik, R. Newton, J. Rabaey, and
  A. Sangiovanni-Vincentelli
• Presented By David Nguyen

2
The Cost of System Design

• Manufacturing Costs
• The material cost of producing the product
• Non-Recurring Engineering (NRE) Costs
• Designing the product
• Ex. Engineers, Testing Equipment
• Tooling purchases needed for manufacturing
• Ex. Tools, masks

3
How to Make Money?

• TotalCost UnitsManufacturingCosts NRE.
• Income Units Cost/Unit
• Success is Income gt TotalCost by balancing
• Units Produced/Sold
• Manufacturing Costs per Unit
• Non-Recurring Engineering Costs
• Price we sell at

4
Problem and Solutions?

• Problem Because of increased pressures (ex. time
  to market, complexity), making money is harder.
  How can we cope with this?
• Solution Platform Based Design Determine a
  common hardware denominator which can be shared
  across multiple applications.
• Reason The NRE cost is amortized because of the
  increased number of units (as a result of its use
  in multiple applications).

5
System Design Methodology Orthogonalization of
Concerns

• Orthogonalization of Concerns is the separation
  of the various aspects of design to allow more
  effective exploration of alternative solutions.
• Function and Architecture
• Communication and Computation
• Functionality and Timing

6
Function Based Design

• A function is an abstract view of the behavior of
  an aspect of the system.
• display the result is a function.
• display the result on the LCD display is NOT a
  function.
• Functional specification should be defined
  formally and contain a formal underlying
  mathematical model model of computation.
• This allows us to handle verification via
  formalism, abstraction, and decomposition.
• Formally defined system (with underlying model of
  computation) gives us the ability to synthesize
  the functionality.

7
Communication Based Design

• Edwards Lee says we should be able to use many
  models of computation in one system.
• The problem is how do we get all of these
  different components, with different models of
  computation, talking to each other?
• Sol1 Design a communication standard which works
  for everything (Complex)
• Sol2 Design a communication method in a case by
  case fashion. (Easier)

8
Micro-Architecture

• Architecture an interface specification that
  describes the functionality of an implementation,
  while being independent of the actual
  implementations
• X86 instruction set architecture.
• Micro-Architecture defines how the architecture
  functionality is actually realized as a
  composition of modules and components, along with
  their associated software
• Intel Pentium 4, AMD Athlon XP

9
Mapping

• The functions of the system are assigned (mapped)
  to the components of the micro-architecture.
• Only after this is done, do notions of cost and
  performance appear. (How fast can I perform my
  functions and how much will it cost me?)
• The result is refined mapped micro-architecture
  that is guaranteed to meet design constraints or
• A mapped micro-architecture that signals
  something cannot be guaranteed. In this case, we
  need to either change the micro-architecture
  used, or make changes in the function space.

10
Link to Implementation

• Once the mapping of functions to
  micro-architecture is deemed as feasible, the
  micro-architecture is then implemented.
• The hardware and software components can be a
  special purpose design, or already designed in a
  current library.

11
Platform Based Design

• To reduce design costs, reuse is a must!
• It is important to find common architectures that
  can support a variety of applications as well as
  the future evolution of a given application.
• Implementing onto a platform should require
  little effort in comparison to a totally new
  implementation.
• Platforms
• Hardware
• Software
• System

12
Hardware Platforms

• A family of micro-architectures that allow the
  substantial re-use of software
• Hardware Platforms have two constraints
• They must be able to support some degree of
  functionality (minimum speed and memory).
• They must meet production and design costs
• These two define an application space of
  supported functionality.
• Advocates the meet in the middle design
  approach.

13
Software Platforms

• To be useful, a hardware platform has to be
  abstracted at a level where the application
  software sees a high-level interface to the
  hardware (API).
• With an API defined, the application software can
  be re-used for every platform instance.
• Given the precise definition of the API and the
  hardware platform, the authors feel like they can
  synthesize most of the software layer.

14
System Platforms

• Combination of the software and hardware
  platform.
• ASV Cones
• Vertex is the API
• Application Instance is mapped to the API
• A Family of micro-architectures implements the
  APIs with varying costs and performance
• Tradeoff between level of abstraction and the
  diversity of the platform instances.

15
Examples

• Philips VideoTop Digital Video Broadcast System
• Magneti-Marelli Automotive Engine Control
• Testing was done on 3 different CPUs, each with
  two different software partitions.
• Estimations performed in VCC were accurate to
  about 11
• BWRC InterCom.
• Implemented Voice-based protocol stack
• Took about 1,200 lines of C-code
• A traditional implementation with Strong-Arm
  would take about 30,000 lines (including the
  RTOS)

16
MESCAL

• Modern Embedded Systems, Compilers,
  Architectures, and Languages
• The Goal of MESCAL is to develop methodologies,
  tools, and appropriate algorithms to support the
  efficient development of fully programmable,
  platform-based designs for specific application
  domains.

17
MESCAL Assumption

• General purpose programmable solutions will not
  be likely to meet aggressive performance and
  power constraints and useful generality.
• Domain-specific programmable solutions are
  required to deliver the benefit of
  programmability while still delivering acceptable
  performance.
• Network/Video Processors vs. General Purpose
  processors.

18
Architecture Specialized Functional Units

• Dramatic Speedup in function execution.
• MESCAL uses IMPACT EPIC (Explicitly Parallel
  Instruction Computing) architecture class for
  individual processing units.
• They can better exploit instruction level
  parallelism (ILP)
• This is a powerful mechanism to exploit
  fine-grained concurrency in a retargetable manner.

19
Architecture Multiple Levels of Parallelism

• Multiple Levels of Parallelism
• Instruction Level Parallelism is exploited though
  an explicitly (EPIC) parallel architecture.
• Thread/Process level parallelism through
  heterogeneous processing and networking.

20
Architecture Template and Design Methodology

• There exists design templates which allow for
  rapid prototyping of networks of processing
  elements.
• The design methodology utilizes a classic
  measurement based feedback design loop.

21
Programmers Model

• The goal of MESCAL Programmers Model is to
  present the programmer with an abstraction of the
  architecture while helping the compiler generate
  efficient code for the new architectural
  platform.
• It combines a bottom up and top down approach.

22
MESCAL Compiler

• The objective of the MESCAL compiler is to
  develop a highly optimized, retargetable compiler
  infrastructure that enables a set of interesting
  source applications to be efficiently mapped into
  a family of fully programmable architectures and
  micro-architectures.
• We would like the compiler to automatically
  synthesize RTOS components, custom components to
  improve performance, scheduler, device drivers,
  memory management routines, and other hardware
  specific code from the machine description.