Embedded Systems Introduction

1
Embedded SystemsIntroduction
L1
July08
2

• References
• Embedded Systems Design, Steve Heath, Elsevier
• Embedded Systems Design, Frank Vahid Tony
  Givargis, John wiley
• Fundamentals of embedded software, Daniel W
  lewis, Pearson education
• Embedded Microcomputer Systems, Jonathan W
  Valavano, Brooks/cole, Thomson Learning
• Embedded Systems Design, Oliver Bailey, Dreamtech
• Embedded Real-time Systems, K V K K Prasad,
  Dreamtech

3
Outline

• Embedded systems overview
• What are they?
• Design challenge optimizing design metrics
• Technologies
• Processor technologies
• IC technologies
• Design technologies

4
Embedded systems overview

• When we talk of microprocessors we think of
  computers as they are everywhere
• Computers often mean
• Desktop PCs
• Laptops
• Mainframes
• Servers
• But theres yet another type of computing system
• Far more common...

5
Embedded systems overview
Computers/ microprocessors are in here...

• Embedded computing systems
• (Micro)processors are embedded within electronic
  devices, equipment, appliances
• Hard to define - any computing system other than
  a desktop computer
• Billions of units produced yearly, versus
  millions of desktop units
• Perhaps 50 per household and per automobile

Toys, mobile phones, kitchen appliances, even
pens ?
Many times more processors used in each of them
, though they cost much less
These processors make these devices
sophisticated, versatile and inexpensive
6
A short list of embedded systems
Modems MPEG decoders Network cards Network
switches/routers On-board navigation Pagers Photoc
opiers Point-of-sale systems Portable video
games Printers Satellite phones Scanners Smart
ovens/dishwashers Speech recognizers Stereo
systems Teleconferencing systems Televisions Tempe
rature controllers Theft tracking systems TV
set-top boxes VCRs, DVD players Video game
consoles Video phones Washers and dryers
Anti-lock brakes Auto-focus cameras Automatic
teller machines Automatic toll systems Automatic
transmission Avionic systems Battery
chargers Camcorders Cell phones Cell-phone base
stations Cordless phones Cruise control Curbside
check-in systems Digital cameras Disk
drives Electronic card readers Electronic
instruments Electronic toys/games Factory
control Fax machines Fingerprint identifiers Home
security systems Life-support systems Medical
testing systems

• And the list goes
• on and on

7
Embedded systems A microprocessor based system
that is built to control a function(s) of a
system and is designed not to be programmed by
the user. (controller) User could select the
functionality but cannot define the
functionality. Embedded system is designed to
perform one or limited number of functions, may
be with choices or options. PCs provide easily
accessible methodologies, HW SW that are used
to build Embedded systems
8
Why did they become popular? Replacement for
discrete logic-based circuits Functional
upgradability ?, easy maintenance
upgrades Improves the performance of mechanical
systems through close control Protection of
Intellectual property Replacement of Analogue
circuits (DSPs)
9
What does an Embedded system consist
of? Processor Types, technologies,
functionalities Memory how much, what types,
organisation Peripherals/ I/O interfaces
communicate with the user, external
environment Inputs and outputs / sensors
actuators Digital - binary, serial/parallel,
Analogue, Displays and alarms, Timing devices SW
OS, application SW, initialisation, self
check Algorithms
10
Path of electronic design Mechanical control
systems- expensive bulky Discrete electronic
circuits fast but no flexibility SW controlled
circuits microprocessors and controllers
slow, flexible HW implementation of SW, HW SW
systems
11
Some Common Characteristics of Embedded Systems

• Single-functioned
• Executes a single program, repeatedly
• Tightly-constrained
• Low cost, low power, small, fast, etc.
• Reactive and real-time
• Continually reacts to changes in the systems
  environment
• Must compute certain results in real-time without
  delay

12
Embedded system - digital camera

• Single-functioned -- always a digital camera
• Tightly-constrained -- Low cost, low power,
  small, fast
• Reactive and real-time -- only to a small extent

13
Design challenge optimizing design metrics

• Obvious design goal
• Construct an implementation with desired
  functionality
• Key design challenge
• Simultaneously optimize numerous design metrics
• Design metric
• A measurable feature of a systems
  implementation
• Optimizing design metrics is a key challenge

14
Design challenge optimizing design metrics

• Common metrics
• Unit cost the monetary cost of manufacturing
  each copy of the system, excluding NRE cost
• NRE cost (Non-Recurring Engineering cost) The
  one-time monetary cost of designing the system
