406997673-Computers-as-Components-2nd-Edi-Wayne-Wolf.pptx

Introduction
• What are embedded computing systems?
• Challenges in embedded computing
system design.
• Design methodologies.
Overheads for Computers as
Components, 2nd ed.
© 2008 Wayne Wolf 1

Components, 2nd ed.
Definition
• Embedded computing system: any device
that includes a programmable computer
but is not itself a general-purpose
computer.
• A PC is not itself an embedded
computing system, although PCs are
often used to build embedded computing
systems.
• Take advantage of application
characteristics to optimize the design

Embedding a computer
CPU
mem
input
output analog
Components, 2nd ed.
analog
embedded
computer

Components, 2nd ed.
Examples
• Cell phone.
• Printer.
• Automobile: engine, brakes, dash, etc.
• Airplane: engine, flight controls,
nav/comm.
• Digital television.
• Household appliances.

Components, 2nd ed.
Early history
• Late 1940’s: MIT Whirlwind computer was
designed for real-time operations.
• Originally designed to control an aircraft
simulator.
• First microprocessor was Intel 4004 in
early 1970’s.
• HP-35 calculator used several chips to
implement a microprocessor in 1972.

Components, 2nd ed.
Early history, cont’d.
• Automobiles used microprocessor-based
engine controllers starting in 1970’s.
• Control fuel/air mixture, engine timing, etc.
• Multiple modes of operation: warm-up,
cruise, hill climbing, etc.
• Provides lower emissions, better fuel
efficiency.

Components, 2nd ed.
Microprocessor varieties
• Microcontroller: includes I/O devices, on-
board memory.
• Digital signal processor (DSP):
microprocessor optimized for digital signal
processing.
• Typical embedded word sizes: 8-bit, 16-
bit, 32-bit.

Components, 2nd ed.
Application examples
• Simple control: front panel of microwave
oven, etc.
• Canon EOS 3 has three microprocessors.
• 32-bit RISC CPU runs autofocus and eye
control systems.
• Digital TV: programmable CPUs +
hardwired logic for video/audio decode,
menus, etc.

Components, 2nd ed.
Automotive embedded systems
• Today’s high-end automobile may have
100 microprocessors:
• 4-bit microcontroller checks seat belt;
• microcontrollers run dashboard devices;
• 16/32-bit microprocessor controls engine.

Components, 2nd ed.
BMW 850i brake and stability
control system
• Anti-lock brake system (ABS): pumps
brakes to reduce skidding.
• Automatic stability control (ASC+T):
controls engine to improve stability.
• ABS and ASC+T communicate.
• ABS was introduced first---needed to
interface to existing ABS module.

BMW 850i, cont’d.
brake
sensor
brake
sensor
brake
sensor
brake
sensor
ABS
hydraulic
pump
Components, 2nd ed.

Components, 2nd ed.
Characteristics of embedded
systems
• Sophisticated functionality.
• Real-time operation.
• Low manufacturing cost.
• Low power.
• Designed to tight deadlines by small
teams.

Components, 2nd ed.
Functional complexity
• Often have to run sophisticated
algorithms or multiple algorithms.
• Cell phone, laser printer.
• Often provide sophisticated user
interfaces.

Components, 2nd ed.
Real-time operation
• Must finish operations by deadlines.
• Hard real time: missing deadline causes
failure.
• Soft real time: missing deadline results in
degraded performance.
• Many systems are multi-rate: must handle
operations at widely varying rates.

Components, 2nd ed.
Non-functional requirements
• Many embedded systems are mass-
market items that must have low
manufacturing costs.
• Limited memory, microprocessor power, etc.
• Power consumption is critical in battery-
powered devices.
• Excessive power consumption increases
system cost even in wall-powered devices.

Components, 2nd ed.
Design teams
• Often designed by a small team of
designers.
• Often must meet tight deadlines.
• 6 month market window is common.
• Can’t miss back-to-school window for
calculator.

Components, 2nd ed.
Why use microprocessors?
• Alternatives: field-programmable gate
arrays (FPGAs), custom logic, etc.
• Microprocessors are often very efficient:
can use same logic to perform many
different functions.
• Microprocessors simplify the design of
families of products.

Components, 2nd ed.
The performance paradox
• Microprocessors use much more logic to
implement a function than does custom
logic.
• But microprocessors are often at least as
fast:
• heavily pipelined;
• large design teams;
• aggressive VLSI technology.

Components, 2nd ed.
Power
• Custom logic uses less power, but CPUs have
advantages:
• Modern microprocessors offer features to
help control power consumption.
• Software design techniques can help reduce
power consumption.
• Heterogeneous systems: some custom logic for
well-defined functions, CPUs+software for
everything else.

Components, 2nd ed.
Platforms
• Embedded computing platform: hardware
architecture + associated software.
• Many platforms are multiprocessors.
• Examples:
• Single-chip multiprocessors for cell phone
baseband.
• Automotive network + processors.

Components, 2nd ed.
The physics of software
• Computing is a physical act.
• Software doesn’t do anything without
hardware.
• Executing software consumes energy,
requires time.
• To understand the dynamics of software
(time, energy), we need to characterize
the platform on which the software runs.

Components, 2nd ed.
What does “performance”
mean?
• In general-purpose computing,
performance often means average-case,
may not be well-defined.
• In real-time systems, performance means
meeting deadlines.
• Missing the deadline by even a little is bad.
• Finishing ahead of the deadline may not help.

Components, 2nd ed.
Characterizing performance
• We need to analyze the system at several
levels of abstraction to understand
performance:
• CPU.
• Platform.
• Program.
• Task.
• Multiprocessor.

Components, 2nd ed.
Challenges in embedded
system design
• How much hardware do we need?
• How big is the CPU? Memory?
• How do we meet our deadlines?
• Faster hardware or cleverer software?
• How do we minimize power?
• Turn off unnecessary logic? Reduce memory
accesses?

Components, 2nd ed.
Challenges, etc.
• Does it really work?
• Is the specification correct?
• Does the implementation meet the spec?
• How do we test for real-time characteristics?
• How do we test on real data?
• How do we work on the system?
• Observability, controllability?
• What is our development platform?

Components, 2nd ed.
Design methodologies
• A procedure for designing a system.
• Understanding your methodology helps
you ensure you didn’t skip anything.
• Compilers, software engineering tools,
computer-aided design (CAD) tools, etc.,
can be used to:
• help automate methodology steps;
• keep track of the methodology itself.

Components, 2nd ed.
Design goals
• Performance.
• Overall speed, deadlines.
• Functionality and user interface.
• Manufacturing cost.
• Power consumption.
• Other requirements (physical size, etc.)

Levels of abstraction
requirements
specification
architecture
component
design
system
integration
Components, 2nd ed.

Components, 2nd ed.
Top-down vs. bottom-up
• Top-down design:
• start from most abstract description;
• work to most detailed.
• Bottom-up design:
• work from small components to big system.
• Real design uses both techniques.

Components, 2nd ed.
Stepwise refinement
• At each level of abstraction, we must:
• analyze the design to determine
characteristics of the current state of the
design;
• refine the design to add detail.

Components, 2nd ed.
Requirements
• Plain language description of what the
user wants and expects to get.
• May be developed in several ways:
• talking directly to customers;
• talking to marketing representatives;
• providing prototypes to users for comment.

Components, 2nd ed.
Functional vs. non-functional
requirements
• Functional requirements:
• output as a function of input.
• Non-functional requirements:
• time required to compute output;
• size, weight, etc.;
• power consumption;
• reliability;
• etc.

Components, 2nd ed.
Our requirements form
name
purpose
inputs
outputs
functions
performance
manufacturing cost
power
physical size/weight

Example: GPS moving map
requirements
• Moving map
obtains position
from GPS, paints
map from local
database.
lat: 40 13 lon: 32 19
Components, 2nd ed.
I-78
Scotch
Road

Components, 2nd ed.
GPS moving map needs
• Functionality: For automotive use. Show major
roads and landmarks.
• User interface: At least 400 x 600 pixel screen.
Three buttons max. Pop-up menu.
• Performance: Map should scroll smoothly. No
more than 1 sec power-up. Lock onto GPS
within 15 seconds.
• Cost: $120 street price = approx. $30 cost of
goods sold.

Components, 2nd ed.
GPS moving map needs, cont’d.
• Physical size/weight: Should fit in hand.
• Power consumption: Should run for 8
hours on four AA batteries.

Components, 2nd ed.
GPS moving map
requirements form
name
purpose
inputs
outputs
functions
performance
manufacturing cost
power
GPS moving map
consumer-grade
moving map for driving
power button, two
control buttons
back-lit LCD 400 X 600
5-receiver GPS; three
resolutions; displays
current lat/lon
updates screen within
0.25 sec of movement
$100 cost-of-goods-
sold
100 mW
no more than 2: X 6:,
12 oz.

Components, 2nd ed.
Specification
• A more precise description of the system:
• should not imply a particular architecture;
• provides input to the architecture design
process.
• May include functional and non-functional
elements.
• May be executable or may be in
mathematical form for proofs.

Components, 2nd ed.
GPS specification
• Should include:
• What is received from GPS;
• map data;
• user interface;
• operations required to satisfy user requests;
• background operations needed to keep the
system running.

