Challenges

1
Challenges

• Shift to
• Reuse Strategy
• Higher Level of Abstractions
• Software !!!

2
PERCENT OF TRANSISTORS WITHIN EMBEDDED IP
(EXCLUDES MEMORY)
3
TRENDS IN EMBEDDED IP
DESIGNS WITH EMBEDDED IP WILL DOMINATE THE SYSTEM
IC BUSINESS IN THE FUTURE
4
Intra- and Inter-Company World Wide IP Networks
System House Corporate Headquarters
Overseas Affiliate with Proprietary IP
Rapid IP Identification, Business Transaction,
Design-in
Semiconductor IP Provider
Independent IP Provider
5
Computing for Embedded Systems
Image borrowed from an Iomega advertisement for
Y2K software and disk drives, Scientific
American, September 1999.
6
Complexity, Quality, Time-to-Market TODAY
TELEMATIC UNIT
INSTRUMENT CLUSTER
PWT UNIT
BODY GATEWAY
C CODE
Source EMBEDDED SYSTEMS THE REAL STORY FABIO
ROMEO, Magnetti-Marelli Design Automation
Conference, Las Vegas, June 20th, 2001
7
The Software Development Problem

• Product Quality is POOR
• Development Productivity is LOW
• Development Cycle-time is TOO LONG

Source Roger G. Fordham Motorola, Global
Software Group DAC 2001, June 6, 2001
System Software (of size 10,000 Function Points)
Source of Industry Data Capers Jones(2000)
Software Assessments, Benchmarks, and Best
Practices, Addison-Wesley.
8

COMPLEXITY, QUALITY, TIME-TO-MARKET FUTURE
TRENDS

• KEY DRIVERS
• QUALITY
• TIME-TO-MARKET
• COMPLEXITY MGMT

• WINNING SOLUTIONS
• PLATFORM APPLICATIONS
• DESIGN METHODOLOGIES
• TESTING

9
What are the Remedies?

• Significant commitment to CONTINUOUS IMPROVEMENT
• Effective use of DESIGN METHODOLOGIES
• Effective use of development/management AUTOMATION

10
Software Architecture Today
Poor common infrastructure. Weak specialization
of functions. Poor resource management. Poor
planning.
11
Software Architecture Tomorrow?
12
The C or Java Paradigm

• Not abstract enough to capture functionality only
• Not detailed enough to capture important
  parameters such as performance, energy
  consumption, size
• What about real time?

13
Problems with Past Design Method

• Lack of unified hardware-software representation
• Partitions are defined a priori
• Can't verify the entire system
• Hard to find incompatibilities across HW-SW
  boundary
• (often found only when prototype is built)
• Lack of well-defined design flow
• Time-to-market problems
• Specification revision becomes difficult

14
Design Effort vs. System Design Value
Function HW/SW Architecture RTL -
SW Mask - ASM
Level of Abstraction
Effort/Value
15
Design Effort vs. System Design Value
Function HW/SW Architecture RTL -
SW Mask - ASM
Level of Abstraction
Effort/Value
16
New Levels of Design Chain Interaction
Function HW/SW Architecture RTL -
SW Mask - ASM
Level of Abstraction
Effort/Value
17
System Level Design Science

• Design Methodology
• Top Down Aspect
• Orthogonalization of Concerns
• Separate Implementation from Conceptual Aspects
• Separate computation from communication
• Formalization precise unambiguous semantics
• Abstraction capture the desired system details
  (do not overspecify)
• Decomposition partitioning the system behavior
  into simpler behaviors
• Successive Refinements refine the abstraction
  level down to the implementation by filling in
  details and passing constraints
• Bottom Up Aspect
• IP Re-use (even at the algorithmic and functional
  level)
• Components of architecture from pre-existing
  library

18
High-Leverage Paradigms

• If we face a problem that has become too complex
  to solve, eliminate the problem!
• Decompose
• Approximate
• Solve by construction

19
Separate Behavior from Micro-architecture

• Implementation Architecture
• Hardware and Software
• Optimized Computer

• System Behavior
• Functional Specification of System.
• No notion of hardware or software!

20
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
We are searching for an abstraction that provides
the Source for all MoCs that can be obtained by
refinement
21
Formalization

• Model of a design with precise unambiguous
  semantics
• Implicit or explicit relations inputs, outputs
  and (possibly) state variables
• Properties
• Cost functions
• Constraints

Formalization of Design Environment closed
system of equations and inequalities over some
algebra.
22
Validating Designs

• By construction
• property is inherent.
• By verification
• property is provable.
• By simulation
• check behavior for all inputs.
• By intuition
• property is true. I just know it is.
• By assertion
• property is true. Wanna make something of it?
• By intimidation
• Dont even try to doubt whether it is true
• It is generally better to be higher in this list