• Size the physical space required by the system
• Performance the execution time or throughput of
  the system
• Power amount of power consumed by the system
• Flexibility the ability to change the
  functionality of the system without incurring
  heavy NRE cost

15
Design challenge optimizing design metrics

• Common metrics (continued)
• Time-to-prototype the time needed to build a
  working version of the system
• Time-to-market the time required to develop a
  system to the point that it can be released and
  sold to customers
• Maintainability the ability to modify the system
  after its initial release
• Correctness, safety, many more

16
Design metric competition -- improving one may
worsen others

• Expertise with both software and hardware is
  needed to optimize design metrics
• A designer must be comfortable with various
  technologies in order to choose the best for a
  given application and constraints

Power
Performance
Size
NRE cost
Hardware
Software
17
Time-to-market a demanding design metric

• Time required to develop a product to the point
  it can be sold to customers
• Market window
• Period during which the product would have
  highest sales
• Average time-to-market constraint is about 8
  months
• Delays can be costly

Revenue
Time (months)
18
Losses Due to Delayed Market Entry

• Simplified revenue model
• Product life 2W, peak at W
• Time of market entry defines a triangle,
  representing market penetration
• Triangle area equals revenue
• Loss
• The difference between the on-time and delayed
  triangle areas

19
Losses due to delayed market entry (cont.)

• Area 1/2 base height
• On-time 1/2 2W W
• Delayed 1/2 (W-DW)(W-D)
• Percentage revenue loss
• (D(3W-D)/2W2)100
• Try some examples

• Lifetime 2W52 wks, delay D4 wks
• (4(326 4)/2262) 22
• Lifetime 2W52 wks, delay D10 wks
• (10(326 10)/2262) 50
• Delays are costly!

20
NRE and Unit Cost Metrics

• Costs
• Unit cost the monetary cost of manufacturing
  each copy of the system, excluding NRE cost
• NRE cost (Non-Recurring Engineering cost) The
  one-time monetary cost of designing the system
• total cost NRE cost unit cost of
  units
• per-product cost total cost / of units
  
• (NRE cost / of units) unit cost

21
NRE and Unit Cost Metrics

• Example
• NRE Rs 20000, unit Rs100
• For 100 units
• total cost 20000 100100 30000
• per-product cost 30,000/100 or 20000/100 100
  300

Amortizing NRE cost over the units results in an
additional Rs 200 per unit
22
NRE and unit cost metrics

• Compare technologies by costs -- best depends on
  quantity !
• Technology A NRERs 5,000, unitRs 100
• Technology B NRERs 1,00,000, unitRs 25
• Technology C NRERs10,00,000, unit Rs 2

23
The performance design metric

• Widely-used measure of system, widely-abused
• Clock freq, instructions per second not good
  measures
• Digital camera example a user cares about how
  fast it processes images, not clock speed or
  instructions per second
• Latency (response time)
• Time between task start and end
• e.g., Cameras A and B process images in 0.25
  0.3 seconds

24
The performance design metric

• Throughput
• Tasks per second, e.g. Camera A processes 4
  images B say 8 images per second
• Throughput can be more than latency seems to
  imply due to concurrency, (by capturing a new
  image while previous image is being stored).
• Speedup of B over S Bs performance / As
  performance
• Throughput speedup 8/4 2

25
Three key embedded system technologies

• Technology
• A manner of accomplishing a task, especially
  using technical processes, methods, or knowledge
• Three key technologies for embedded systems
• Processor technology
• IC technology
• Design technology

26
Processor Technology
General purpose Processor
Application specific Processor
Single purpose Processor
Microprocessors microcontrollers Programming
Specific processor
ASIP F P processor router
27
Processor technology

• Processors vary in their customization for the
  problem at hand

total 0 for i 1 to N loop total
Mi end loop
Desired functionality

General-purpose processor
Single-purpose processor
Application-specific processor
28
Processor technology

• The architecture of the computation engine used
  to implement a systems desired functionality
• Processor does not have to be programmable
• Processor not equal to general-purpose
  processor

Datapath
Controller
Controller
Datapath
Controller
Datapath
Control logic
index
Registers
Control logic and State register
Control logic and State register
Register file
total
Custom ALU
State register

General ALU
IR
PC
IR
PC
Data memory
Data memory
Program memory
Program memory
Data memory
Assembly code for total 0 for i 1 to
Assembly code for total 0 for i 1 to
Single-purpose (hardware)
Application -specific
General-purpose (software)
29
General-purpose processors