Components, 2nd ed.
Architecture design
• What major components go satisfying the
specification?
• Hardware components:
• CPUs, peripherals, etc.
• Software components:
• major programs and their operations.
• Must take into account functional and
non-functional specifications.

GPS moving map block diagram
GPS
receiver
search
engine
renderer
user
interface
database
display
Components, 2nd ed.

GPS moving map hardware
architecture
GPS
receiver
CPU
panel I/O
display frame
buffer
memory
Components, 2nd ed.

GPS moving map software
architecture
position database
search
renderer
timer
user
interface
pixels
Components, 2nd ed.

Components, 2nd ed.
Designing hardware and
software components
• Must spend time architecting the system
before you start coding.
• Some components are ready-made, some
can be modified from existing designs,
others must be designed from scratch.

Components, 2nd ed.
System integration
• Put together the components.
• Many bugs appear only at this stage.
• Have a plan for integrating components to
uncover bugs quickly, test as much
functionality as early as possible.

Components, 2nd ed.
Summary
• Embedded computers are all around us.
• Many systems have complex embedded
hardware and software.
• Embedded systems pose many design
challenges: design time, deadlines, power,
etc.
• Design methodologies help us manage the
design process.

Components, 2nd ed.
Introduction
• Object-oriented design.
• Unified Modeling Language (UML).

Components, 2nd ed.
System modeling
• Need languages to describe systems:
• useful across several levels of abstraction;
• understandable within and between
organizations.
• Block diagrams are a start, but don’t cover
everything.

Components, 2nd ed.
Object-oriented design
• Object-oriented (OO) design: A
generalization of object-oriented
programming.
• Object = state + methods.
• State provides each object with its own
identity.
• Methods provide an abstract interface to the
object.

Components, 2nd ed.
Objects and classes
• Class: object type.
• Class defines the object’s state elements
but state values may change over time.
• Class defines the methods used to interact
with all objects of that type.
• Each object has its own state.

Components, 2nd ed.
OO design principles
• Some objects will closely correspond to
real-world objects.
• Some objects may be useful only for
description or implementation.
• Objects provide interfaces to read/write
state, hiding the object’s implementation
from the rest of the system.

Components, 2nd ed.
UML
• Developed by Booch et al.
• Goals:
• object-oriented;
• visual;
• useful at many levels of abstraction;
• usable for all aspects of design.

UML object
d1: Display
pixels: array[] of pixels
elements
menu_items
pixels is a
2-D array
comment
object name
class name
attributes
Components, 2nd ed.

UML class
Display
pixels
elements
menu_items
mouse_click()
draw_box
operations
class name
Components, 2nd ed.

Components, 2nd ed.
The class interface
• The operations provide the abstract
interface between the class’s
implementation and other classes.
• Operations may have arguments, return
values.
• An operation can examine and/or modify
the object’s state.

Components, 2nd ed.
Choose your interface properly
• If the interface is too small/specialized:
• object is hard to use for even one application;
• even harder to reuse.
• If the interface is too large:
• class becomes too cumbersome for designers to
understand;
• implementation may be too slow;
• spec and implementation are probably buggy.

Components, 2nd ed.
Relationships between objects
and classes
• Association: objects communicate but one
does not own the other.
• Aggregation: a complex object is made of
several smaller objects.
• Composition: aggregation in which owner
does not allow access to its components.
• Generalization: define one class in terms
of another.

Class derivation
• May want to define one class in terms of
another.
• Derived class inherits attributes, operations of
base class.
Derived_class
Base_class
UML
generalization
Components, 2nd ed.

Class derivation example
Display
pixels
elements
menu_items
pixel()
set_pixel()
mouse_click()
draw_box
BW_display Color_map_display
base
class
Components, 2nd ed.
derived class

Multiple inheritance
Speaker Display
Multimedia_display
base classes
derived class
Components, 2nd ed.

Components, 2nd ed.
Links and associations
• Link: describes relationships between
objects.
• Association: describes relationship
between classes.

Link example
• Link defines the contains relationship:
message
msg = msg1
length = 1102
message
msg = msg2
length = 2114
message set
count = 2
Components, 2nd ed.

Association example
message
msg:ADPCM_stream
length : integer
message set
count : integer
0..* 1
contains
# contained messages # containing message sets
Components, 2nd ed.

Components, 2nd ed.
Stereotypes
• Stereotype: recurring combination of
elements in an object or class.
• Example:
• <<foo>>

Components, 2nd ed.
Behavioral description
• Several ways to describe behavior:
• internal view;
• external view.

State machines
a b
state
Components, 2nd ed.
state name
transition

Components, 2nd ed.
Event-driven state machines
• Behavioral descriptions are written as
event-driven state machines.
• Machine changes state when receiving an
input.
• An event may come from inside or outside
of the system.

Components, 2nd ed.
Types of events
• Signal: asynchronous event.
• Call: synchronized communication.
• Timer: activated by time.

Signal event
<<signal>>
mouse_click
leftorright: button
x, y: position
declaration
a
b
Components, 2nd ed.
mouse_click(x,y,button)
event description

Call event
c d
draw_box(10,5,3,2,blue)
Components, 2nd ed.

Timer event
e f
tm(time-value)
Components, 2nd ed.

Example state machine
region
found
got menu
item
called
menu item
found
object
object
highlighted
finish
start
mouse_click(x,y,button)/
find_region(region)
input/output
region = menu/
which_menu(i) call_menu(I)
region = drawing/
find_object(objid)
Components, 2nd ed.
highlight(objid)

Components, 2nd ed.
Sequence diagram
• Shows sequence of operations over time.
• Relates behaviors of multiple objects.

Sequence diagram example
m: Mouse d1: Display u: Menu
mouse_click(x,y,button)
which_menu(x,y,i)
time
call_menu(i)
Components, 2nd ed.

Components, 2nd ed.
Summary
• Object-oriented design helps us organize
a design.
• UML is a transportable system design
language.
• Provides structural and behavioral description
primitives.

© 2000 Morgan
Kaufman
Components 2nd ed. 76
Introduction
• Example: model train controller.

© 2000 Morgan
Kaufman
Purposes of example
• Follow a design through several levels of
abstraction.
• Gain experience with UML.

Model train setup
console
power
supply
rcvr motor
ECC command address header
© 2000 Morgan
Kaufman

© 2000 Morgan
Kaufman
Requirements
• Console can control 8 trains on 1 track.
• Throttle has at least 63 levels.
• Inertia control adjusts responsiveness
with at least 8 levels.
• Emergency stop button.
• Error detection scheme on messages.

© 2000 Morgan
Kaufman
Requirements form
name
purpose
inputs
outputs
functions
performance
model train controller
control speed of <= 8 model trains
throttle, inertia, emergency stop,
train #
train control signals
set engine speed w. inertia;
emergency stop
can update train speed at least 10
times/sec
manufacturing cost $50
power
physical
size/weight
wall powered
console comfortable for 2 hands; < 2
lbs.

© 2000 Morgan
Kaufman
Digital Command Control
• DCC created by model railroad hobbyists,
picked up by industry.
• Defines way in which model trains,
controllers communicate.
• Leaves many system design aspects open,
allowing competition.
• This is a simple example of a big trend:
• Cell phones, digital TV rely on standards.

© 2000 Morgan
Kaufman
DCC documents
• Standard S-9.1, DCC Electrical Standard.
• Defines how bits are encoded on the rails.
• Standard S-9.2, DCC Communication
Standard.
• Defines packet format and semantics.

DCC electrical standard
• Voltage moves
around the power
supply voltage; adds
no DC component.
• 1 is 58 s, 0 is at
least 100 s.
time
logic 1 logic 0
58 s
© 2000 Morgan
Kaufman
>= 100 s

© 2000 Morgan
Kaufman
DCC communication standard
• Basic packet format: PSA(sD)+E.
• P: preamble = 1111111111.
• S: packet start bit = 0.
• A: address data byte.
• s: data byte start bit.
• D: data byte (data payload).
• E: packet end bit = 1.

© 2000 Morgan
Kaufman
DCC packet types
• Baseline packet: minimum packet that
must be accepted by all DCC
implementations.
• Address data byte gives receiver address.
• Instruction data byte gives basic instruction.
• Error correction data byte gives ECC.

© 2000 Morgan
Kaufman
Conceptual specification
• Before we create a detailed specification,
we will make an initial, simplified
specification.
• Gives us practice in specification and UML.
• Good idea in general to identify potential
problems before investing too much effort in
detail.

© 2000 Morgan
Kaufman
Basic system commands
command name parameters
set-speed speed
(positive/negative)
inertia-value (non-
negative)
none
set-inertia
estop

Typical control sequence
:console :train_rcvr
set-inertia
set-speed
set-speed
estop
set-speed
© 2000 Morgan
Kaufman

Message classes
command
set-inertia
value: unsigned-
integer
set-speed
value: integer
estop
© 2000 Morgan
Kaufman

© 2000 Morgan
Kaufman
Roles of message classes
• Implemented message classes derived
from message class.
• Attributes and operations will be filled in for
detailed specification.
• Implemented message classes specify
message type by their class.
• May have to add type as parameter to data
structure in implementation.

© 2000 Morgan
Kaufman
Subsystem collaboration
diagram
Shows relationship between console and
receiver (ignores role of track):
1..n: command
:console :receiver

© 2000 Morgan
Kaufman
System structure modeling
• Some classes define non-computer
components.
• Denote by *name.
• Choose important systems at this point to
show basic relationships.

