Transcript System Level Design: Orthogonalization of Concerns and

System Level Design:
Orthogonalization of
Concerns and PlatformBased Design
K. Keutzer, S. Malik, R. Newton, J. Rabaey,
and A. Sangiovanni-Vincentelli
Presented By: David Nguyen
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
How to Make Money?
TotalCost = #Units*ManufacturingCosts +
NRE.
Income = #Units * Cost/Unit
Success is Income > TotalCost by
balancing




# Units Produced/Sold
Manufacturing Costs per Unit
Non-Recurring Engineering Costs
Price we sell at
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).
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
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.
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)
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
Mapping
The functions of the system are assigned
(mapped) to the components of the microarchitecture.
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.
Link to Implementation
Once the mapping of functions to microarchitecture 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.
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
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.
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 reused 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.
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 microarchitectures implements
the APIs with varying costs
and performance
Tradeoff between level of
abstraction and the
diversity of the platform
instances.
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)
November 5, 2002
David Nguyen
15
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.
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.
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.
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.
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.
Programmer’s Model
The goal of MESCAL
Programmer’s 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.
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.
November 5, 2002
David Nguyen
22