• Programmable device used in a variety of
  applications
• Also known as microprocessor
• Features
• Program memory
• General datapath with large register set and
  general ALU
• User benefits
• Low time-to-market and NRE costs
• High flexibility
• Pentium the most well-known, but there are
  hundreds of others

30
Single-purpose processors

• Digital circuit designed to execute exactly one
  program
• Ex. coprocessor, accelerator
• Features
• Contains only the components needed to execute a
  single program
• No program memory
• Benefits
• Fast
• Low power
• Small size

31
Application-specific Instruction set Processors

• Programmable processor optimized for a particular
  class of applications having common
  characteristics
• Compromise between general-purpose and
  single-purpose processors
• Features
• Program memory
• Optimized datapath
• Special functional units
• Benefits
• Some flexibility, good performance, size and power

32
IC technology

• The manner in which a digital (gate-level)
  implementation is mapped onto an IC
• IC Integrated circuit, or chip
• IC technologies differ in their customization to
  a design
• ICs consist of numerous layers (perhaps 10 or
  more)
• IC technologies differ with respect to who builds
  each layer when

gate
oxide
IC package
IC
drain
channel
source
Silicon substrate
33
IC technology Building ICs We can conceptualise
ICs as being built in layers as under Build CMOS
transistors Lowest substrate doped regions
with appropriate leads form CMOS transistors
Build Gates - We can interconnect the
transistors to make say universal NAND gate Build
R T elements - We use NAND gates to create
elements like decoders, multiplexers, ALUs,
Registers, counters etc. These are called RT
elements Build systems Select appropriate RT
elements (get ready made or design your own) and
interconnect to build the system
34
Problem decomposition- Design
Build or construct
Systems
RT elements
Gates
CMOS Transistors
35
Concept of IPs or cores We could build a CMOS
transistor in a number of ways we can change
doping levels, doping materials, doping areas and
depths and connectors used. Each combination
produces a transistor with different
characteristics input and output impedances,
gain, freq response, etc. Different firms or
persons own these transistor designs. Similarly
we could build gates using any of the above
transistors and again we have many ways of
building gates. Again these gates are owned by
different firms or persons. The above arguments
are good for the RT elements.
Different firms or persons
36

• The choices for us are
• We could build all components from CMOS
  transistors to systems by ourselves. Time
  consuming
• We take ready made transistor design from some
  one (basically in the form of mask) and build
  gates and upwards. It is faster than 1 above.
  Cost?
• We use the gates designed by some one and build
  RT elements systems . It is faster than 2
  above. Cost?
• We could use RT elements of others, including
  processors to build systems or bigger RT
  elements. It is faster than 3 above.

The reusable components at all levels are CORES
/IPs and could be incorporated into your designs
37
IC Technology
Full-custom/ VLSI
Semi-custom ASIC
PLD (Programmable Logic Device, FPGA)

Build every thing
Build part only
Build only top layer
38
IC technology

• Three types of IC technologies
• Full-custom/VLSI
• Semi-custom ASIC (gate array and standard cell)
• PLD (Programmable Logic Device)

39
Full-custom/VLSI

• All layers are optimized for an embedded systems
  particular digital implementation
• Placing transistors
• Sizing transistors
• Routing wires
• Benefits
• Excellent performance, small size, low power
• Drawbacks
• High NRE cost (e.g., Rs 2 M), long time-to-market

40
Semi-custom

• Lower layers are fully or partially built
• Designers are left with routing of wires and
  maybe placing some blocks
• Benefits
• Good performance, good size, less NRE cost than a
  full-custom implementation (perhaps 10k to
  100k)
• Drawbacks
• Still require weeks to months to develop

41
PLD (Programmable Logic Device)

• All layers already exist
• Designers can purchase an IC
• Connections on the IC are either created or
  destroyed to implement desired functionality
• Field-Programmable Gate Array (FPGA) very popular
• Benefits
• Low NRE costs, almost instant IC availability
• Drawbacks
• Bigger, expensive (perhaps Rs 2000 per unit),
  power hungry, slower

42
Moores law

• The most important trend in embedded systems
• Predicted in 1965 by Intel co-founder Gordon
  Moore
• IC transistor capacity has doubled roughly every
  18 months for the past several decades

10,000
Logic transistors per chip (in millions)
1,000
100
10
1
0.1
Note logarithmic scale
0.01
0.001
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
2003
2005
2007
2009
43
Moores law

• This growth rate is hard to imagine, most people
  underestimate