© 2000 Morgan
Kaufman
Major subsystem roles
• Console:
• read state of front panel;
• format messages;
• transmit messages.
• Train:
• receive message;
• interpret message;
• control the train.

Console system classes
1
© 2000 Morgan
Kaufman
1
1
1
console
1 1
formatter
panel
1 1
receiver*
transmitter
1 1
sender*

© 2000 Morgan
Kaufman
Console class roles
• panel: describes analog knobs and
interface hardware.
• formatter: turns knob settings into bit
streams.
• transmitter: sends data on track.

Train system classes
1
© 2000 Morgan
Kaufman
1 motor
interface
1 1
pulser*
train set
1 1..t
train
1 1
controller
1
1
receiver
1 1
detector*

© 2000 Morgan
Kaufman
Train class roles
• receiver: digitizes signal from track.
• controller: interprets received commands
and makes control decisions.
• motor interface: generates signals
required by motor.

© 2000 Morgan
Kaufman
Detailed specification
• We can now fill in the details of the
conceptual specification:
• more classes;
• behaviors.
• Sketching out the spec first helps us
understand the basic relationships in the
system.

Train speed control
• Motor controlled by pulse width
modulation:
+
V
-
duty
cycle
© 2000 Morgan
Kaufman

© 2000 Morgan
Kaufman
Console physical object
classes
knobs*
train-knob: integer
speed-knob: integer
inertia-knob: unsigned-
integer
emergency-stop: boolean
pulser*
pulse-width: unsigned-
integer
direction: boolean
sender*
send-bit()
detector*
read-bit() : integer

© 2000 Morgan
Kaufman
Panel and motor interface
classes
panel
train-number() : integer
speed() : integer
inertia() : integer
estop() : boolean
new-settings()
motor-interface
speed: integer

© 2000 Morgan
Kaufman
Class descriptions
• panel class defines the controls.
• new-settings() behavior reads the controls.
• motor-interface class defines the motor
speed held as state.

© 2000 Morgan
Kaufman
Transmitter and receiver
classes
transmitter
send-speed(adrs: integer,
speed: integer)
send-inertia(adrs: integer,
val: integer)
set-estop(adrs: integer)
receiver
current: command
new: boolean
read-cmd()
new-cmd() : boolean
rcv-type(msg-type:
command)
rcv-speed(val: integer)
rcv-inertia(val:integer)

© 2000 Morgan
Kaufman
Class descriptions
• transmitter class has one behavior for
each type of message sent.
• receiver function provides methods to:
• detect a new message;
• determine its type;
• read its parameters (estop has no
parameters).

© 2000 Morgan
Kaufman
Formatter class
formatter
current-train: integer
current-speed[ntrains]: integer
current-inertia[ntrains]:
unsigned-integer
current-estop[ntrains]: boolean
send-command()
panel-active() : boolean
operate()

© 2000 Morgan
Kaufman
Formatter class description
• Formatter class holds state for each train,
setting for current train.
• The operate() operation performs the
basic formatting task.

© 2000 Morgan
Kaufman
Control input cases
• Use a soft panel to show current panel
settings for each train.
• Changing train number:
• must change soft panel settings to reflect
current train’s speed, etc.
• Controlling throttle/inertia/estop:
• read panel, check for changes, perform
command.

Control input sequence
diagram
:knobs :panel :formatter :transmitter
inertia/estop
change
in
change
in
speed/
train
number
change in
control
settings
read panel
panel settings
panel-active
send-command
send-speed,
send-inertia.
send-estop
read panel
panel settings
change in
train
number
set-knobs
read panel
panel settings
new-settings
© 2000 Morgan
Kaufman

Formatter operate behavior
idle
update-panel()
send-command()
panel-active() new train number
other
© 2000 Morgan
Kaufman

Panel-active behavior
panel*:read-train()
current-train = train-knob
update-screen
changed = true
T
panel*:read-speed() current-speed = throttle
changed = true
T
F
...
F
...
© 2000 Morgan
Kaufman

© 2000 Morgan
Kaufman
Controller class
controller
current-train: integer
current-speed[ntrains]: integer
current-direction[ntrains]: boolean
current-inertia[ntrains]:
unsigned-integer
operate()
issue-command()

© 2000 Morgan
Kaufman
Setting the speed
• Don’t want to change speed
instantaneously.
• Controller should change speed gradually
by sending several commands.

Sequence diagram for set-
speed command
:receiver :controller :motor-interface :pulser*
new-cmd
cmd-type
rcv-speed set-speed set-pulse
set-pulse
set-pulse
set-pulse
set-pulse
© 2000 Morgan
Kaufman

Controller operate behavior
issue-command()
receive-command()
wait for a
command
from receiver
© 2000 Morgan
Kaufman

Refined command classes
command
type: 3-bits
address: 3-bits
parity: 1-bit
set-inertia
type=001
value: 3-bits
set-speed
type=010
value: 7-bits
estop
type=000
© 2000 Morgan
Kaufman

© 2000 Morgan
Kaufman
Summary
• Separate specification and programming.
• Small mistakes are easier to fix in the spec.
• Big mistakes in programming cost a lot of
time.
• You can’t completely separate
specification and architecture.
• Make a few tasteful assumptions.

Components 2nd ed.
Instruction sets
• Computer architecture taxonomy.
• Assembly language.

Components 2nd ed.
von Neumann architecture
• Memory holds data, instructions.
• Central processing unit (CPU) fetches
instructions from memory.
• Separate CPU and memory distinguishes
programmable computer.
• CPU registers help out: program counter
(PC), instruction register (IR), general-
purpose registers, etc.

CPU + memory
CPU
P
C
address
data
IR
memory
ADD r5,r1,r3
200
200
ADD r5,r1,r3
Components 2nd ed.

Harvard architecture
CPU
PC
data memory
program memory
address
data
address
Components 2nd ed.
data

Components 2nd ed.
von Neumann vs. Harvard
• Harvard can’t use self-modifying code.
• Harvard allows two simultaneous memory
fetches.
• Most DSPs use Harvard architecture for
streaming data:
• greater memory bandwidth;
• more predictable bandwidth.

Components 2nd ed.
RISC vs. CISC
• Complex instruction set computer (CISC):
• many addressing modes;
• many operations.
• Reduced instruction set computer (RISC):
• load/store;
• pipelinable instructions.

Components 2nd ed.
Instruction set characteristics
• Fixed vs. variable length.
• Addressing modes.
• Number of operands.
• Types of operands.

Components 2nd ed.
Programming model
• Programming model: registers visible to
the programmer.
• Some registers are not visible (IR).

Components 2nd ed.
Multiple implementations
• Successful architectures have several
implementations:
• varying clock speeds;
• different bus widths;
• different cache sizes;
• etc.

Components 2nd ed.
Assembly language
• One-to-one with instructions (more or
less).
• Basic features:
• One instruction per line.
• Labels provide names for addresses (usually
in first column).
• Instructions often start in later columns.
• Columns run to end of line.

Components 2nd ed.
ARM assembly language
example
label1 ADR r4,c
LDR r0,[r4] ; a comment
ADR r4,d
LDR r1,[r4]
SUB r0,r0,r1 ; comment

Components 2nd ed.
Pseudo-ops
• Some assembler directives don’t
correspond directly to instructions:
• Define current address.
• Reserve storage.
• Constants.

Components 2nd ed.
CPUs
• Input and output.
• Supervisor mode, exceptions, traps.
• Co-processors.

I/O devices
• Usually includes some non-digital
component.
• Typical digital interface to CPU:
CPU
status
reg
data
reg
mechanism
Components 2nd ed.

Components 2nd ed.
Application: 8251 UART
• Universal asynchronous receiver
transmitter (UART) : provides serial
communication.
• 8251 functions are integrated into
standard PC interface chip.
• Allows many communication parameters
to be programmed.

Serial communication
• Characters are transmitted separately:
no
char
time
bit 1 bit n-1
start bit 0
Components 2nd ed.
stop
...

Components 2nd ed.
Serial communication
parameters
• Baud (bit) rate.
• Number of bits per character.
• Parity/no parity.
• Even/odd parity.
• Length of stop bit (1, 1.5, 2 bits).

8251 CPU interface
CPU 8251
status
(8 bit)
data
(8 bit)
serial
port
Components 2nd ed.
xmit/
rcv

Components 2nd ed.
Programming I/O
• Two types of instructions can support I/O:
• special-purpose I/O instructions;
• memory-mapped load/store instructions.
• Intel x86 provides in, out instructions.
Most other CPUs use memory-mapped
I/O.
• I/O instructions do not preclude memory-
mapped I/O.

Components 2nd ed.
ARM memory-mapped I/O
• Define location for device:
DEV1 EQU 0x1000
• Read/write code:
LDR r1,#DEV1 ; set up device adrs
LDR r0,[r1] ; read DEV1
LDR r0,#8 ; set up value to write
STR r0,[r1] ; write value to device

Components 2nd ed.
Peek and poke
• Traditional HLL interfaces:
int peek(char *location) {
return *location; }
void poke(char *location, char
newval) {
(*location) = newval; }

Components 2nd ed.
Busy/wait output
• Simplest way to program device.
• Use instructions to test when device is ready.
current_char = mystring;
while (*current_char != ‘0’) {
poke(OUT_CHAR,*current_char);
while (peek(OUT_STATUS) != 0);
current_char++;
}