23
Notion of Time
24
System Specifications
25
Two Basic Questions Question I - IP Authoring

• How to design a system block?
• Starting from the system level
• With a consistent test-bench
• Getting from the abstract, un-timed system model
  to the clocked HW or SW implementation model
• Example
• Rake Receiver
• Which are the optimal algorithms?
• How does it work fixed point?
• How is it best implemented?
• Does the implementation work as specified in the
  system level

Embedded System Requirements
Implementation Level Verification
Synthesis / Place Route etc.
26
Two Basic Questions Question II IP
Integration

• How to integrate system blocks?
• Starting from the system level
• With a consistent test-bench
• Getting from the abstract, un-timed system model
  to the clocked HW or SW implementation model
• Communication between blocks
• Addressing Platform Based design
• Example
• 3G Cell phone
• Which are the optimal algorithms?
• Do they work together functionally?
• Is the architecture sufficient?
• Does the implementation integration work?

Embedded System Requirements
System Integration
Hardware Assembly
Implementation Level Verification
Synthesis / Place Route etc.
27
The new approach

• Not the typical stepwise top-down refinement we
  rest on platforms!
• Explicit mapping of applications onto
  architecture components
• The higher the level of abstraction, the faster
  is the design time

28
Ptolemy

• E. Lee Project at UC Berkeley
• Multiple models of computation
• DSP beginnings Static Dataflow
• Many other models FSM, Discrete Event
• Mixed model verification

29
A bit of history the POLIS project

• The problem

• The target architecture

30
The Essence of the Polis/Felix/VCC Approach
31
Example of System Behavior
Mem 13
User/Sys Control 3
Rate Buffer 12
Sensor
Synch Control 4
remote
Satellite Dish
Rate Buffer 5
Video Decode 6
Frame Buffer 7
Video Output 8
Transport Decode 2
Front End 1
Rate Buffer 9
monitor
Audio Decode/ Output 10
Cable
Mem 11
speakers
32
IP-Based Design of the System Behavior
System Integration Communication
Protocol Designed in Felix
User Interface Written in C
Mem 13
Testbench Designed in BONeS
User/Sys Control 3
Rate Buffer 12
Sensor
Synch Control 4
remote
Satellite Dish
Rate Buffer 5
Video Decode 6
Frame Buffer 7
Video Output 8
Transport Decode 2
Front End 1
Rate Buffer 9
Audio Decode/ Output 10
monitor
Cable
Mem 11
Baseband Processing Designed in SPW
speakers
Transport Decode Written in C
Decoding Algorithms Designed in SPW
33
The next level of Abstraction
34
IP-Based Design of the Implementation
Which Bus? PI? AMBA? Dedicated Bus for DSP?
Which DSP Processor? C50? Can DSP be done
on Microcontroller?
Can I Buy an MPEG2 Processor? Which One?
Which Microcontroller? ARM? HC11?
How fast will my User Interface Software run?
How Much can I fit on my Microcontroller?
Do I need a dedicated Audio Decoder? Can decode
be done on Microcontroller?
35
Architectural Choices
Flexibility
1/Efficiency (power, speed)
36
Map Between Behavior from Architecture
Transport Decode Implemented as Software Task
Running on Microcontroller
37
Classic A/D, HW/SW tradeoff
Digital expanding
De-correlate (spread spectrum)
De-modulate
e.g.
Analog vs. Digital tradeoff
LO
System Chip DSP
Suppose digital limit is pushed
A/D
Custom DSP
DS 1-bit Modulator
Dec. Filter
Gen DSP
1-bit Modulator
Gen DSP
1-bit Modulator

• RF Front End
• Can trade custom analog for hardware, even for
  software
• Power, area critical criteria, or easy functional
  modification

38
Example Voice Mail Pager
Modulation Scheme Choice (e.g. BPSK)
?
De-correlate (spread spectrum)
De-modulate
Gen DSP
?
e.g.
Analog vs. Digital tradeoff

• Design considerations cross design layers
• Trade-offs require systematic methodology and
  constraint-based hierarchical approach for clear
  justification

39
Where All is Going
Communication-based Design
Analog Platform Design

• Create paradigm shift- not just link methods
• New levels of abstraction to fluidly tradeoff
  HW/SW, A/D, HF/IF, interfaces, etc- to exploit
  heterogeneous nature of components
• Links already being forged

40
Concluding Remarks

• The Industry Structure is undergoing a
  revolutionary change
• The Design Problems are changing radically their
  main characteristics
• System Design is becoming more and more the key
  to success
• System implies Major Emphasis on Software
• Analog, Sensors, Actuators, RF must be part of
  design
• Deep Submicron makes most of the tools obsolete