44
Graphical illustration of Moores law
1981
1984
1987
1990
1993
1996
1999
2002
10,000 transistors
150,000,000 transistors
Leading edge chip in 1981
Leading edge chip in 2002

• Something that doubles frequently grows more
  quickly than most people realize!
• A 2002 chip can hold about 15,000 1981 chips
  inside itself

45
Design of Embedded Systems (Wescon 1975)

• ... avoid data processing aides such as
  assemblers, high-level languages, simulated
  systems, and control panels. These computer-aided
  design tools generally get in the way of
  cost-effective design and are more a result of
  the cultural influence of data processing, rather
  than a practical need.
• bulk of real-world control problems require less
  than 2,000 instructions to implement. For this
  size of program computer aided design does little
  to improve the design approach and does a lot to
  separate the design engineer from intimate
  knowledge of his hardware.

46

• But the complexity of applications and the
  Embedded systems is increasing
• ICs of much larger size, complexity, complex
  functionality are desired. gt 100, 000 lines of
  code
• We have four different problems in the design and
  implementation of Embedded systems
• Visualise the system and write the
  specifications
• Breakdown the system and analyse it topdown
  process functional behaviour design
  technology
• Design the processors processor technology
• Build the processors IC technology

47
Design productivity gap

• While designer productivity has grown at an
  impressive rate over the past decades, the rate
  of improvement has not kept pace with chip
  capacity

10,000
100,000
1,000
10,000
Logic transistors per chip (in millions)
100
1000
Gap
Productivity (K) Trans./Staff-Mo.
10
100
IC capacity
1
10
0.1
1
productivity
0.01
0.1
0.001
0.01
2007
2009
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
2003
2005
48
So we need to use design technology which would
help us to bridge the productivity gap Digital
Design methodology has changed drastically in the
past 5 years
49
Design needs Design technology Achieving the
metrics fast reliably Enhanced productivity
Design single stage Multi stage - several
abstraction levels
50
Design Technology

• The manner in which we convert our concept of
  desired system functionality into an
  implementation

Compilation/ Synthesis
Libraries/ IP
Test/ Verification
Compilation/Synthesis Automates exploration and
insertion of implementation details for lower
level.
System specification
System synthesis
Hw/Sw/ OS
Model simulat./ checkers
Hw-Sw cosimulators
Behavioral specification
Libraries/IP Incorporates pre-designed
implementation from lower abstraction level into
higher level.
Cores
Behavior synthesis
RT components
HDL simulators
RT specification
RT synthesis
Test/Verification Ensures correct functionality
at each level, thus reducing costly iterations
between levels.
Gate simulators
Logic specification
Gates/ Cells
Logic synthesis
To final implementation
51
Compilation and synthesis Specify in abstract
manner and get lower level details Libraries and
IP - reusability Are ICs a form of libraries?
How do cores differ from ICs Test / verification
Simulation HDL based simulations
52
Process of FPGA fabrication Visualise a system
Write behavioural specifications of the system
(model of the system) HDL like Verilog,
schematic, FSM etc Synthesize the system (lower
level components and their connections also
called netlist) Simulate for functional and
timing validation Generate test data (test
bench) Make FPGA Test the functioning of the
system using test bench
53
Functionality perspective
Multiple perspectives for visualisation of a
system
Environmental
System
User I/F or Operator perspective
Performance
Architectural perspective
Physical
54
Systematic Design of Embedded Systems

• Most embedded systems are far too complex for
  Adhoc/empirical approach to design(100,000 lines)
  
• Methodical, engineering-oriented, tool-based
  approach is essential
• specification, synthesis, optimization,
  verification etc.
• prevalent for hardware, still rare for software
• One key aspect is the creation of models
• Representation of knowledge and ideas about the
  system being developed - specification
• Models only represent certain properties to be
  analyzed, understood verified. They omit or
  modify certain details (abstraction) based on
  certain assumptions. One of the few tools
  available for dealing with complexity

55
Abstractions and Models

• Models are foundations of science and engineering
• Designs usually start with informal
  specifications
• However, soon a need for Models and Abstractions
  is established
• Models or abstractions have connections to
  Implementation (h/w, s/w) and Application
• Two types of modeling System structure system
  behavior
• The relationships, behavior and interaction of
  atomic components
• Coordinate computation of communication between
  components
• Models from classical CS
• FSM, RAM (von Neumann), CCS (Milner)
• Turing machine, Universal Register Machine

56
Models Conceptual model Physical model Analogue
model Mathematical model Numerical
model Computational model Implementation Assumptio
ns accuracy
57
Good Models