Components 2nd ed.
Simultaneous busy/wait input
and output
while (TRUE) {
/* read */
while (peek(IN_STATUS) == 0);
achar = (char)peek(IN_DATA);
/* write */
poke(OUT_DATA,achar);
poke(OUT_STATUS,1);
while (peek(OUT_STATUS) != 0);
}

Components 2nd ed.
Interrupt I/O
• Busy/wait is very inefficient.
• CPU can’t do other work while testing device.
• Hard to do simultaneous I/O.
• Interrupts allow a device to change the
flow of control in the CPU.
• Causes subroutine call to handle device.

Interrupt interface
CPU
status
reg
data
reg
mechanism
PC intr request
intr ack
data/address
IR
Components 2nd ed.

Components 2nd ed.
Interrupt behavior
• Based on subroutine call mechanism.
• Interrupt forces next instruction to be a
subroutine call to a predetermined
location.
• Return address is saved to resume executing
foreground program.

Components 2nd ed.
Interrupt physical interface
• CPU and device are connected by CPU
bus.
• CPU and device handshake:
• device asserts interrupt request;
• CPU asserts interrupt acknowledge when it
can handle the interrupt.

Components 2nd ed.
Example: character I/O
handlers
void input_handler() {
achar = peek(IN_DATA);
gotchar = TRUE;
poke(IN_STATUS,0);
}
void output_handler() {
}

Components 2nd ed.
Example: interrupt-driven main
program
main() {
while (TRUE) {
if (gotchar) {
poke(OUT_DATA,achar);
poke(OUT_STATUS,1);
gotchar = FALSE;
}
}
}

Example: interrupt I/O with
buffers
• Queue for characters:
a
head tail tail
Components 2nd ed.