• Simple
• Ptolemy vs. Galileo
• Amenable for development of theory to reason
• should not be too general
• Has High Expressive Power
• a game is interesting only if it has some level
  of difficulty!
• Provides Ability for Critical Reasoning
• Science vs. Religion
• Practice is currently THE only serious test of
  model quality
• Executable (for Simulation)
• Synthesizable
• Unbiased towards any specific implementation (h/w
  or s/w)

58
Modeling Embedded Systems

• Functional behavior what does the system do
• in non-embedded systems, this is sufficient
• Contract with the physical world
• Time meet temporal contract with the environment
• temporal behavior important in real-time systems,
  as most embedded systems are
• simple metric such as throughput, latency, jitter
• more sophisticated quality-of-service metrics
• Power meet constraint on power consumption
• peak power, average power, system lifetime
• Others size, weight, heat, temperature,
  reliability etc
• System model must support description of both
• functional behavior and physical interaction

59
Elements of a Model of a Computation System
Language

• Set of symbols with superimposed syntax
  semantics
• textual (e.g. matlab), visual (e.g. labview) etc.
• Syntax rules for combining symbols
• well structured, intuitive
• Semantics rules for assigning meaning to symbols
  and combinations of symbols
• without rigorous semantics, precise model
  behavior over time is not well defined
• full executability and automatic h/w or s/w
  synthesis is impossible
• E.g. operational semantics (in terms of actions
  of an abstract machine), denotational semantics
  (in terms of relations)

60
Simulation and Synthesis

• Two sides of the same coin
• Simulation scheduling then execution on desktop
  computer(s)
• Synthesis scheduling then code generation in
  C, C, assembly, VHDL, etc.
• Validation by simulation important throughout
  design flow
• Models of computation enable
• Global optimization of computation and
  communication
• Scheduling and communication that is correct by
  construction

61
Models Useful In 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. Would 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 !

62
An embedded system is expected to receive inputs,
process data or information, and provide
outputs The processing is done by
processors Before we build the processor we must
know the expected behaviour of the
processor This is the model of the processor. We
may call it a computational model. Before the
processor is built it is in our mind. We
express this model through a description - text,
graphics, or some formal language
63
Models Languages Models exist without
language Models are expressed in some language or
the other A model could be expressed in
different languages A language could express more
than one model Some languages are better suited
to express some models
64
Types of models many include Sequential
model A model that represents the embedded
system as a sequence of actions. A variety of
systems need this sequence of steps. Most
programming languages and natural languages can
express this feature Communicating-process model
A number of independent processes (may be
sequential) communicate among themselves whilst
doing their job. Synchronisation/signalling,
passing data, mutual exclusion etc. Some
languages are better suited.
65
State machine model A model where the embedded
system resides in a state till an input to the
system/event makes it change its state. Most
reactive and control system applications fall
under this category. FSM representations are good
way expressing the model. Text Vs Graphic
languages Data flow model An embedded system
that functions mainly by transforming an input
data stream into an output data stream
functioning of an mpeg camera UML may be more
useful. Most DSP applications
66
OO models Well known Useful for successive
decomposition problems, problems where OO
paradigm is useful etc. Multiple models and
multiple languages may be needed to describe a
complex system. The model description must be
accompanied by semantic descriptions for proper
processing
67
Lift model - English language description Lift
cage contains a number of controls floor
numbers, open and close door, it receives the
data regarding the floor it is at. Users press
the floor number to which they desire to go and
depending upon the current location and the floor
it has to go it moves up and down. Before it
moves, the door is closed. On reaching the floor
it keeps the door open for 15 sec, unless close
door operation is executed before door closes.
When stationary, door is kept closed. When moving
in a direction it does not return to opposite
direction, even on request, unless no request for
higher or lower floor in the same direction is
pending
68

• Problems
• Develop a model for the lift controller
• Identify one problem each that fits into the
  models discussed above.
• Develop a model for a data acquisition system
  that receives data from 14 channels through A/D
  converters and takes appropriate control actions
  as a function of the 14 inputs and communicates
  with 4 actuators. Inputs from channel 15 or 16
  need immediate response, and the controller must
  respond in a time of about 20 clock cycles. In
  these cases, actuator 5 is activated.

69
Modeling Approaches based on Software Design
Methods

• No systematic design in 60s
• From 70s, many different s/w design strategies
• Design methods based on functional decomposition
• Real-Time Structured Analysis and Design(RTSAD)
• Design methods based on concurrent task
  structuring
• Design Approach for Real-Time Systems (DARTS)
• Design methods based on information hiding
• Object-Oriented Design method (OOD)
• Design methods based on modeling the domain
• Jackson System Development method (JSD)
• Object-Oriented Design method (OOD)

70
continued

• UML is the latest manifestation
• becoming prevalent in complex embedded system
  design

71
How Models Influence an Application Design?

• Example given input from a camera, digitally
  encode it using MPEG II encoding standards.
• this task involves storing the image for
  processing going through a number of processing
  steps, e.g., Discrete cosine transform (DCT),
  Quantization, encoding (variable length
  encoding), formatting the bit stream, Inverse
  Discrete Cosine transform (IDCT), ...
• Is this problem appropriate for
• Reactive Systems, Synchronous Data flow, CSP, ...
• More than one model could be appropriate.

72
Choice of Model

• Model Choice depends on
• application domain
• DSP applications use data flow models
• Control applications use finite state machine
  models
• Event driven applications use reactive models
• efficiency of the model
• in terms of simulation time
• in terms of synthesized circuit/code.
• Language Choice depends on
• underlying semantics
• semantics in the model appropriate for the
  application.
• available tools
• personal taste and/or company policy

73
Design productivity exponential increase
100,000
10,000
1,000
Productivity (K) Trans./Staff Mo.
100
10
1
0.1
0.01
1981
2009
1995
1997
2007
1983
1987
1989
1991
1993
1999
2001
2003
1985
2005

• Exponential increase over the past few decades

74
The co-design ladder
Sequential program code (e.g., C, VHDL)

• In the past
• Hardware and software design technologies were
  very different
• Recent maturation of synthesis enables a unified
  view of hardware and software
• Hardware/software codesign

Behavioral synthesis (1990's)
Compilers (1960's,1970's)
Register transfers
Assembly instructions
RT synthesis (1980's, 1990's)
Assemblers, linkers (1950's, 1960's)
Logic equations / FSM's
Logic synthesis (1970's, 1980's)
Machine instructions
Logic gates
Implementation
VLSI, ASIC, or PLD implementation hardware
Microprocessor plus program bits software
The choice of hardware versus software for a
particular function is simply a tradeoff among
various design metrics, like performance, power,
size, NRE cost, and especially flexibility there
is no fundamental difference between what
hardware or software can implement.
75
Independence of Processor and IC Technologies

• Basic tradeoff
• General vs. custom
• With respect to processor technology or IC
  technology
• The two technologies are independent

Customized, providing improved
General-purpose processor
ASIP
Single- purpose processor
General, providing improved
Power efficiency Performance Size Cost (high
volume)
Flexibility Maintainability NRE cost Time-
to-prototype Time-to-market Cost (low volume)
Semi-custom
PLD
Full-custom
76
Design productivity gap

• While designer productivity has grown at an
  impressive rate over the past decades, the rate
  of improvement has not kept pace with chip
  capacity

10,000
100,000
1,000
10,000
100
1000
Logic transistors per chip (in millions)
Gap
Productivity (K) Trans./Staff-Mo.
10
100
IC capacity
1
10
0.1
1
productivity
0.01
0.1
0.001
0.01
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
2003
2005
2007
2009
77
Design productivity gap

• 1981 leading edge chip required 100 designer
  months
• 10,000 transistors / 100 transistors/month
• 2002 leading edge chip requires 30,000 designer
  months
• 150,000,000 / 5000 transistors/month
• Designer cost increase from 1M to 300M

78
The mythical man-month

• The situation is even worse than the productivity
  gap indicates
• In theory, adding designers to team reduces
  project completion time
• In reality, productivity per designer decreases
  due to complexities of team management and
  communication
• In the software community, known as the mythical
  man-month (Brooks 1975)
• At some point, can actually lengthen project
  completion time! (Too many cooks)

Team
15

• 1M transistors, 1 designer5000
  trans/month
• Each additional designer reduces for 100
  trans/month
• So 2 designers produce 4900 trans/month each

60000
16
16
18
50000
19
40000
23
24
30000
Months until completion
20000
43
Individual
10000
10
20
30
40
0
Number of designers
79
Summary

• Embedded systems are everywhere
• Key challenge optimization of design metrics
• Design metrics compete with one another
• A unified view of hardware and software is
  necessary to improve productivity
• Three key technologies
• Processor general-purpose, application-specific,
  single-purpose
• IC Full-custom, semi-custom, PLD
• Design Compilation/synthesis, libraries/IP,
  test/verification