Components 2nd ed.
Buffer-based input handler
void input_handler() {
char achar;
if (full_buffer()) error = 1;
else { achar = peek(IN_DATA);
add_char(achar); }
poke(IN_STATUS,0);
if (nchars == 1)
{ poke(OUT_DATA,remove_char();
poke(OUT_STATUS,1); }
}

I/O sequence diagram
:foreground :input :output :queue
empty
a
empty
b
bc
c
Components 2nd ed.

Components 2nd ed.
Debugging interrupt code
• What if you forget to change registers?
• Foreground program can exhibit mysterious
bugs.
• Bugs will be hard to repeat---depend on
interrupt timing.

Components 2nd ed.
Priorities and vectors
• Two mechanisms allow us to make
interrupts more specific:
• Priorities determine what interrupt gets CPU
first.
• Vectors determine what code is called for
each type of interrupt.
• Mechanisms are orthogonal: most CPUs
provide both.

Prioritized interrupts
device 1 device 2 device n
interrupt
acknowledge
L1 L2 .. Ln
CPU
Components 2nd ed.

Components 2nd ed.
Interrupt prioritization
• Masking: interrupt with priority lower than
current priority is not recognized until
pending interrupt is complete.
• Non-maskable interrupt (NMI): highest-
priority, never masked.
• Often used for power-down.

Example: Prioritized I/O
:interrupts :foreground :A :B :C
B
A,B
C
A
Components 2nd ed.

Interrupt vectors
handler 0
handler 1
handler 2
handler 3
• Allow different devices to be handled by
different code.
• Interrupt vector table:
Interrupt
vector
table head
Components 2nd ed.

Interrupt vector acquisition
:CPU :device
receive
request
receive
ack
receive
vector
Components 2nd ed.

Generic interrupt mechanism
N
intr?
Y
Assume priority selection is
handled before this
point.
N
ignore
intr priority >
current
priority?
Y
ack
Y
N
vector?
Y
Y
timeout?
bus error
Components 2nd ed.
call table[vector]
continue
execution

Components 2nd ed.
Interrupt sequence
• CPU acknowledges request.
• Device sends vector.
• CPU calls handler.
• Software processes request.
• CPU restores state to foreground
program.

Components 2nd ed.
Sources of interrupt overhead
• Handler execution time.
• Interrupt mechanism overhead.
• Register save/restore.
• Pipeline-related penalties.
• Cache-related penalties.

Components 2nd ed.
ARM interrupts
• ARM7 supports two types of interrupts:
• Fast interrupt requests (FIQs).
• Interrupt requests (IRQs).
• Interrupt table starts at location 0.

Components 2nd ed.
ARM interrupt procedure
• CPU actions:
• Save PC. Copy CPSR to SPSR.
• Force bits in CPSR to record interrupt.
• Force PC to vector.
• Handler responsibilities:
• Restore proper PC.
• Restore CPSR from SPSR.
• Clear interrupt disable flags.

Components 2nd ed.
ARM interrupt latency
• Worst-case latency to respond to interrupt
is 27 cycles:
• Two cycles to synchronize external request.
• Up to 20 cycles to complete current
instruction.
• Three cycles for data abort.
• Two cycles to enter interrupt handling state.

Components 2nd ed.
C55x interrupts
• Latency is between 7 and 13 cycles.
• Maskable interrupt sequence:
• Interrupt flag register is set.
• Interrupt enable register is checked.
• Interrupt mask register is checked.
• Interrupt flag register is cleared.
• Appropriate registers are saved.
• INTM set to 1, DBGM set to 1, EALLOW set to 0.
• Branch to ISR.
• Two styles of return: fast and slow.

Components 2nd ed.
Supervisor mode
• May want to provide protective barriers
between programs.
• Avoid memory corruption.
• Need supervisor mode to manage the
various programs.
• SHARC does not have a supervisor mode.

Components 2nd ed.
ARM supervisor mode
• Use SWI instruction to enter supervisor
mode, similar to subroutine:
SWI CODE_1
• Sets PC to 0x08.
• Argument to SWI is passed to supervisor
mode code.
• Saves CPSR in SPSR.

Components 2nd ed.
Exception
• Exception: internally detected error.
• Exceptions are synchronous with
instructions but unpredictable.
• Build exception mechanism on top of
interrupt mechanism.
• Exceptions are usually prioritized and
vectorized.

Components 2nd ed.
Trap
• Trap (software interrupt): an exception
generated by an instruction.
• Call supervisor mode.
• ARM uses SWI instruction for traps.
• SHARC offers three levels of software
interrupts.
• Called by setting bits in IRPTL register.

Components 2nd ed.
Co-processor
• Co-processor: added function unit that is
called by instruction.
• Floating-point units are often structured as
co-processors.
• ARM allows up to 16 designer-selected co-
processors.
• Floating-point co-processor uses units 1, 2.
• C55x uses co-processors as well.

Components 2nd ed.
C55x image/video hardware
extensions
• Available in 5509 and 5510.
• Equivalent C-callable functions for other
devices.
• Available extensions:
• DCT/IDCT.
• Pixel interpolation
• Motion estimation.

DCT/IDCT
• 2-D DCT/IDCT is
computed from
two 1-D
DCT/IDCT.
• Put data in
different banks to
maximize
throughput.
block
Column DCT
interim DCT
Row
DCT
Components 2nd ed.

Components 2nd ed.
C55 DCT/IDCT coprocessor
extensions
• Load, compute, transfer to accumulators:
• ACy=copr(k8,ACx,Xmem,Ymem)
• Compute, transfer, mem write:
• ACy=copr(k8,ACx,ACy), Lmem=ACz
• Special:
• ACy=copr(k8,ACx,ACy)

Software pipelined
load/compute/store for DCT
Iteration i-1 Iteration i Iteration i+1
op_i(0), load_i+1(0,1)
op_i(1), store_i-1(0,1)
op_i(2), store_i-1(2,3)
op_i(2), store_i-1(4,5)
op_i(2), store_i-1(6,7)
op_i(2), load_i+1(2,3)
…
Dual_load
4 empty
3
Dual_load
8
compute
empty
4
Long_store
© 2008 Wayne Wolf
s for C
Dual_load
4 empty
3
Dual_load
8
compute
empty
4
Long_O
sv
te
or
h
re
ea
d
Component
Dual_load
4 empty
3
Dual_load
8
compute
empty
4
o
Lm
p
ou
nt
e
gr
s
_a
s
store
s 2nd ed. 171

Components 2nd ed.
C55 motion estimation
• Search strategy:
• Full vs. non-full.
• Accuracy:
• Full-pixel vs. half-pixel.
• Number of returned motion vectors:
• 1 (one 16x16) vs. 4 (four 8x8).
• Algorithms:
• 3-step algorithm (distance 4,2,1).
• 4-step algorithm (distance 8,4,2,1).
• 4-step with half-pixel refinement.

Four-step motion estimation
breakdown
d = {8,4,2,1};
for (i=0; i<4; i++) {
compute 3 upper differences for
d[i];
compute 3 middle differences
for d[i];
compute 3 lower differences for
d[i];
compute minimum value;
move to next d;
}
X
Components 2nd ed.

Components 2nd ed.
C55 motion estimation
accelerator
• Includes 3 16-bit pixel data paths, 3 16-bit
absolute differences (ADs).
• Basic operation:
• [ACx,ACy] = copr(k8,ACx,ACy,Xmem,Ymem,Coeff)
• K8 = control bits (enable AD units, etc.)
• ACx, ACy = accumulated absolute differences
• Xmem, Ymem = pointers to odd, even lines of the
search window
• Pointer to two adjacent pixels from reference window

C55 pixel interpolation
• Given four pixels A, B, C, D, interpolate
three half-pixels:
A B
C D
U
M R
Components 2nd ed.

Components 2nd ed.
Pixel interpolation coprocessor
operations
• Load pixels and compute:
• ACy=copr(k8,AC,Lmem)
• Load pixels, compute, and store:
• ACy=copr(k8,AACx,Lmem) || Lmem=ACz

Components 2nd ed.
CPUs
• Caches.
• Memory management.

Caches and CPUs
CPU
cache
controlle
r
cache
main
memory
data
address
data
data
address
Components 2nd ed.

Components 2nd ed.
Cache operation
• Many main memory locations are mapped
onto one cache entry.
• May have caches for:
• instructions;
• data;
• data + instructions (unified).
• Memory access time is no longer
deterministic.

Components 2nd ed.
Terms
• Cache hit: required location is in cache.
• Cache miss: required location is not in
cache.
• Working set: set of locations used by
program in a time interval.

Components 2nd ed.
Types of misses
• Compulsory (cold): location has never
been accessed.
• Capacity: working set is too large.
• Conflict: multiple locations in working set
map to same cache entry.

Components 2nd ed.
Memory system performance
• h = cache hit rate.
• tcache = cache access time, tmain = main
memory access time.
• Average memory access time:
• tav = htcache + (1-h)tmain

Multiple levels of cache
CPU L1 cache L2 cache
Components 2nd ed.

Components 2nd ed.
Multi-level cache access time
• h1 = cache hit rate.
• h2 = rate for miss on L1, hit on L2.
• Average memory access time:
• tav = h1tL1 + (h2-h1)tL2 + (1- h2-h1)tmain

Components 2nd ed.
Replacement policies
• Replacement policy: strategy for choosing
which cache entry to throw out to make
room for a new memory location.
• Two popular strategies:
• Random.
• Least-recently used (LRU).

Components 2nd ed.
Cache organizations
• Fully-associative: any memory location
can be stored anywhere in the cache
(almost never implemented).
• Direct-mapped: each memory location
maps onto exactly one cache entry.
• N-way set-associative: each memory
location can go into one of n sets.

Components 2nd ed.
Cache performance benefits
• Keep frequently-accessed locations in fast
cache.
• Cache retrieves more than one word at a
time.
• Sequential accesses are faster after first
access.

Direct-mapped cache
=
tag index offset
hit value
byte
1 0xabcd byte byte byte ...
valid tag data
cac he block
Components 2nd ed.

Components 2nd ed.
Write operations
• Write-through: immediately copy write to
main memory.
• Write-back: write to main memory only
when location is removed from cache.

Components 2nd ed.
Direct-mapped cache locations
• Many locations map onto the same cache
block.
• Conflict misses are easy to generate:
• Array a[] uses locations 0, 1, 2, …
• Array b[] uses locations 1024, 1025, 1026, …
• Operation a[i] + b[i] generates conflict
misses.

Set-associative cache
• A set of direct-mapped caches:
Set 1 Set 2 Set n
...
hit
Components 2nd ed.
data

Components 2nd ed.
Example: direct-mapped vs.
set-associative
address data
000 0101
001 1111
010 0000
011 0110
100 1000
101 0001
110 1010
111 0100

Components 2nd ed.
Direct-mapped cache behavior
• After 001 access:
block tag data block tag data
00 - - 00 - -
01 0 1111 01 0 1111
10 - - 10 0 0000
11 - - 11 - -

Components 2nd ed.
Direct-mapped cache behavior,
cont’d.
00 - - 00 1 1000
01 0 1111 01 0 1111
10 0 0000 10 0 0000
11 0 0110 11 0 0110

Components 2nd ed.
Direct-mapped cache behavior,
cont’d.
00 1 1000 00 1 1000
01 1 0001 01 1 0001
10 0 0000 10 0 0000
11 0 0110 11 1 0100

Components 2nd ed.
2-way set-associtive cache
behavior
• Final state of cache (twice as big as
direct-mapped):
set blk 0 tag blk 0 data blk 1 tag blk 1 data
00 1 1000 - -
01 0 1111 1 0001
10 0 0000 - -
11 0 0110 1 0100

Components 2nd ed.
2-way set-associative cache
behavior
• Final state of cache (same size as direct-
mapped):
set blk 0 tag blk 0 data blk 1 tag blk 1 data
0 01 0000 10 1000
1 10 0111 11 0100

Components 2nd ed.
Example caches
• StrongARM:
• 16 Kbyte, 32-way, 32-byte block instruction
cache.
• 16 Kbyte, 32-way, 32-byte block data cache
(write-back).
• SHARC:
• 32-instruction, 2-way instruction cache.

Memory management units
• Memory management unit (MMU)
translates addresses:
CPU
main
memory
memory
management
unit
logical
address
Components 2nd ed.
physical
address

Components 2nd ed.
Memory management tasks
• Allows programs to move in physical
memory during execution.
• Allows virtual memory:
• memory images kept in secondary storage;
• images returned to main memory on demand
during execution.
• Page fault: request for location not
resident in memory.

Components 2nd ed.
Address translation
• Requires some sort of register/table to
allow arbitrary mappings of logical to
physical addresses.
• Two basic schemes:
• segmented;
• paged.
• Segmentation and paging can be
combined (x86).

Components 2nd ed.
Segments and pages
page 1
page 2
segment 1
memory
segment 2

Segment address translation
segment base address logical address
range
check
physical address
+
range
error
Components 2nd ed.
segment lower bound
segment upper bound

Page address translation
page offset
page offset
page i base
concatenate
Components 2nd ed.

Page table organizations
flat tree
page descriptor
page
descriptor
Components 2nd ed.

Components 2nd ed.
Caching address translations
• Large translation tables require main
memory access.
• TLB: cache for address translation.
• Typically small.

Components 2nd ed.
ARM memory management
• Memory region types:
• section: 1 Mbyte block;
• large page: 64 kbytes;
• small page: 4 kbytes.
• An address is marked as section-mapped
or page-mapped.
• Two-level translation scheme.

ARM address translation
1st index 2nd index offset
physical address
Translation table
base register
descriptor
1st level table
descriptor
2nd level table
concatenate
concatenate
Components 2nd ed.

Components 2nd ed.
CPUs
• CPU performance
• CPU power consumption.

Components 2nd ed.
Elements of CPU performance
• Cycle time.
• CPU pipeline.
• Memory system.

Components 2nd ed.
Pipelining
• Several instructions are executed
simultaneously at different stages of
completion.
• Various conditions can cause pipeline
bubbles that reduce utilization:
• branches;
• memory system delays;
• etc.

Components 2nd ed.
Performance measures
• Latency: time it takes for an instruction to
get through the pipeline.
• Throughput: number of instructions
executed per time period.
• Pipelining increases throughput without
reducing latency.

Components 2nd ed.
ARM7 pipeline
• ARM 7 has 3-stage pipe:
• fetch instruction from memory;
• decode opcode and operands;
• execute.

ARM pipeline execution
add r0,r1,#5
sub r2,r3,r6
cmp r2,#3
fetch decode execute
time
1
Components 2nd ed.
2 3

Components 2nd ed.
Pipeline stalls
• If every step cannot be completed in the
same amount of time, pipeline stalls.
• Bubbles introduced by stall increase
latency, reduce throughput.

ARM multi-cycle LDMIA
instruction
fetch decod
e
ex ld r2ex ld r3
ldmia
r0,{r2,r3}
sub
r2,r3,r6
cmp
r2,#3
fetch
time
decodeex sub
fetch decod
e
ex cmp
Components 2nd ed.

Components 2nd ed.
Control stalls
• Branches often introduce stalls (branch
penalty).
• Stall time may depend on whether branch is
taken.
• May have to squash instructions that
already started executing.
• Don’t know what to fetch until condition is
evaluated.

ARM pipelined branch
time
fetch decod
e
ex bne ex bne ex bne
bne foo
sub
r2,r3,r6
fetch decode
foo add
r0,r1,r2
fetch decod
e
ex add
Components 2nd ed.

Components 2nd ed.
Delayed branch
• To increase pipeline efficiency, delayed
branch mechanism requires n instructions
after branch always executed whether
branch is executed or not.
• SHARC supports delayed and non-delayed
branches.
• Specified by bit in branch instruction.
• 2 instruction branch delay slot.

Components 2nd ed.
Example: ARM execution time
• Determine execution time of FIR filter:
for (i=0; i<N; i++)
f = f + c[i]*x[i];
• Only branch in loop test may take more
than one cycle.
• BLT loop takes 1 cycle best case, 3 worst
case.

Components 2nd ed.
FIR filter ARM code
;
; loop initiation code
MOV r0,#0 ; use r0 for i, set to 0
MOV r8,#0 ; use a separate index for arrays
ADR r2,N
get address for N
LDR r1,[r2] ; get value of N
MOV r2,#0 ; use r2 for f, set to 0
ADR r3,c ; load r3 with address of base of c
ADR r5,x ; load r5 with address of base of x
; loop body
loop LDR r4,[r3,r8] ; get value of c[i]
LDR r6,[r5,r8] ; get value of x[i]
MUL r4,r4,r6 ; compute c[i]*x[i]
ADD r2,r2,r4 ; add into running sum
; update loop counter and array index
ADD r8,r8,#4 ; add one to array index
ADD r0,r0,#1 ; add 1 to i
; test for exit
CMP r0,r1
BLT loop
if i < N, continue loop
loopend ...
;

FIR filter performance by block
Block Variable # instructions # cycles
Initialization tinit 7 7
Body tbody 4 4
Update tupdate 2 2
Test ttest 2 [2,4]
tloop = tinit+ N(tbody + tupdate) + (N-1) ttest,worst + ttest,best
Loop test succeeds is worst case
Loop test fails is best case
Components 2nd ed.

Components 2nd ed.
C55x pipeline
• C55x has 7-stage pipe:
• fetch;
• decode;
• address: computes data/branch addresses;
• access 1: reads data;
• access 2: finishes data read;
• Read stage: puts operands on internal
busses;
• execute.

C55x organization
Instruction
unit
Program
flow
unit
Address
unit
Data
unit
3 data read busses
3 data read address busses
program address bus
program
read bus
2 data write busses
2 data write address busses
16
24
24
16
24
32
I
D
S
W
n
i
a
u
s
n
r
t
t
a
i
g
a
r
t
l
u
e
l
-
e
r
o
s
m
c
e
p
t
o
a
i
u
e
o
p
d
l
r
n
e
t
a
i
r
p
n
a
l
d
n
y
d
f
c
f
r
e
r
e
o
o
t
a
e
c
m
d
f
h
f
i
m
c
i
e
n
t
o
r
y
Components 2nd ed.
CBD,bDusbusses

Components 2nd ed.
C55x pipeline hazards
• Processor structure:
• Three computation units.
• 14 operators.
• Can perform two operations per
instruction.
• Some combinations of operators are not
legal.

Components 2nd ed.
C55x hazards
• A-unit ALU/A-unit ALU.
• A-unit swap/A-unit swap.
• D-unit ALU,shifter,MAC/D-unit ALU,shifter,MAC
• D-unit shifter/D-unit shift, store
• D-unit shift, store/D-unit shift, store
• D-unit swap/D-unit swap
• P-unit control/P-unit control

Components 2nd ed.
Memory system performance
• Caches introduce indeterminacy in
execution time.
• Depends on order of execution.
• Cache miss penalty: added time due to a
cache miss.

Components 2nd ed.
Types of cache misses
• Compulsory miss: location has not been
referenced before.
• Conflict miss: two locations are fighting
for the same block.
• Capacity miss: working set is too large.

Components 2nd ed.
CPU power consumption
• Most modern CPUs are designed with
power consumption in mind to some
degree.
• Power vs. energy:
• heat depends on power consumption;
• battery life depends on energy consumption.

Components 2nd ed.
CMOS power consumption
• Voltage drops: power consumption
proportional to V2.
• Toggling: more activity means more
power.
• Leakage: basic circuit characteristics; can
be eliminated by disconnecting power.

Components 2nd ed.
CPU power-saving strategies
• Reduce power supply voltage.
• Run at lower clock frequency.
• Disable function units with control signals
when not in use.
• Disconnect parts from power supply when
not in use.

Components 2nd ed.
C55x low power features
• Parallel execution units---longer idle shutdown
times.
• Multiple data widths:
• 16-bit ALU vs. 40-bit ALU.
• Instruction caches minimizes main memory
accesses.
• Power management:
• Function unit idle detection.
• Memory idle detection.
• User-configurable IDLE domains allow programmer
control of what hardware is shut down.

Components 2nd ed.
Power management styles
• Static power management: does not
depend on CPU activity.
• Example: user-activated power-down mode.
• Dynamic power management: based on
CPU activity.
• Example: disabling off function units.

Components 2nd ed.
Application: PowerPC 603
energy features
• Provides doze, nap, sleep modes.
• Dynamic power management features:
• Uses static logic.
• Can shut down unused execution units.
• Cache organized into subarrays to minimize
amount of active circuitry.

Components 2nd ed.
PowerPC 603 activity
• Percentage of time units are idle for SPEC
integer/floating-point:
unit Specint92 Specfp92
D cache 29% 28%
I cache 29% 17%
load/store 35% 17%
fixed-point 38% 76%
floating-point 99% 30%
system register 89% 97%

Components 2nd ed.
Power-down costs
• Going into a power-down mode costs:
• time;
• energy.
• Must determine if going into mode is
worthwhile.
• Can model CPU power states with power
state machine.

Components 2nd ed.
Application: StrongARM SA-
1100 power saving
• Processor takes two supplies:
• VDD is main 3.3V supply.
• VDDX is 1.5V.
• Three power modes:
• Run: normal operation.
• Idle: stops CPU clock, with logic still powered.
• Sleep: shuts off most of chip activity; 3 steps, each
about 30 s; wakeup takes > 10 ms.

SA-1100 power state machine
idle sleep
Prun = 400 mW
run
10 s
160 ms
90 s
10 s
90 s
Components 2nd ed.
Pidle = 50 mW Psleep = 0.16 mW

Components 2nd ed.
CPUs
• Example: data compressor.

Components 2nd ed.
Goals
• Compress data transmitted over serial
line.
• Receives byte-size input symbols.
• Produces output symbols packed into bytes.
• Will build software module only here.

Collaboration diagram for
compressor
:input :data compressor :output
1..n: input
symbols
Components 2nd ed.
1..m: packed
output
symbols

Components 2nd ed.
Huffman coding
• Early statistical text compression algorithm.
• Select non-uniform size codes.
• Use shorter codes for more common symbols.
• Use longer codes for less common symbols.
• To allow decoding, codes must have unique
prefixes.
• No code can be a prefix of a longer valid code.

Huffman example
character P
a .45
b .24
c .11
d .08
e .07
f .05
P=1
P=.55
P=.31
P=.19
P=.12
Components 2nd ed.

Components 2nd ed.
Example Huffman code
• Read code from root to leaves:
a 1
b 01
c 0000
d 0001
e 0010
f 0011

Components 2nd ed.
Huffman coder requirements
table
name
purpose
inputs
outputs
functions
performance
manufacturing cost
power
data compression module
code module for Huffman
compression
encoding table, uncoded
byte-size inputs
packed compression output
symbols
Huffman coding
fast
N/A
N/A
N/A

Components 2nd ed.
Building a specification
• Collaboration diagram shows only steady-
state input/output.
• A real system must:
• Accept an encoding table.
• Allow a system reset that flushes the
compression buffer.

Components 2nd ed.
data-compressor class
data-compressor
buffer: data-buffer
table: symbol-table
current-bit: integer
encode(): boolean,
data-buffer
flush()
new-symbol-table()

Components 2nd ed.
data-compressor behaviors
• encode: Takes one-byte input, generates
packed encoded symbols and a Boolean
indicating whether the buffer is full.
• new-symbol-table: installs new symbol
table in object, throws away old table.
• flush: returns current state of buffer,
including number of valid bits in buffer.

Components 2nd ed.
Auxiliary classes
data-buffer
databuf[databuflen] :
character
len : integer
insert()
length() : integer
symbol-table
symbols[nsymbols] :
data-buffer
len : integer
value() : symbol
load()

Components 2nd ed.
Auxiliary class roles
• data-buffer holds both packed and
unpacked symbols.
• Longest Huffman code for 8-bit inputs is 256
bits.
• symbol-table indexes encoded verison of
each symbol.
• load() puts data in a new symbol table.

Class relationships
symbol-table
data-compressor
data-buffer
1
Components 2nd ed.
1
1
1

Encode behavior
create new buffer
add to buffers
add to buffer
return true
return false
input symbol
encode
Components 2nd ed.
buffer filled?
T
F

Insert behavior
pack into
this buffer
pack bottom bits
into this buffer,
top bits into
overflow buffer
update
length
input
symbol
Components 2nd ed.
fills buffer?
T
F

Components 2nd ed.
Program design
• In an object-oriented language, we can
reflect the UML specification in the code
more directly.
• In a non-object-oriented language, we
must either:
• add code to provide object-oriented features;
• diverge from the specification structure.

Components 2nd ed.
C++ classes
Class data_buffer {
char databuf[databuflen];
int len;
int length_in_chars() { return len/bitsperbyte; }
public:
void insert(data_buffer,data_buffer&);
int length() { return len; }
int length_in_bytes() { return (int)ceil(len/8.0); }
int initialize();
...

Components 2nd ed.
C++ classes, cont’d.
class data_compressor {
data_buffer buffer;
int current_bit;
symbol_table table;
public:
boolean encode(char,data_buffer&);
void new_symbol_table(symbol_table);
int flush(data_buffer&);
data_compressor();
~data_compressor();
}

Components 2nd ed.
C code
struct data_compressor_struct {
data_buffer buffer;
int current_bit;
sym_table table;
}
typedef struct data_compressor_struct data_compressor,
*data_compressor_ptr;
boolean data_compressor_encode(data_compressor_ptr
mycmptrs, char isymbol, data_buffer *fullbuf) ...

Testing
input symbols
• Test by encoding, then decoding:
symbol table
encoder decoder
compare
result
Components 2nd ed.

Components 2nd ed.
Code inspection tests
• Look at the code for potential problems:
• Can we run past end of symbol table?
• What happens when the next symbol does
not fill the buffer? Does fill it?
• Do very long encoded symbols work
properly? Very short symbols?
• Does flush() work properly?

Components 2nd ed.
Bus-Based Computer Systems
• Busses.
• Memory devices.
• I/O devices:
• serial links
• timers and counters
• keyboards
• displays
• analog I/O

Components 2nd ed.
The CPU bus
• Bus allows CPU, memory, devices to
communicate.
• Shared communication medium.
• A bus is:
• A set of wires.
• A communications protocol.

Components 2nd ed.
Bus protocols
• Bus protocol determines how devices
communicate.
• Devices on the bus go through sequences
of states.
• Protocols are specified by state machines,
one state machine per actor in the protocol.
• May contain asynchronous logic behavior.

Four-cycle handshake
device 1 device 2
ack
device 1
enq
device 2
Components 2nd ed.
1 2 3 4
time

Components 2nd ed.
Four-cycle handshake, cont’d.
1. Device 1 raises enq.
2. Device 2 responds with ack.
3. Device 2 lowers ack once it has finished.
4. Device 1 lowers enq.

Microprocessor busses
• Clock provides
synchronization.
• R/W is true when
reading (R/W’ is false
when reading).
• Address is a-bit bundle
of address lines.
• Data is n-bit bundle of
data lines.
• Data ready signals
when n-bit data is
ready.
Components 2nd ed.

Timing diagrams
Components 2nd ed.

Bus read
Components 2nd ed.

State diagrams for bus read
CPU
device
Get
data
Done
Adrs
Wait
See
ack
Send
data
Release
ack
Adrs
Wait
Ack
start
Components 2nd ed.

Bus wait state
Components 2nd ed.

Bus burst read
Components 2nd ed.

Bus multiplexing
CPU
device
data
adrs
data enable
Components 2nd ed.
adrs
Adrs enable

DMA
• Direct memory access
(DMA) performs data
transfers without
executing
instructions.
• CPU sets up transfer.
• DMA engine fetches,
writes.
• DMA controller is a
separate unit.
Components 2nd ed.

Components 2nd ed.
Bus mastership
• By default, CPU is bus master and initiates
transfers.
• DMA must become bus master to perform
its work.
• CPU can’t use bus while DMA operates.
• Bus mastership protocol:
• Bus request.
• Bus grant.

DMA operation
• CPU sets DMA registers
for start address, length.
• DMA status register
controls the unit.
• Once DMA is bus master,
it transfers automatically.
• May run continuously until
complete.
• May use every nth bus
cycle.
Components 2nd ed.

Bus transfer sequence diagram
Components 2nd ed.

System bus configurations
• Multiple busses allow
parallelism:
• Slow devices on one
bus.
• Fast devices on
separate bus.
• A bridge connects
two busses.
CPU slow device
memory
high-speed
device
bridge
slow device
Components 2nd ed.

Bridge state diagram
Components 2nd ed.

ARM AMBA bus
• Two varieties:
• AHB is high-performance.
• APB is lower-speed, lower
cost.
• AHB supports pipelining,
burst transfers, split
transactions, multiple bus
masters.
• All devices are slaves on
APB.
Components 2nd ed.

Memory components
• Several different
types of memory:
• DRAM.
• SRAM.
• Flash.
• Each type of memory
comes in varying:
• Capacities.
• Widths.
Components 2nd ed.

Components 2nd ed.
Random-access memory
• Dynamic RAM is dense, requires refresh.
• Synchronous DRAM is dominant type.
• SDRAM uses clock to improve performance,
pipeline memory accesses.
• Static RAM is faster, less dense, consumes
more power.

SDRAM operation
Components 2nd ed.

Components 2nd ed.
Read-only memory
• ROM may be programmed at factory.
• Flash is dominant form of field-
programmable ROM.
• Electrically erasable, must be block erased.
• Random access, but write/erase is much
slower than read.
• NOR flash is more flexible.
• NAND flash is more dense.

Components 2nd ed.
Timers and counters
• Very similar:
• a timer is incremented by a periodic signal;
• a counter is incremented by an
asynchronous, occasional signal.
• Rollover causes interrupt.

Watchdog timer
• Watchdog timer is periodically reset by
system timer.
• If watchdog is not reset, it generates an
interrupt to reset the host.
host CPU
watchdog
timer
interrupt
Components 2nd ed.
reset

Switch debouncing
• A switch must be debounced to multiple
contacts caused by eliminate mechanical
bouncing:
Components 2nd ed.

Encoded keyboard
• An array of switches is read by an
encoder.
• N-key rollover remembers multiple key
depressions.
row
Components 2nd ed.

LED
• Must use resistor to limit current:
Components 2nd ed.

7-segment LCD display
• May use parallel or multiplexed input.
Components 2nd ed.

Components 2nd ed.
Types of high-resolution display
• Liquid crystal display (LCD) is dominant
form.
• Plasma, OLED, etc.
• Frame buffer holds current display
contents.
• Written by processor.
• Read by video.

Touchscreen
• Includes input and output device.
• Input device is a two-dimensional
voltmeter:
Components 2nd ed.

Touchscreen position sensing
ADC
voltage
Components 2nd ed.

Digital-to-analog conversion
• Use resistor tree:
R
Components 2nd ed.
2R
4R
8R
bn
bn-1
bn-2
bn-3
Vout

Flash A/D conversion
• N-bit result requires 2n comparators:
encoder
Vin
...
Components 2nd ed.

Dual-slope conversion
• Use counter to time required to
charge/discharge capacitor.
• Charging, then discharging eliminates
non-linearities.
Vin
Components 2nd ed.
timer

Sample-and-hold
• Samples data:
converter
Vin
Components 2nd ed.

Components 2nd ed.
• Designing with microprocessors.
• Development and debugging.
• System-level performance analysis.

Components 2nd ed.
System architectures
• Architectures and components:
• software;
• hardware.
• Some software is very hardware-
dependent.

Components 2nd ed.
Hardware platform architecture
Contains several elements:
• CPU;
• bus;
• memory;
• I/O devices: networking, sensors,
actuators, etc.
How big/fast much each one be?

Components 2nd ed.
Software architecture
Functional description must be broken into
pieces:
• division among people;
• conceptual organization;
• performance;
• testability;
• maintenance.

Components 2nd ed.
Hardware and software
architectures
Hardware and software are intimately
related:
• software doesn’t run without hardware;
• how much hardware you need is
determined by the software requirements:
• speed;
• memory.

Components 2nd ed.
Evaluation boards
• Designed by CPU manufacturer or others.
• Includes CPU, memory, some I/O devices.
• May include prototyping section.
• CPU manufacturer often gives out
evaluation board netlist---can be used as
starting point for your custom board
design.

Components 2nd ed.
Adding logic to a board
• Programmable logic devices (PLDs)
provide low/medium density logic.
• Field-programmable gate arrays (FPGAs)
provide more logic and multi-level logic.
• Application-specific integrated circuits
(ASICs) are manufactured for a single
purpose.

Components 2nd ed.
The PC as a platform
• Advantages:
• cheap and easy to get;
• rich and familiar software environment.
• Disadvantages:
• requires a lot of hardware resources;
• not well-adapted to real-time.

Typical PC hardware platform
CPU
CPU bus
memory
DMA
controller
timers
bus
interface
bus
interface
high-speed bus
low-speed bus
device
device
intr
ctrl
Components 2nd ed.

Components 2nd ed.
Typical busses
• PCI: standard for high-speed interfacing
• 33 or 66 MHz.
• PCI Express.
• USB (Universal Serial Bus), Firewire (IEEE
1394): relatively low-cost serial interface
with high speed.

Components 2nd ed.
Software elements
• IBM PC uses BIOS (Basic I/O System) to
implement low-level functions:
• boot-up;
• minimal device drivers.
• BIOS has become a generic term for the
lowest-level system software.

Components 2nd ed.
Example: StrongARM
• StrongARM system includes:
• CPU chip (3.686 MHz clock)
• system control module (32.768 kHz clock).
• Real-time clock;
• operating system timer
• general-purpose I/O;
• interrupt controller;
• power manager controller;
• reset controller.

Components 2nd ed.
Debugging embedded systems
• Challenges:
• target system may be hard to observe;
• target may be hard to control;
• may be hard to generate realistic inputs;
• setup sequence may be complex.

Host/target design
• Use a host system to prepare software for
target system:
target
system
Components 2nd ed.
serial line
host system

Components 2nd ed.
Host-based tools
• Cross compiler:
• compiles code on host for target system.
• Cross debugger:
• displays target state, allows target system to
be controlled.

Components 2nd ed.
Software debuggers
• A monitor program residing on the target
provides basic debugger functions.
• Debugger should have a minimal footprint
in memory.
• User program must be careful not to
destroy debugger program, but , should
be able to recover from some damage
caused by user code.

Components 2nd ed.
Breakpoints
• A breakpoint allows the user to stop
execution, examine system state, and
change state.
• Replace the breakpointed instruction with
a subroutine call to the monitor program.

ARM breakpoints
Components 2nd ed.
0x400 MUL r4,r6,r6
0x404 ADD r2,r2,r4
0x408 ADD r0,r0,#1
0x40c B loop
uninstrumented code
0x400 MUL r4,r6,r6
0x404 ADD r2,r2,r4
0x408 ADD r0,r0,#1
0x40c BL bkpoint
code with breakpoint

Components 2nd ed.
Breakpoint handler actions
• Save registers.
• Allow user to examine machine.
• Before returning, restore system state.
• Safest way to execute the instruction is to
replace it and execute in place.
• Put another breakpoint after the replaced
breakpoint to allow restoring the original
breakpoint.

Components 2nd ed.
In-circuit emulators
• A microprocessor in-circuit emulator is a
specially-instrumented microprocessor.
• Allows you to stop execution, examine
CPU state, modify registers.

Logic analyzers
• A logic analyzer is an array of low-grade
oscilloscopes:
Components 2nd ed.

Logic analyzer architecture
UUT sample
memory
microprocessor
controller
system clock
clock
gen
state or
timing mode
vector
address
display
Components 2nd ed.
keypad

Boundary scan
• Simplifies testing of
multiple chips on a
board.
• Registers on pins can
be configured as a
scan chain.
• Used for debuggers,
in-circuit emulators.
Components 2nd ed.

Components 2nd ed.
How to exercise code
• Run on host system.
• Run on target system.
• Run in instruction-level simulator.
• Run on cycle-accurate simulator.
• Run in hardware/software co-simulation
environment.

Components 2nd ed.
Debugging real-time code
• Bugs in drivers can cause non-
deterministic behavior in the foreground
problem.
• Bugs may be timing-dependent.

System-level performance
analysis
• Performance depends
on all the elements of
the system:
• CPU.
• Cache.
• Bus.
• Main memory.
• I/O device.
memory
CPU
cache
Components 2nd ed.

Components 2nd ed.
Bandwidth as performance
• Bandwidth applies to several components:
• Memory.
• Bus.
• CPU fetches.
• Different parts of the system run at
different clock rates.
• Different components may have different
widths (bus, memory).

Components 2nd ed.
Bandwidth and data transfers
• Video frame: 320 x 240 x 3 = 230,400
bytes.
• Transfer in 1/30 sec.
• Transfer 1 byte/sec, 0.23 sec per frame.
• Too slow.
• Increase bandwidth:
• Increase bus width.
• Increase bus clock rate.

Bus bandwidth
• T: # bus cycles.
• P: time/bus cycle.
• Total time for
transfer:
• t = TP.
• D: data payload
length.
• O1 + O2 = overhead
O.
O1 D O2
W
Components 2nd ed.
basic
T (N) = (D+O)N/W

Bus burst transfer bandwidth
• T: # bus cycles.
• P: time/bus cycle.
• Total time for
transfer:
• t = TP.
• D: data payload
length.
• O1 + O2 = overhead
O.
B O
W
Components 2nd ed.
burst
T (N) = (BD+O)N/(BW)
2
1
…

Memory aspect ratios
16 M
64 M
8 M
Components 2nd ed.
1 4 8

Components 2nd ed.
Memory access times
• Memory component access times comes
from chip data sheet.
• Page modes allow faster access for
successive transfers on same page.
• If data doesn’t fit naturally into physical
words:
• A = [(E/w)mod W]+1

Bus performance bottlenecks
• Transfer 320 x 240
video frame @ 30
frames/sec = 612,000
bytes/sec.
• Is performance
bottleneck bus or
memory?
memory
CPU
Components 2nd ed.

Components 2nd ed.
Bus performance bottlenecks,
cont’d.
• Bus: assume 1 MHz bus, D=1, O=3:
• Tbasic = (1+3)612,000/2 = 1,224,000 cycles =
1.224 sec.
• Memory: try burst mode B=4, width
w=0.5.
• Tmem = (4*1+4)612,000/(4*0.5) = 2,448,000
cycles = 0.2448 sec.

Components 2nd ed.
Performance spreadsheet
bus memory
clock period 1.00E-06 clock period 1.00E-08
W 2 W 0.5
D 1 D 1
O 3 O 4
B 4
N 612000 N 612000
T_basic 1224000 T_mem 2448000
t 1.22E+00 t 2.45E-02

Parallelism
• Speed things up by
running several units
at once.
• DMA provides
parallelism if CPU
doesn’t need the bus:
• DMA + bus.
• CPU.
Components 2nd ed.

Components 2nd ed.
• Example: alarm clock

Alarm clock interface
Alarm on Alarm off
Alarm
ready
set set
time alarm
hour minute
light
button
PM
buzzer
Components 2nd ed.

Components 2nd ed.
Operations
• Set time: hold set time, depress hour,
minute.
• Set alarm time: hold set alarm, depress
hour, minute.
• Turn alarm on/off: depress alarm on/off.

Components 2nd ed.
Alarm clock requirements
name
purpose
inputs
outputs
functions
alarm clock
24-hour digital clock with one alarm
set time, set alarm, hour, minute, alarm on/off
four-digit display, PM indicator, alarm ready, buzzer
keep time, set time, set alarm, turn alarm on/off,
activate buzzer by alarm
hours and digits, no seconds; not high precision
consumer product
performance
manufacturing
cost
power
physical
size/weight
AC
fits on stand

Alarm clock class diagram
Lights* Display Mechanism
Buttons*
Speaker*
1 1
Components 2nd ed.
1 1
1
1
1
1

Components 2nd ed.
Alarm clock physical classes
Lights*
digit-val()
digit-scan()
alarm-on-light()
PM-light()
Buttons*
set-time(): boolean
set-alarm(): boolean
alarm-on(): boolean
alarm-off(): boolean
minute(): boolean
hour(): boolean
Speaker*
buzz()

Components 2nd ed.
Display class
Display
time[4]: integer
alarm-indicator: boolean
PM-indicator: boolean
set-time()
alarm-light-on()
alarm-light-off()
PM-light-on()
PM-light-off()

Components 2nd ed.
Mechanism class
Mechanism
Seconds: integer
PM: boolean
tens-hours, ones-hours: boolean
tens-minutes, ones-minutes: boolean
alarm-ready: boolean
alarm-tens-hours, alarm-ones-hours:
boolean
alarm-tens-minutes, alarm-ones-minutes:
boolean
scan-keyboard()
update-time()

Update-time behavior
update seconds
with rollover
F
Rollover?
T
update hh:mm
with rollover
PM=true PM=false
AM->PM PM->AM
display.set-time(current time)
alarm.buzzer(true)
Time >= alarm and alarm-on?
T
F
Components 2nd ed.

Scan-keyboard behavior
compute button activations
alarm-ready=
true
alarm-ready=
false
alarm.buzzer(false)
save button
states
Alarm-on
and minutes
Components 2nd ed.
Alarm-off
Set-time and
not set-alarm
and hours
Increment time
tens w. rollover
andAM/PM
Increment time
ones w. rollover
andAM/PM
Set-time and
not set-alarm

Components 2nd ed.
System architecture
• Includes:
• periodic behavior (clock);
• aperiodic behavior (buttons, buzzer
activation).
• Two major software components:
• interrupt-driven routine updates time;
• foreground program deals with buttons,
commands.

Components 2nd ed.
Interrupt-driven routine
• Timer probably can’t handle one-minute
interrupt interval.
• Use software variable to convert interrupt
frequency to seconds.

Components 2nd ed.
Foreground program
• Operates as while loop:
while (TRUE) {
read_buttons(button_values);
process_command(button_values);
check_alarm();
}

Components 2nd ed.
Testing
• Component testing:
• test interrupt code on the platform;
• can test foreground program using a mock-
up.
• System testing:
• relatively few components to integrate;
• check clock accuracy;
• check recognition of buttons, buzzer, etc.

Components 2nd ed.
Program design and analysis
• Software components.
• Representations of programs.
• Assembly and linking.

Components 2nd ed.
Software state machine
• State machine keeps internal state as a
variable, changes state based on inputs.
• Uses:
• control-dominated code;
• reactive systems.

State machine example
idle
buzzer seated
belted
no seat/-
Components 2nd ed.
seat/timer on
no belt
and no
timer/-
no belt/timer on
belt/-
belt/
buzzer off
Belt/buzzer on
no seat/-
no seat/
buzzer off

Components 2nd ed.
C implementation
#define IDLE 0
#define SEATED 1
#define BELTED 2
#define BUZZER 3
switch (state) {
case IDLE: if (seat) { state = SEATED; timer_on = TRUE; }
break;
case SEATED: if (belt) state = BELTED;
else if (timer) state = BUZZER;
break;
…
}

Signal processing and circular
buffer
• Commonly used in signal processing:
• new data constantly arrives;
• each datum has a limited lifetime.
• Use a circular bu
f
fer to hold the data
stream.
d1 d2 d3 d4 d5 d6 d7
time time t+1
Components 2nd ed.

Circular buffer
x1 x2 x3 x4 x5 x6
t1 t2 t3
Data stream
Components 2nd ed.
x1 x2 x3
x5 x6 x7 x4
Circular buffer

Circular buffers
• Indexes locate currently used data,
current input data:
d1
d2
d3
d4
time t1
use
input d5
d2
d3
d4
time t1+1
use
input
Components 2nd ed.

406997673-Computers-as-Components-2nd-Edi-Wayne-Wolf.pptx

406997673-Computers-as-Components-2nd-Edi-Wayne-Wolf.pptx

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 406997673-Computers-as-Components-2nd-Edi-Wayne-Wolf.pptx

Similaire à 406997673-Computers-as-Components-2nd-Edi-Wayne-Wolf.pptx (20)

Dernier

Dernier (20)

406997673-Computers-as-Components-2nd-Edi-Wayne-Wolf.pptx