0% found this document useful (0 votes)

9 views

Unit-2 Embedded System Analysis and Design

The document discusses the embedded system design process and its major steps. It covers requirements analysis, specifications, architecture design, component design, system integration, and formal modeling techniques like UML. Requirements analysis establishes what the system should do, specifications define how it will meet requirements, and architecture design plans the overall system structure.

Uploaded by

narutoblue12345

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

9 views

Unit-2 Embedded System Analysis and Design

Uploaded by

narutoblue12345

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 478

Unit- 2

• THE EMBEDDED SYSTEM DESIGN PROCESS

• It will give us an introduction to the various steps in

embedded system design before we look into them in more
detail.
• it will allow us to consider the design methodology .
• A design methodology is important for three reasons
• First, it allows us to keep a scorecard on a design
• Second, it allows us to develop computer-aided design tools.
• Third, a design methodology makes it much easier for members of a
design team to communicate.

1
Major levels of abstraction in the
design process.

2
Requirements
• before we design a system, we must know what
we are designing.
• May be developed in several ways:
• talking directly to customers;
• talking to marketing representatives;
• providing prototypes to users for comment.
• Requirements may be functional or
nonfunctional

3
Functional vs. non-functional
requirements
• Functional requirements:
• output as a function of input.
• Non-functional requirements:
• Performance, Cost;
• time required to compute output;
• Physical size and weight;
• power consumption;
• reliability;
• etc.
4
A sample requirements form that can be filled out at
the start of the project.

name
purpose
Inputs
outputs
functions
performance
manufacturing cost
power
physical size/weight

5
Requirements analysis of a GPS
moving map

• The moving map is a handheld device that

displays for the user a map of the terrain
around the user’s current position; I-78

Scotch Road
• the map display changes as the user and the
map device change position..
• The moving map obtains its position from
the GPS, a satellite-based navigation
system.
• The moving map display the location

lat: 40 13 lon: 32 19

6
GPS moving map needs

• Functionality: The system should show major roads and

other landmarks available in standard databases.
• User interface: The screen should have at least 400600
pixel resolution.
• The device should be controlled by no more
than three buttons.
• A menu system should pop up on the
screen when buttons are pressed

7
GPS moving map needs, cont’d.
• Performance: Map should scroll smoothly. No more than
1 sec power-up. system should be able to verify its
position and display the current map within 15 s.
• Cost: Should be economical
• Physical size/weight: Should fit in hand.
• Power consumption: Should run for 8 hours on four AA
batteries.

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

9
Specification

• it serves as the contract between the customer and the

architects.
• The specification should be understandable, so that someone
can verify that it meets system requirements and overall
expectations of the customer.
• 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.

10
GPS specification Should include:

• What data is received from GPS;

• map data;
• user interface;
• operations required to satisfy user requests;
• background operations needed to keep the
system running.

11
Architecture design
• The architecture is a plan for the overall structure of the
system.

• The specification does not say how the system does the things,
only what the system does.

• Describing how the system implements those functions is the

purpose of the architecture.

• To understand what an architectural description is, let’s look at

a sample architecture for the moving map Example

12
GPS moving map block diagram

GPS search display

renderer
receiver engine

user
database interface

We can concentrate on the functional elements in the system block

diagram, and then consider the nonfunctional constraints when creating
the hardware and software architectures.

13
GPS moving map hardware
architecture

display frame CPU

buffer
GPS
receiver

memory
panel I/O

14
GPS moving map software
architecture

position database pixels

renderer
search

user
timer
interface

15
Designing hardware and software
components
• The architectural description tells us what components
we need.
• The components will in general include both hardware—
FPGAs, boards, and so on—and software modules.
• Some components are ready-made, some can be
modified from existing designs, others must be designed
from scratch.
• You will have to design some components yourself.
• Even if you are using only standard integrated circuits,
you may have to design the PCB that connects them

16
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.

• System integration is difficult because it usually

uncovers problems.

17
FORMALISMS FOR SYSTEM DESIGN

• Formalisms means a description of something in the formal

mathematical or logical terms.
• there is a visual language that can be used to capture all the
design tasks is the Unified Modeling Language (UML)
• UML was designed to be useful at many levels of abstraction in
the design process.
• UML is an object-oriented modeling language.
• We can also use UML to model the outside world that interacts
with our system.
• UML is so rich, there are many graphical elements in a UML
diagram.

18
Structural Description
• structural description, mean the basic components of the
system;
• we will learn how to describe how these components act in the
next section
• An object includes a set of attributes that define its internal
state.
• these attributes usually become variables or constants held in a
data structure.
• An object describing a display (such as a CRT screen) is shown
in UML notation
• The attribute is, in this case, an array of pixels that holds the
contents of the display

19
Objects and classes

• The object is identified in two ways:

• It has a unique name, and it is a member of a class.
• A class is a form of type definition—all objects derived from
the same class have the same characteristics,
• A class defines the attributes that an object may have.
• It also defines the operations that determine how the
object interacts with the rest of the world.
• In a programming language, the operations would become
pieces of code used to manipulate the object.

20
UML object

object name
class name
d1: Display

pixels is a pixels: array[] of pixels

2-D array elements
menu_items

comment
attributes

21
UML class

Display class name

pixels
elements
menu_items

mouse_click()
operations
draw_box

22
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.

23
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.
24
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.

25
Class derivation

• May want to define one class in terms of

another.
• Derived class inherits attributes, operations of
base class.

Derived_class
UML
generalization
Base_class

26
Class derivation example

Display
base
pixels class
elements
menu_items
pixel()
derived class set_pixel()
mouse_click()
draw_box

BW_display Color_map_display

27
Multiple inheritance

base classes

Speaker Display

Multimedia_display

derived class

28
Behavioral description

• Several ways to describe behavior:

• internal view;
• external view.

29
State machines

transition

a b

state state name

30
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.

31
Types of events

• Signal: asynchronous event.

• Call: synchronized communication.

• Timer: activated by time.

32
Signal event

<<signal>>
mouse_click a

Left or right: button

mouse_click(x,y,button)
x, y: position

b
declaration

event description

33
Call event

draw_box (10,5,3,2,blue)

c d

34
Timer event

tm(time-value)

e f

35
Example state machine

start input/output
mouse_click(x,y,button)/ region = menu/
find_region(region) which_menu(i) call_menu(I)
region got menu called
found item menu item
region = drawing/
find_object(objid) highlight(objid)

found object
object highlighted

finish
36
Sequence diagram

• Shows sequence of operations over time.

• Relates behaviors of multiple objects.

37
Sequence diagram example

m: Mouse d1: Display u: Menu

mouse_click(x,y,button)
which_menu(x,y,i)

time
call_menu(i)

38
MEMORY SYSTEM MECHANISMS

• Architectural features improve both the speed

and capacity of memory systems.
• computer architects resort to caches to
increase the average performance of
• the memory system.
• Modern microprocessor units (MMUs)
perform
• address translations that provide a larger virtual
memory space in a small physical
• memory.
39
Caches

• A cache is a small, fast memory that holds copies of

some of the contents of main memory.
• It provides higher-speed access for the CPU
• Caches are widely used to speed up memory system
performance.
• The cache speeds up average memory access time
when properly used.
• It increases the variability of memory access times—
accesses in the cache will be fast

40
Caches and CPUs

address data
cache

controller
cache main
CPU
memory
address
data data

41
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.

42
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.

43
Types of misses

• Compulsory Miss (cold miss): location has never

been accessed, and occurs the first time a location is
used.

• Capacity Miss: caused by a too-large working set.

• Conflict Miss: happens when two locations map to

the same location in the cache.

44
Memory system performance
• The average memory access time is given as

• tav = htcache + (1-h)tmain

• h = cache hit rate.

• tcache = cache access time,
• tmain = main memory access time.

• The hit rate depends on the program being executed and the
cache organization, and is typically measured using simulators
• t main is typically 50–60 ns for DRAM, while tcache is at most
a few nanoseconds
45
Multiple levels of cache
Modern CPUs may use multiple levels of cache as shown

CPU L1 cache L2 cache

46
Multi-level cache access time

• the average access time for a two-level cache

system is
• tav = h1tL1 + (h2-h1)tL2 + (1- h2-h1)tmain

• h1 = first-level hit rate.

• h2 = hit rate for L2 and miss on L1.

47
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).

48
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.

49
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.

50
Direct-mapped cache

1 0xabcd byte byte byte ...

valid tag data
cache block

tag index offset

hit value
byte

51
Write operations

• Write-through: immediately copy write to

main memory.
• Write-back: write to main memory only
when location is removed from cache.

52
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.

53
Set-associative cache

• A set of direct-mapped caches:

Set 1 Set 2 ... Set n

hit data
54
Example: direct-mapped vs.
set-associative

address data
000 0101
001 1111
010 0000
011 0110
100 1000
101 0001
110 1010
111 0100

55
Direct-mapped cache behavior

• After 001 access: • After 010 access:

block tag data block tag data
00 - - 00 - -
01 0 1111 01 0 1111
10 - - 10 0 0000
11 - - 11 - -

56
Direct-mapped cache behavior,
cont’d.

• After 011 access: • After 100 access:

block tag data block tag data
00 - - 00 1 1000
01 0 1111 01 0 1111
10 0 0000 10 0 0000
11 0 0110 11 0 0110

57
Direct-mapped cache behavior,
cont’d.

• After 101 access: • After 111 access:

block tag data block tag data
00 1 1000 00 1 1000
01 1 0001 01 1 0001
10 0 0000 10 0 0000
11 0 0110 11 1 0100

58
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

59
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

60
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.

61
Memory management units

• Memory management unit (MMU)

translates addresses:

logical physical
address memory address main
CPU management
memory
unit

62
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.

63
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).

64
Segments and pages

page 1
page 2
segment 1

memory

segment 2

65
Segment address translation

segment base address logical address

segment lower bound range range

segment upper bound check error

physical address

66
Page address translation

page offset

page i base

concatenate

page offset

67
Page table organizations

page
descriptor
page descriptor

flat tree

68
Caching address translations
• Large translation tables require main
memory access.
• TLB: cache for address translation.
• Typically small.

69
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.

70
ARM address translation

Translation table 1st index 2nd index offset

base register

descriptor concatenate
1st level table

concatenate
descriptor
2nd level table physical address

71
CPU performance

• Elements of CPU performance

• Cycle time.
• CPU pipeline.
• Memory system management.

72
Pipelining
• Several instructions are executed simultaneously at
different stages of completion.
• Pipelining greatly increases the efficiency of the
CPU.
• ARM 7 Processor has three stage pipeline.
• Fetch : the instruction is fetched from memory.
• Decode: the instruction’s opcode and operands are
decoded to determine what function to
perform.
• Execute : the decoded instruction is executed.
• Each of these operations requires one clock cycle for
typical instructions.
73
ARM pipeline execution

add r0,r1,#5
fetch decode execute

sub r2,r3,r6 fetch decode execute

cmp r2,#3 fetch decode execute

time
1 2 3

74
Performance measures

• Latency: time takes for an instruction to get

through the pipeline.
• a normal instruction requires three clock cycles to
completely execute, known as the latency of instruction
execution.
• Throughput: number of instructions executed per
time period.
• the pipeline has a throughput of one instruction per
cycle.

75
CPU power consumption
• Most modern CPUs are designed with
power consumption in mind to some
degree.
• Power is, energy consumption per unit
time.
• heat generation depends on power
consumption
• battery life depends on energy consumption.

76
CMOS power consumption
• Voltage drops: power consumption proportional to V2 ( power
supply voltage)
• Therefore, by reducing the power supply voltage, we
can significantly reduce power consumption.
• Toggling: CMOS circuit uses most of its power when it is
changing its output value.
• By reducing the speed at which the circuit operates, we can
reduce its power consumption
• Leakage: The only way to eliminate leakage current is to
remove the power supply when the circuit is not
active.

77
CPU power-saving techniques

• 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.

78
Power management features

• 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 by CPU
while executing some instructions.

79
Power-down costs
• A power-down mode provides the opportunity to
reduce power consumption
• Going into a power-down mode costs:
• The power-down or power-up transition consumes time and
energy in order to control the CPU’s internal logic.

Power state machine for a processor.

80
Strong ARM SA-1100 power saving

• Three power modes:

• Run: normal operation.
• Idle: stops CPU clock and all other blocks remain working.
• Sleep: shuts off most of chip activity;
• The sleep shutdown sequence happens in three steps, each of which
requires about 30 us.
• The wake-up sequence has three steps:
• the PWR_EN pin is activated to turn ON the external power supply
• waits for about 10 ms;
• the CPU boot sequence begins.

81
SA-1100 power state machine

Prun = 400 mW

run
10 ms
160 ms
90 ms
10 ms
90 ms
idle sleep

Pidle = 50 mW Psleep = 0.16 mW

82
The CPU bus

• Bus allows CPU, memory, devices to

communicate.
• Shared communication medium.
• A bus is:
• A set of wires.
• A communications protocol for all the devices.
• One of the major roles of the bus is to provide an interface
to memory.

83
Bus protocols
• Bus protocol determines how devices communicate.
• Devices on the bus go through sequences of states.
• Protocols are specified by state machines,
• The basic building block of most bus protocols is the
four-cycle handshake
• The handshake ensures that when two devices want to
communicate, one is ready to transmit and the other is
ready to receive.
• The handshake uses a pair of wires dedicated to the
handshake
• enq (enquiry) and
• ack ( acknowledge).

84
Four-cycle handshake

enq device 1

device 1 device 2

ack
device 2

1 2 3 4
time

85
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.
At the end of the handshake, both handshaking
signals are low,

86
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.

87
Timing diagrams

88
Bus read

89
State diagrams for bus read

Get Done Send Release

data data ack
Start here
See Ack
ack Adrs Adrs

Wait Wait Start here

device
CPU start

90
Bus multiplexing

data enable device

data
CPU
adrs

adrs

Adrs enable

91
DMA
• Direct memory access
(DMA) is a bus operation that
allows reads and writes not
controlled by the CPU.
• A DMA transfer is controlled by
a DMA controller,
• The bus request is an input
to the CPU through which DMA
controllers ask for ownership
of the bus.
• ■ The bus grant signals that
the bus has been granted to
the DMA controller.

92
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.
• A device that can initiate its own bus transfer is
known as a bus master.
• Bus mastership protocol:
• Bus request.
• Bus grant.

93
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.

94
System bus configurations

• Multiple busses allow

parallelism: CPU slow device
• Slow devices on one

bridge
bus.
• Fast devices on memory slow device
separate bus.
• A bridge connects high-speed
device
two busses.

95
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.

96
Memory Devices

• Several different
types of memory:
• DRAM.
• SRAM.
• Flash.
• Each type of memory
comes in varying:
• Capacities.
• Widths.

97
Random-access memory

• Random-access memories can be both read and

written.
• Most
• bulk memory in modern systems is dynamic
RAM (DRAM).
• DRAM is very dense; its values be refreshed
periodically
• The dominant form of dynamic RAM today is the
synchronous DRAMs(SDRAMs), which uses
clocks to improve DRAM performance.

98
Static RAM

• SRAM is faster than DRAM

• SRAM consumes more power than DRAM
• More DRAM can be put on Single chip
• DRAM values must be periodically
refreshed.

99
Read-only memory

• ROM may be programmed at factory.

• Flash is dominant form of field-
programmable ROM.
• EPROM
• EEPROM
• Electrically erasable, must be block erased.
• Random access, but write/erase is much
slower than read.

100
Timers and counters
• Very similar:
• a timer is incremented by a periodic signal;
• a counter is incremented by an
asynchronous, occasional signal.

101
Watchdog timer
• Watchdog timer is periodically reset by
system timer.
• If watchdog is not reset, it generates an
interrupt to reset the host.

interrupt

host CPU watchdog

reset timer

102
Switch debouncing
• A switch must be debounced to multiple
contacts caused by eliminate mechanical
bouncing:

103
Encoded keyboard
• An array of switches is read by an
encoder.
• N-key rollover remembers multiple key
depressions.

row

104
LED

• Must use resistor to limit current:

105
7-segment LCD display

• May use parallel or multiplexed input.

106
Touchscreen position sensing

ADC

voltage

107
Digital-to-analog conversion
• Use resistor tree:

R
bn Vout
2R

bn-1
4R
bn-2
8R
bn-3

108
Flash A/D conversion

• N-bit result requires 2n comparators:

Vin

encoder

...

109
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.

110
Host/target design

• Use a host system to prepare software for

target system:

target
system

serial line
host system

111
Host-based tools

• Cross compiler:
• compiles code on host for target system.
• Cross debugger:
• displays target state, allows target system to
be controlled.

112
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.

113
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.

114
In-circuit emulators

• A microprocessor in-circuit emulator is a

specially-instrumented microprocessor.
• Allows you to stop execution, examine
CPU state, modify registers.

115
Logic analyzers

• A logic analyzer is an array of low-grade

oscilloscopes:

116
Program design and analysis

• Software components.
• Representations of programs.
• Assembly and linking.

117
Models of programs
• Source code is not a good representation for
programs:
• Compilers derive intermediate representations
to manipulate and optimize the program.

118
Data flow graph
• DFG: data flow graph.
• Does not represent control.
• Models basic block: code with no entry or
exit.
• Describes the minimal ordering
requirements on operations.

119
Data flow graph

x = a + b; a b c d
y = c - d;
+ -
z = x * y;
y1 = b + d; x
y

* +
single assignment form
z y1
DFG

120
Control-data flow graph

• CDFG: represents control and data.

• Uses data flow graphs as components.
• Two types of nodes:
• decision;
• data flow.

121
CDFG example

T
if (cond1) bb1(); cond1 bb1()
else bb2(); F
bb3(); bb2()
switch (test1) {
case c1: bb4(); break; bb3()
case c2: bb5(); break;
case c3: bb6(); break; c3
c1 test1
}
c2
bb4() bb5() bb6()

122
for loop

for (i=0; i<N; i++)

i=0
loop_body();
for loop
F
i<N
i=0; T
while (i<N) {
loop_body(); i++; } loop_body()

equivalent
123
Assembly and linking

124
Assemblers
• Major tasks:
• generate binary for symbolic instructions;
• translate labels into addresses;
• handle pseudo-ops (data, etc.).
• Generally one-to-one translation.
• Assembly labels:
ORG 100
label1 ADR r4,c

125
Symbol table

ADD r0,r1,r2 xx 0x8

xx ADD r3,r4,r5 yy 0x10
CMP r0,r3
yy SUB r5,r6,r7

assembly code symbol table

126
Program performance metrics
• Try to use registers efficiently.
• Make use of page mode accesses in the memory
system whenever possible.
• Analyze cache behavior to find major cache
conflicts.

127
Energy/power optimization
• In optimizing a program’s energy consumption is
knowing how much energy the program consumes.
• It is possible to measure power consumption for an
instruction or a small code
• Energy consumption varies somewhat from
instruction to instruction.
• The sequence of instructions has some influence.
• The opcode and the locations of the operands also
matter.

128
Measuring energy consumption

• Execute a small loop, measure current:

129
Efficient loops
• General rules:
• Don’t use function calls.
• Keep loop body small to enable local repeat
(only forward branches).
• Use unsigned integer for loop counter.
• Use <= to test loop counter.
• Make use of compiler---global optimization,
software pipelining.

130
Optimizing for program size
• Goal:
• reduce hardware cost of memory;
• reduce power consumption of memory units.
• Two opportunities:
• data;
• instructions.

131
Data size minimization
• Reuse constants, variables, data buffers in
different parts of code.
• Requires careful verification of correctness.
• Generate data using instructions.

132
Program validation and testing
• The two major types of testing strategies:
• Black-box methods generate tests
without looking at the internal structure of
the program.
• Clear-box (also known as white-box)
methods generate tests based on the
program structure.

133
Clear-box testing
• Examine the source code to determine whether
it works:
• Can you actually exercise a path?
• Do you get the value you expect along a path?
• Testing procedure:
• Controllability: rovide program with inputs.
• Execute.
• Observability: examine outputs.

134
Black-box test vectors
• Random tests.
• May weight distribution based on software
specification.
• Regression tests.
• Tests of previous versions, bugs, etc.
• May be clear-box tests of previous versions.

135
Hardware platform
• CPU.
• A/D converter.
• D/A converter.
• Timer.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 136
Component design and testing
• Easy to test transmitter and receiver on
host.
• Transmitter can be verified with speaker
outputs.
• Receiver verification tasks:
• start bit recognition;
• data bit recognition.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 137
System integration and testing
• Use loopback mode to test components
against each other.
• Loopback in software or by connecting D/A
and A/D converters.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 138
Processes and operating
systems
• Multiple tasks and multiple processes.
• Specifications of process timing.
• Preemptive real-time operating systems.
• Processes and UML.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 139
Reactive systems
• Respond to external events.
• Engine controller.
• Seat belt monitor.
• Requires real-time response.
• System architecture.
• Program implementation.
• May require a chain reaction among
multiple processors.

Overheads for Computers as

• A task is a functional • A process is a unique

description of a execution of a program.
• Several copies of a
connected set of program may run
operations. simultaneously or at
different times.
• (Task can also mean
• A process has its own
a collection of
state:
processes.) • registers;
• memory.
• The operating system
manages processes.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 141
Why multiple processes?
• Multiple tasks means multiple processes.
• Processes help with timing complexity:
• multiple rates
• multimedia
• automotive
• asynchronous input
• user interfaces
• communication systems

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 142
Multi-rate systems
• Tasks may be synchronous or
asynchronous.
• Synchronous tasks may recur at different
rates.
• Processes run at different rates based on
computational needs of the tasks.

Overheads for Computers as

• Tasks:
• spark control
• crankshaft sensing
• fuel/air mixture engine
• oxygen sensor controller
• Kalman filter

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 144
Typical rates in engine
controllers
Variable Full range time (ms) Update period (ms)
Engine spark timing 300 2
Throttle 40 2
Air flow 30 4
Battery voltage 80 4
Fuel flow 250 10
Recycled exhaust gas 500 25
Status switches 100 20
Air temperature Seconds 400
Barometric pressure Seconds 1000
Spark (dwell) 10 1
Fuel adjustment 80 8
Carburetor 500 25
Mode actuators 100
Overheads for Computers as 100
© 2008 Wayne Wolf Components 2nd ed. 145
Real-time systems
• Perform a computation to conform to external
timing constraints.
• Deadline frequency:
• Periodic.
• Aperiodic.
• Deadline type:
• Hard: failure to meet deadline causes system failure.
• Soft: failure to meet deadline causes degraded
response.
• Firm: late response is useless but some late
responses can be tolerated.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 146
Timing specifications on
processes
• Release time: time at which process
becomes ready.
• Deadline: time at which process must
finish.

Overheads for Computers as

deadline

P1
time
initiating period
event aperiodic process
periodic process initiated
at start of period
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 148
Rate requirements on
processes

• Period: interval
between process
activations.
CPU 1 P11
• Rate: reciprocal of
period. CPU 2 P12
• Initiatino rate may be CPU 3 P13
higher than period--- CPU 4 P14
several copies of
process run at once. time

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 149
Timing violations
• What happens if a process doesn’t finish
by its deadline?
• Hard deadline: system fails if missed.
• Soft deadline: user may notice, but system
doesn’t necessarily fail.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 150
Example: Space Shuttle
software error
• Space Shuttle’s first launch was delayed
by a software timing error:
• Primary control system PASS and backup
system BFS.
• BFS failed to synchronize with PASS.
• Change to one routine added delay that
threw off start time calculation.
• 1 in 67 chance of timing problem.

Overheads for Computers as

• Tasks may have data P1 P2

dependencies---must P5
execute in certain order.
• Task graph shows P3
data/control
dependencies between P6
processes. P4
• Task: connected set of
processes. task 1 task 2
• Task set: One or more
tasks. task set
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 152
Communication between tasks

• Task graph assumes that

all processes in each task MPEG
run at the same rate, system
tasks do not layer
communicate.
• In reality, some amount
of inter-task MPEG MPEG
communication is audio video
necessary.
• It’s hard to require
immediate response for
multi-rate communication.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 153
Process execution
characteristics
• Process execution time Ti.
• Execution time in absence of preemption.
• Possible time units: seconds, clock cycles.
• Worst-case, best-case execution time may be useful
in some cases.
• Sources of variation:
• Data dependencies.
• Memory system.
• CPU pipeline.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 154
Utilization
• CPU utilization:
• Fraction of the CPU that is doing useful work.
• Often calculated assuming no scheduling
overhead.
• Utilization:
• U= (CPU time for useful work)/ (total available CPU time)
=[S t1 ≤ t ≤ t2 T(t) ] / [t2 – t1]
= T/t

Overheads for Computers as

• A process can be in
one of three states: executing gets data
• executing on the CPU; gets and CPU
preempted
• ready to run; CPU needs
data
• waiting for data.
gets data
ready waiting
needs data

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 156
The scheduling problem
• Can we meet all deadlines?
• Must be able to meet deadlines in all cases.
• How much CPU horsepower do we need
to meet our deadlines?

Overheads for Computers as

• Resource constraints
make schedulability
analysis NP-hard. P1 P2

• Must show that the

deadlines are met for
all timings of resource
requests. I/O device

Overheads for Computers as

• Assume:
• No resource conflicts.
• Constant process T1 T2 T3
execution times.
• Require: T
• T ≥ Si Ti
• Can’t use more than
100% of the CPU.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 159
Hyperperiod
• Hyperperiod: least common multiple
(LCM) of the task periods.
• Must look at the hyperperiod schedule to
find all task interactions.
• Hyperperiod can be very long if task
periods are not chosen carefully.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 160
Hyperperiod example
• Long hyperperiod:
• P1 7 ms.
• P2 11 ms.
• P3 15 ms.
• LCM = 1155 ms.
• Shorter hyperperiod:
• P1 8 ms.
• P2 12 ms.
• P3 16 ms.
• LCM = 96 ms.

Overheads for Computers as

• P1 period 1 ms, CPU

time 0.1 ms. LCM 5.00E-03
• P2 period 1 ms, CPU P1
peirod CPU time CPU time/LCM
1.00E-03 1.00E-04 5.00E-04
time 0.2 ms. P2 1.00E-03 2.00E-04 1.00E-03
P3 5.00E-03 3.00E-04 3.00E-04
• P3 period 5 ms, CPU
time 0.3 ms. total CPU/LCM
utilization
1.80E-03
3.60E-01

Overheads for Computers as

• Schedule in time
slots. T1 T2 T3 T1 T2 T3
• Same process
activation P P
irrespective of
workload.
• Time slots may be
equal size or
unequal.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 163
TDMA assumptions

• Schedule based on
least common
multiple (LCM) of
the process P1 P1 P1
periods.
P2 P2
• Trivial scheduler -
> very small PLCM
scheduling
overhead.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 164
TDMA schedulability
• Always same CPU utilization (assuming
constant process execution times).
• Can’t handle unexpected loads.
• Must schedule a time slot for aperiodic
events.

Overheads for Computers as

• TDMA period = 10
ms. TDMA period 1.00E-02
• P1 CPU time 1 ms. P1
CPU time
1.00E-03
• P2 CPU time 3 ms. P2 3.00E-03
P3 2.00E-03
• P3 CPU time 2 ms. P4 2.00E-03
total 8.00E-03
• P4 CPU time 2 ms. utilization 8.00E-01

Overheads for Computers as

• Schedule process
only if ready.
• Always test T1 T2 T3 T2 T3
processes in the
same order.
• Variations: P P
• Constant system
period.
• Start round-robin
again after finishing
a round.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 167
Round-robin assumptions
• Schedule based on least common multiple
(LCM) of the process periods.
• Best done with equal time slots for
processes.
• Simple scheduler -> low scheduling
overhead.
• Can be implemented in hardware.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 168
Round-robin schedulability
• Can bound maximum CPU load.
• May leave unused CPU cycles.
• Can be adapted to handle unexpected
load.
• Use time slots at end of period.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 169
Schedulability and overhead
• The scheduling process consumes CPU
time.
• Not all CPU time is available for processes.
• Scheduling overhead must be taken into
account for exact schedule.
• May be ignored if it is a small fraction of total
execution time.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 170
Running periodic processes
• Need code to control execution of
processes.
• Simplest implementation: process =
subroutine.

Overheads for Computers as

• Simplest while (TRUE) {

implementation has p1();
one loop. p2();
• No control over
execution timing. }

Overheads for Computers as

• Encapuslate set of all void pall(){

processes in a single p1();
function that p2();
implements the task
set,. }
• Use timer to control
execution of the task.
• No control over timing
of individual
processes.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 173
Multiple timers implementation

• Each task has its own void pA(){ /* rate A */

function. p1();
• Each task has its own p3();
timer. }
• May not have enough void B(){ /* rate B */
timers to implement p2();
all the rates. p4();
p5();
}

Overheads for Computers as

• Use a software count int p2count = 0;

to divide the timer. void pall(){
• Only works for clean p1();
multiples of the timer if (p2count >= 2) {
period. p2();
p2count = 0;
}
else p2count++;
p3();
}
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 175
Implementing processes
• All of these implementations are
inadequate.
• Need better control over timing.
• Need a better mechanism than
subroutines.

Overheads for Computers as

© 2000 Morgan Overheads for Computers as

Kaufman Components 177
Operating systems
• The operating system controls resources:
• who gets the CPU;
• when I/O takes place;
• how much memory is allocated.
• The most important resource is the CPU
itself.
• CPU access controlled by the scheduler.

© 2000 Morgan Overheads for Computers as

Kaufman Components 178
Process state

© 2000 Morgan Overheads for Computers as

Kaufman Components 179
Operating system structure
• OS needs to keep track of:
• process priorities;
• scheduling state;
• process activation record.
• Processes may be created:
• statically before system starts;
• dynamically during execution.

© 2000 Morgan Overheads for Computers as

Kaufman Components 180
Embedded vs. general-purpose
scheduling
• Workstations try to avoid starving
processes of CPU access.
• Fairness = access to CPU.
• Embedded systems must meet deadlines.
• Low-priority processes may not run for a long
time.

© 2000 Morgan Overheads for Computers as

Kaufman Components 181
Priority-driven scheduling
• Each process has a priority.
• CPU goes to highest-priority process that
is ready.
• Priorities determine scheduling policy:
• fixed priority;
• time-varying priorities.

© 2000 Morgan Overheads for Computers as

Kaufman Components 182
Priority-driven scheduling
example
• Rules:
• each process has a fixed priority (1 highest);
• highest-priority ready process gets CPU;
• process continues until done.
• Processes
• P1: priority 1, execution time 10
• P2: priority 2, execution time 30
• P3: priority 3, execution time 20

© 2000 Morgan Overheads for Computers as

Kaufman Components 183
Priority-driven scheduling
example

P3 ready t=18
P2 ready t=0 P1 ready t=15

P2 P1 P2 P3

0 10 20 30 40 50 60
time
© 2000 Morgan Overheads for Computers as
Kaufman Components 184
The scheduling problem
• Can we meet all deadlines?
• Must be able to meet deadlines in all cases.
• How much CPU horsepower do we need
to meet our deadlines?

© 2000 Morgan Overheads for Computers as

Kaufman Components 185
Process initiation disciplines
• Periodic process: executes on (almost)
every period.
• Aperiodic process: executes on demand.
• Analyzing aperiodic process sets is harder-
--must consider worst-case combinations
of process activations.

© 2000 Morgan Overheads for Computers as

Kaufman Components 186
Timing requirements on
processes
• Period: interval between process
activations.
• Initiation interval: reciprocal of period.
• Initiation time: time at which process
becomes ready.
• Deadline: time at which process must
finish.

© 2000 Morgan Overheads for Computers as

Kaufman Components 187
Timing violations
• What happens if a process doesn’t finish
by its deadline?
• Hard deadline: system fails if missed.
• Soft deadline: user may notice, but system
doesn’t necessarily fail.

© 2000 Morgan Overheads for Computers as

Kaufman Components 188
Example: Space Shuttle
software error
• Space Shuttle’s first launch was delayed
by a software timing error:
• Primary control system PASS and backup
system BFS.
• BFS failed to synchronize with PASS.
• Change to one routine added delay that
threw off start time calculation.
• 1 in 67 chance of timing problem.

© 2000 Morgan Overheads for Computers as

Kaufman Components 189
Interprocess communication
• Interprocess communication (IPC): OS
provides mechanisms so that processes
can pass data.
• Two types of semantics:
• blocking: sending process waits for response;
• non-blocking: sending process continues.

© 2000 Morgan Overheads for Computers as

Kaufman Components 190
IPC styles
• Shared memory:
• processes have some memory in common;
• must cooperate to avoid destroying/missing
messages.
• Message passing:
• processes send messages along a
communication channel---no common
address space.

© 2000 Morgan Overheads for Computers as

Kaufman Components 191
Shared memory

• Shared memory on a bus:

memory
CPU 1 CPU 2

© 2000 Morgan Overheads for Computers as

Kaufman Components 192
Race condition in shared
memory
• Problem when two CPUs try to write the
same location:
• CPU 1 reads flag and sees 0.
• CPU 2 reads flag and sees 0.
• CPU 1 sets flag to one and writes location.
• CPU 2 sets flag to one and overwrites
location.

© 2000 Morgan Overheads for Computers as

Kaufman Components 193
Atomic test-and-set
• Problem can be solved with an atomic
test-and-set:
• single bus operation reads memory location,
tests it, writes it.
• ARM test-and-set provided by SWP:
ADR r0,SEMAPHORE
LDR r1,#1
GETFLAG SWP r1,r1,[r0]
BNZ GETFLAG

© 2000 Morgan Overheads for Computers as

Kaufman Components 194
Critical regions
• Critical region: section of code that cannot
be interrupted by another process.
• Examples:
• writing shared memory;
• accessing I/O device.

© 2000 Morgan Overheads for Computers as

Kaufman Components 195
Semaphores
• Semaphore: OS primitive for controlling
access to critical regions.
• Protocol:
• Get access to semaphore with P().
• Perform critical region operations.
• Release semaphore with V().

© 2000 Morgan Overheads for Computers as

Kaufman Components 196
Message passing

• Message passing on a network:

CPU 1 CPU 2

message message

message

© 2000 Morgan Overheads for Computers as

Kaufman Components 197
Process data dependencies

• One process may not

be able to start until P1 P2
another finishes.
• Data dependencies
defined in a task
P3
graph.
• All processes in one
task run at the same P4
rate.
© 2000 Morgan Overheads for Computers as
Kaufman Components 198
Other operating system
functions
• Date/time.
• File system.
• Networking.
• Security.

© 2000 Morgan Overheads for Computers as

Kaufman Components 199
Processes and operating
systems
• Scheduling policies:
• RMS;
• EDF.
• Scheduling modeling assumptions.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 200
Metrics
• How do we evaluate a scheduling policy:
• Ability to satisfy all deadlines.
• CPU utilization---percentage of time devoted
to useful work.
• Scheduling overhead---time required to make
scheduling decision.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 201
Rate monotonic scheduling
• RMS (Liu and Layland): widely-used,
analyzable scheduling policy.
• Analysis is known as Rate Monotonic
Analysis (RMA).

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 202
RMA model
• All process run on single CPU.
• Zero context switch time.
• No data dependencies between processes.
• Process execution time is constant.
• Deadline is at end of period.
• Highest-priority ready process runs.

Overheads for Computers as

• Ti is computation time of process i; ti is

period of process i.

period ti

Pi
computation time Ti

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 204
Rate-monotonic analysis
• Response time: time required to finish
process.
• Critical instant: scheduling state that gives
worst response time.
• Critical instant occurs when all higher-
priority processes are ready to execute.

Overheads for Computers as

P1 P1 P1 P1 P1

P2 P2 P2

P3 P3
critical
instant
P4

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 206
RMS priorities
• Optimal (fixed) priority assignment:
• shortest-period process gets highest priority;
• priority inversely proportional to period;
• break ties arbitrarily.
• No fixed-priority scheme does better.

Overheads for Computers as

P2 period

P2
P1 period

P1 P1 P1

0 5 10
time
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 208
RMS CPU utilization
• Utilization for n processes is
• S i Ti / ti
• As number of tasks approaches infinity,
maximum utilization approaches 69%.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 209
RMS CPU utilization, cont’d.
• RMS cannot use 100% of CPU, even with
zero context switch overhead.
• Must keep idle cycles available to handle
worst-case scenario.
• However, RMS guarantees all processes
will always meet their deadlines.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 210
RMS implementation
• Efficient implementation:
• scan processes;
• choose highest-priority active process.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 211
Earliest-deadline-first
scheduling
• EDF: dynamic priority scheduling scheme.
• Process closest to its deadline has highest
priority.
• Requires recalculating processes at every
timer interrupt.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 213
EDF implementation
• On each timer interrupt:
• compute time to deadline;
• choose process closest to deadline.
• Generally considered too expensive to use
in practice.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 214
Fixing scheduling problems
• What if your set of processes is
unschedulable?
• Change deadlines in requirements.
• Reduce execution times of processes.
• Get a faster CPU.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 215
Priority inversion
• Priority inversion: low-priority process
keeps high-priority process from running.
• Improper use of system resources can
cause scheduling problems:
• Low-priority process grabs I/O device.
• High-priority device needs I/O device, but
can’t get it until low-priority process is done.
• Can cause deadlock.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 216
Solving priority inversion
• Give priorities to system resources.
• Have process inherit the priority of a
resource that it requests.
• Low-priority process inherits priority of device
if higher.

Overheads for Computers as

• Data dependencies
allow us to improve
P1
utilization.
• Restrict combination
of processes that can
run simultaneously. P2
• P1 and P2 can’t run
simultaneously.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 218
Context-switching time
• Non-zero context switch time can push
limits of a tight schedule.
• Hard to calculate effects---depends on
order of context switches.
• In practice, OS context switch overhead is
small (hundreds of clock cycles) relative to
many common task periods (ms – ms).

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 219
Processes and operating
systems
• Interprocess communication.
• Operating system performance.
• Power management.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 220
Interprocess communication
• OS provides interprocess communication
mechanisms:
• various efficiencies;
• communication power.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 221
Interprocess communication
• Interprocess communication (IPC): OS
provides mechanisms so that processes
can pass data.
• Two types of semantics:
• blocking: sending process waits for response;
• non-blocking: sending process continues.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 222
IPC styles
• Shared memory:
• processes have some memory in common;
• must cooperate to avoid destroying/missing
messages.
• Message passing:
• processes send messages along a
communication channel---no common
address space.

Overheads for Computers as

• Shared memory on a bus:

memory
CPU 1 CPU 2

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 224
Race condition in shared
memory
• Problem when two CPUs try to write the
same location:
• CPU 1 reads flag and sees 0.
• CPU 2 reads flag and sees 0.
• CPU 1 sets flag to one and writes location.
• CPU 2 sets flag to one and overwrites
location.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 225
Atomic test-and-set
• Problem can be solved with an atomic
test-and-set:
• single bus operation reads memory location,
tests it, writes it.
• ARM test-and-set provided by SWP:
ADR r0,SEMAPHORE
LDR r1,#1
GETFLAG SWP r1,r1,[r0]
BNZ GETFLAG

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 226
Critical regions
• Critical region: section of code that cannot
be interrupted by another process.
• Examples:
• writing shared memory;
• accessing I/O device.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 227
Semaphores
• Semaphore: OS primitive for controlling
access to critical regions.
• Protocol:
• Get access to semaphore with P().
• Perform critical region operations.
• Release semaphore with V().

Overheads for Computers as

• Message passing on a network:

CPU 1 CPU 2

message message

message

Overheads for Computers as

• One process may not

be able to start until P1 P2
another finishes.
• Data dependencies
defined in a task
P3
graph.
• All processes in one
task run at the same P4
rate.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 230
Signals in UML

• More general than Unix signal---may carry

arbitrary data:

someClass
<<signal>>
aSig
<<send>>
p : integer sigbehavior()

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 231
Evaluating RTOS performance
• Simplifying assumptions:
• Context switch costs no CPU time,.
• We know the exact execution time of
processes.
• WCET/BCET don’t depend on context
switches.

Overheads for Computers as

Process Execution deadline

time
P1 3 5
P2 3 10

With context switch overhead of

1, no feasible schedule.
2TP1 + TP2 = 2*(1+3)+(1_3)=11

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 233
Process execution time
• Process execution time is not constant.
• Extra CPU time can be good.
• Extra CPU time can also be bad:
• Next process runs earlier, causing new
preemption.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 234
Processes and caches
• Processes can cause additional caching
problems.
• Even if individual processes are well-behaved,
processes may interfere with each other.
• Worst-case execution time with bad
behavior is usually much worse than
execution time with good cache behavior.

Overheads for Computers as

Schedule 1 (LRU cache):

Process WCET Avg. CPU
time
P1 8 6
P2 4 3
P3 4 3

Schedule 2 (half of cache

reserved for P1):

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 236
Power optimization
• Power management: determining how
system resources are scheduled/used to
control power consumption.
• OS can manage for power just as it
manages for time.
• OS reduces power by shutting down units.
• May have partial shutdown modes.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 237
Power management and
performance
• Power management and performance are
often at odds.
• Entering power-down mode consumes
• energy,
• time.
• Leaving power-down mode consumes
• energy,
• time.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 238
Simple power management
policies
• Request-driven: power up once request is
received. Adds delay to response.
• Predictive shutdown: try to predict how
long you have before next request.
• May start up in advance of request in
anticipation of a new request.
• If you predict wrong, you will incur additional
delay while starting up.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 239
Probabilistic shutdown
• Assume service requests are probabilistic.
• Optimize expected values:
• power consumption;
• response time.
• Simple probabilistic: shut down after time
Ton, turn back on after waiting for Toff.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 240
Advanced Configuration and
Power Interface
• ACPI: open standard for power
management services.

applications
power
OS kernel management
device
drivers
ACPI BIOS

Hardware platform
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 241
ACPI global power states
• G3: mechanical off
• G2: soft off
• S1: low wake-up latency with no loss of context
• S2: low latency with loss of CPU/cache state
• S3: low latency with loss of all state except memory
• S4: lowest-power state with all devices off
• G1: sleeping state
• G0: working state

Overheads for Computers as

• Compress audio using adaptive differential

pulse code modulation (ADPCM).

analog

time
ADPCM 3 2 1 -1 -2 -3

time
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 244
ADPCM coding
• Coded in a small alphabet with positive
and negative values.
• {-3,-2,-1,1,2,3}
• Minimize error between predicted value
and actual signal value.

Overheads for Computers as

S quantizer

inverse
integrator
quantizer
encoder
samples

inverse
integrator
quantizer
decoder
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 246
Telephone system terms
• Subscriber line: line to phone.
• Central office: telephone switching
system.
• Off-hook: phone active.
• On-hook: phone inactive.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 247
Real and simulated subscriber
line
• Real subscriber line:
• 90V RMS ringing signal;
• companded analog signals;
• lightning protection, etc.
• Simulated subscriber line:
• microphone input;
• speaker output;
• switches for ring, off-hook, etc.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 248
Requirements
Inputs Telephone: voice samples, ring.
User interface: microphone, play
messages button, record OGM button.
Outputs Telephone: voice samples, on-
hook/off-hook command.
User interface: speaker, # messages
indicator, message light.
Functions Default mode: detects ring, signals off-
hook, pays OGM, records ICM
Playback: play all messages, wait 5
seconds for new playback.
OGM editing: OGM up to 10 sec.
Performance About 30 minutes voice (@ 8kHz).
Manufacturing cost Consumer product range ($50)
Power AC plug
Physical Comparable to desk phone.
size/weight
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 249
Comments on analysis
• DRAM requirement influenced by DRAM
price.
• Details of user interface protocol could be
tested on a PC-based prototype.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 250
Answering machine class
diagram
1
1 1
Microphone* 1
Controls Record *
Outgoing-
1 1 1
Line-in*
1 1 1 * message
1 *
1 1
Playback Incoming-
Line-out* * message
1 1

1 Lights
Buttons*

1
Speaker*

Overheads for Computers as

Microphone* Line-in* Line-out*

sample() sample()
sample()
ring-indicator() pick-up()

Buttons* Lights* Speaker*

record-OGM messages
play num-messages
sample()

Overheads for Computers as

Message
length
start-adrs
next-msg
samples

Incoming-message Outgoing-message

msg-time length=30 sec

Overheads for Computers as

Controls Record Playback

operate() record-msg() playback-msg()

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 254
Software components
• Front panel module.
• Speaker module.
• Telephone line module.
• Telephone input and output modules.
• Compression module.
• Decompression module.

Overheads for Computers as

Compute buttons, line activations

Activations?

Play OGM Record OGM Play ICM Erase Answer

Play OGM
Wait for timeout
Allocate ICM
Erase
Record ICM
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 256
Record-msg/playback-msg
behaviors

nextadrs = 0 nextadrs = 0

msg.samples[nextadrs] = speaker.samples() =
sample(source) msg.samples[nextadrs];
nextadrs++
F F
End(source) nextadrs=msg.length
T T

record-msg playback-msg
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 257
Hardware platform
• CPU.
• Memory.
• Front panel.
• 2 A/Ds:
• subscriber line, microphone.
• 2 D/A:
• subscriber line, speaker.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 258
Component design and testing
• Must test performance as well as testing.
• Compression time shouldn’t dominate other
tasks.
• Test for error conditions:
• memory overflow;
• try to delete empty message set, etc.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 259
System integration and testing
• Can test partial integration on host
platform; full testing requires integration
on target platform.
• Simulate phone line for tests:
• it’s legal;
• easier to produce test conditions.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 260
Multiprocessors
• Why multiprocessors?
• CPUs and accelerators.
• Multiprocessor performance analysis.

Overheads for Computers as

• Better cost/performance.
• Match each CPU to its tasks or use custom
logic (smaller, cheaper).
• CPU cost is a non-linear function of
performance.

cost

performance
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 262
Why multiprocessors? cont’d.
• Better real-time performance.
• Put time-critical functions on less-loaded
processing elements.
• Remember RMS utilization---extra CPU cycles
must be reserved to meet deadlines.

cost
deadline w.
deadline RMS overhead

performance
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 263
Why multiprocessors? cont’d.

• Using specialized
processors or custom
logic saves power.
• Desktop
uniprocessors are not
power-efficient [Aus04] © 2004 IEEE Computer Society

enough for battery-

powered applications.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 264
Why multiprocessors? cont’d.
• Good for processing I/O in real-time.
• May consume less energy.
• May be better at streaming data.
• May not be able to do all the work on
even the largest single CPU.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 265
Accelerated systems
• Use additional computational unit
dedicated to some functions?
• Hardwired logic.
• Extra CPU.
• Hardware/software co-design: joint design
of hardware and software architectures.

Overheads for Computers as

request accelerator
result
data
data
CPU
memory

I/O

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 267
Accelerator vs. co-processor
• A co-processor executes instructions.
• Instructions are dispatched by the CPU.
• An accelerator appears as a device on the
bus.
• The accelerator is controlled by registers.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 268
Accelerator implementations
• Application-specific integrated circuit.
• Field-programmable gate array (FPGA).
• Standard component.
• Example: graphics processor.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 269
System design tasks
• Design a heterogeneous multiprocessor
architecture.
• Processing element (PE): CPU, accelerator,
etc.
• Program the system.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 270
Accelerated system design
• First, determine that the system really
needs to be accelerated.
• How much faster is the accelerator on the
core function?
• How much data transfer overhead?
• Design the accelerator itself.
• Design CPU interface to accelerator.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 271
Accelerated system platforms
• Several off-the-shelf boards are available
for acceleration in PCs:
• FPGA-based core;
• PC bus interface.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 272
Accelerator/CPU interface
• Accelerator registers provide control
registers for CPU.
• Data registers can be used for small data
objects.
• Accelerator may include special-purpose
read/write logic.
• Especially valuable for large data transfers.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 273
System integration and
debugging
• Try to debug the CPU/accelerator
interface separately from the accelerator
core.
• Build scaffolding to test the accelerator.
• Hardware/software co-simulation can be
useful.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 274
Caching problems
• Main memory provides the primary data
transfer mechanism to the accelerator.
• Programs must ensure that caching does
not invalidate main memory data.
• CPU reads location S.
• Accelerator writes location S.
• CPU writes location S. BAD

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 275
Synchronization
• As with cache, main memory writes to
shared memory may cause invalidation:
• CPU reads S.
• Accelerator writes S.
• CPU reads S.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 276
Multiprocessor performance
analysis
• Effects of parallelism (and lack of it):
• Processes.
• CPU and bus.
• Multiple processors.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 277
Accelerator speedup
• Critical parameter is speedup: how much
faster is the system with the accelerator?
• Must take into account:
• Accelerator execution time.
• Data transfer time.
• Synchronization with the master CPU.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 278
Accelerator execution time
• Total accelerator execution time:
• taccel = tin + tx + tout

Data input Data output

Accelerated
computation

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 279
Accelerator speedup
• Assume loop is executed n times.
• Compare accelerated system to non-
accelerated system:
• S = n(tCPU - taccel)
• = n[tCPU - (tin + tx + tout)]

Execution time on CPU

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 280
Single- vs. multi-threaded
• One critical factor is available parallelism:
• single-threaded/blocking: CPU waits for accelerator;
• multithreaded/non-blocking: CPU continues to
execute along with accelerator.
• To multithread, CPU must have useful work to
do.
• But software must also support multithreading.

Overheads for Computers as

• Single-threaded: • Multi-threaded:
P1
P1

P2 A1 P2 A1

P3
P3

P4
P4
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 282
Execution time analysis

• Single-threaded: • Multi-threaded:
• Count execution time • Find longest path
of all component through execution.
processes.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 283
Sources of parallelism
• Overlap I/O and accelerator computation.
• Perform operations in batches, read in second
batch of data while computing on first batch.
• Find other work to do on the CPU.
• May reschedule operations to move work
after accelerator initiation.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 284
Data input/output times
• Bus transactions include:
• flushing register/cache values to main
memory;
• time required for CPU to set up transaction;
• overhead of data transfers by bus packets,
handshaking, etc.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 285
Scheduling and allocation
• Must:
• schedule operations in time;
• allocate computations to processing
elements.
• Scheduling and allocation interact, but
separating them helps.
• Alternatively allocate, then schedule.

Overheads for Computers as

P1 P2

M1 M2
d1 d2

Task graph Hardware platform

Overheads for Computers as

• Allocate P1, P2 -> M1; P3 -> M2.

M1 P1 P1C P2 P2C

M2 P3

time

Overheads for Computers as

• Allocate P1 -> M1; P2, P3 -> M2:

M1 P1 P1C

M2 P2 P3

time

Overheads for Computers as

• Task graph: • Network:

execution time
3 3 allocation
P1 P2
M1 M2 M3

d1 d2
P3
4

Transmission time = 4
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 290
Initial schedule

M1 P1

M2 P2

M3 P3

network d1 d2
Time = 15

0 5 10 15 20 time
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 291
New design
• Modify P3:
• reads one packet of d1, one packet of d2
• computes partial result
• continues to next packet

Overheads for Computers as

M1 P1

M2 P2

M3
P3 P3 P3 P3
network d1d2d1d2d1d2d1d2
Time = 12

0 5 10 15 20 time
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 293
Buffering and performance
• Buffering may sequentialize operations.
• Next process must wait for data to enter
buffer before it can continue.
• Buffer policy (queue, RAM) affects
available parallelism.

Overheads for Computers as

• Three processes
separated by buffers:

B1 A B2 B B3 C

Overheads for Computers as

A[0] A[0]
A[1] B[0]
… C[0]
Must wait for
B[0] all of A before A[1]
B[1] getting any B B[1]
… C[1]
C[0] …
C[1]
… Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 296
Multiprocessors
• Consumer electronics systems.
• Cell phones.
• CDs and DVDs.
• Audio players.
• Digital still cameras.

Overheads for Computers as

• Multimedia: stored in
compressed form,
uncompressed on
viewing.
• Data storage and
management: keep track
of your multimedia, etc.
• Communication:
download, upload, chat.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 298
Non-functional requirements
for CE
• Often battery-operated, strict power
budget.,
• Very inexpensive.
• User interface must be capable but
inexpensive.

Overheads for Computers as

• Many devices talk to host

system.
• PC host does things that
are hard to do on the
device.
• Increasingly, CE
devices communicate
directly over the
network, avoiding the
host for access.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 300
Platforms and operating
systems

• Many CE devices use

a DSP for signal
processing and a
RISC CPU for other
tasks.
• I/O devices include
buttons, screen, USB.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 301
Flash file systems
• Flash is widely used for mass storage.
• Flash wears out on writing (up to 1 million
cycles).
• Directory is most often written, wears out
first.
• Flash file system has layer that moves
contents to levelize wear.
• Hides wear leveling from API.

Overheads for Computers as

• Most popular CE
device in history;
most widely used
computing device.
• 1 billion sold per year.
• Handset talks to cell.
• Cells hand off
handset as it moves.

Overheads for Computers as

• Today’s cell phones use analog

front end, digital baseband
processing.
• Future cell phones will
perform IF processing with
DSP.
• Baseband processing in DSP:
• Voice compression.
• Network protocol.
• Other processing:
• Multimedia functions.
• User interface.
• File system.
• Applications (contacts, etc.)
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 304
CD/MP3 player

Audio
CPU
memory
Jog
memory
Error Analog
display focus, drive
corrector out
tracking,
sled,
amp DAC Servo Analog head
motor
CPU in
I2S FE, TE, amp
memory
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 305
CD medium
• Rotational speed: 1.2-1.4 m/s (CLV).
• Track pitch: 1.6 microns.
• Diameter: 120 mm.
• Pit length: 0.8 -3 microns.
• Pit depth: .11 microns.
• Pit width: 0.5 microns.
• Laser wavelength: 780 nm.

Overheads for Computers as

• Laser, lens, sled:

CD
focus

track
detectors
diffraction
sled grating
laser

track
Overheads for Computers as 307
© 2008 Wayne Wolf Components 2nd ed.
Laser focus

• Focus controlled by vertical position of

lens.
• Unfocused beam causes irregular spot:

Out of focus In focus Out of focus

Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 308
Laser pickup

Side spot
detectors F
A

Level:
D B A+B+C+D
Focus error:
C (A+C)-(B+D)
E Tracking error:
E-F

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 309
Servo control
• Four main signals:
• focus (laser) @ 245 kHz;
• tracking (laser) @ 245 kHz;
Optical pickup
• sled (motor): @ 800 Hz;
• Disc motor.

Overheads for Computers as

• Eight-to-fourteen modulation:
• Fourteen-bit code guarantees a maximum
distance between transitions.

00000011 00100100000000

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 311
Error correction
• CD capacity: 6.99 GB raw, 700 MB formatted.
• Reed-Solomon code:
• g(x) = (x-a) (x- a2) … (x- an-k-1) (x- an-k)
• Produces data, erasure bits.
• Time to solve varies greatly depending on noise.
• CD interleaves Reed-Solomon blocks to reduce
effects of large data gaps.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 312
Control and error correction
• Skips caused by physical disturbance.
• Wait for disturbance to subside.
• Retry.
• Read errors caused by disc/servo problems.
• Detect error.
• Choose location for retry.
• Retry.
• Fail and interpolate.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 313
MPEG audio standards
• Layer 1:
• Lossless compression of subbands + optional
simple masking model
• Layer 2:
• More advanced masking model.
• Layer 3:
• Additional processing for lower bit rates.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 314
MPEG audio rates
• Input sampling rates:
• 32, 44.1, 48 kHz.
• Output bit rates:
• 23, 48, 64, 96, 112, 128, 192, 256, 384
kbits/sec.
• Output can be mono, dual-channel
(bilingual, etc.), stereo.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 315
Other standards
• Dolby Digital (AC-3):
• Uses modified discrete cosine transform.
• ATRAC (MiniDisc):
• Uses subband + modified DCT.
• MPEG-2 AAC.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 316
MPEG Layer 1
• 384 samples/block at all frequencies.
• Equals 8 ms at 48 kHz.
• Optional masking model.
• Driven by separate FFT for better accuracy.

Overheads for Computers as

• Bit allocation codes specify word length in

each subband.
• Scale factors give gain for each band.

bit scale aux

header CRC subband samples
allocation factors data

Overheads for Computers as

Choose
Scale factor
mux
Filter
bank * requantize
0101..
Masking
FFT model

Overheads for Computers as

Scale
factor
demux inverse
quantize Inverse
0101.. * * filter
bank
expand
Step
size

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 320
MP3
• Decoding is easier than encoding, but
requires:
• decompression;
• filtering.
• Basic CD standard for data discs.
• No standards for MP3 disc file structure:
player must understand Windows, Mac,
Unix discs.

Overheads for Computers as

• Audio players may use

flash, hard disk, or CD for
mass storage.
• Decompression requires
small amount of CPU:
• 10% of ARM7.
• File system must be
compatible (FAT).

Overheads for Computers as

• DSC must determine

exposure before
taking picture.
• After taking picture:
• Improve image
quality.
• Compress.
• Save as file.

Overheads for Computers as

• DSC uses CPU for

general-purpose
processing, DSP for
image processing.
• Internal memory buffers
the passes on the image.
• Display is lower
resolution than image
sensor.
• Image must be
downsampled.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 324
Image capture

• Before taking picture:

• Determine exposure.
• Determine focus.
• Optimize white
balance.

Bayer pattern

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 325
Image processing
• Must perform basic processing to get
usable picture:
• Bayer->RGB interpolation.
• DSCs perform many functions formerly
performed by photoprocessors for film:
• Image sharpening.
• Color balance.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 326
File management
• EXIF standard gives format for digital
pictures:
• Format of data in a file.
• Directory structure.
• EXIF file includes:
• Image (JPEG, etc.)
• Thumbnail.
• Metadata (camera type, date/time, etc.)

Overheads for Computers as

• Build accelerator for block motion

estimation, one step in video
compression.
• Perform two-dimensional correlation:
f2
f2f2
f2f2f2f2f2f2f2
Frame 1

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 329
Block motion estimation
• MPEG divides frame into 16 x 16
macroblocks for motion estimation.
• Search for best match within a search
range.
• Measure similarity with sum-of-absolute-
differences (SAD):
• S | M(i,j) - S(i-ox, j-oy) |

Overheads for Computers as

• Best match produces motion vector for

motion block:

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 331
Full search algorithm
bestx = 0; besty = 0;
bestsad = MAXSAD;
for (ox = - SEARCHSIZE; ox < SEARCHSIZE; ox++) {
for (oy = -SEARCHSIZE; oy < SEARCHSIZE; oy++) {
int result = 0;
for (i=0; i<MBSIZE; i++) {
for (j=0; j<MBSIZE; j++) {
result += iabs(mb[i][j] - search[i-
ox+XCENTER][j-oy-YCENTER]);

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 332
Full search algorithm, cont’d.
}
}
if (result <= bestsad) { bestsad = result; bestx =
ox; besty = oy; }
}
}

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 333
Computational requirements
• Let MBSIZE = 16, SEARCHSIZE = 8.
• Search area is 8 + 8 + 1 in each
dimension.
• Must perform:
• nops = (16 x 16) x (17 x 17) = 73984 ops
• CIF format has 352 x 288 pixels -> 22 x
18 macroblocks.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 334
Accelerator requirements
name block motion estimator
purpose block motion est. in PC
inputs macroblocks, search areas
outputs motion vectors
functions compute motion vectors with
full search
performance as fast as possible
manufacturing cost hundreds of dollars
power from PC power supply
physical size/weight PCI card

Overheads for Computers as

Motion-vector Macroblock Search-area

x, y : pos pixels[] : pixelval pixels[] : pixelval

PC Motion-estimator
memory[]
compute-mv()

Overheads for Computers as

:PC :Motion-estimator

compute-mv()
Search area memory[]

memory[]

macroblocks memory[]

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 337
Architectural considerations
• Requires large amount of memory:
• macroblock has 256 pixels;
• search area has 1,089 pixels.
• May need external memory (especially if
buffering multiple macroblocks/search
areas).

Overheads for Computers as

search area
PE 0

network
PE 1
generator

comparator
Address

ctrl ...
Motion
vector
macroblock

network

PE 0 PE 1 PE 2

|M(0,0)-S(0,0)|

M(0,0)
|M(0,1)-S(0,1)| |M(0,0)-S(0,1)|

|M(0,2)-S(0,2)| |M(0,1)-S(0,2)| |M(0,0)-S(0,2)|

S(0,2)

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 340
System testing
• Testing requires a large amount of data.
• Use simple patterns with obvious answers
for initial tests.
• Extract sample data from JPEG pictures
for more realistic tests.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 341
Networking for Embedded
Systems
• Why we use networks.
• Network abstractions.
• Example networks.

Overheads for Computers as

distributed computing platform:

PE
PE

communication link
network

PE
PEs may be CPUs or ASICs.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 343
Networks in embedded
systems

initial processing
more processing
PE sensor
PE

PE actuator

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 344
Why distributed?
• Higher performance at lower cost.
• Physically distributed activities---time
constants may not allow transmission to
central site.
• Improved debugging---use one CPU in
network to debug others.
• May buy subsystems that have embedded
processors.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 345
Network abstractions
• International Standards Organization
(ISO) developed the Open Systems
Interconnection (OSI) model to describe
networks:
• 7-layer model.
• Provides a standard way to classify
network components and operations.

Overheads for Computers as

application end-use interface

presentation data format
session application dialog control
transport connections
network end-to-end service
data link reliable data transport
physical mechanical, electrical

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 347
OSI layers
• Physical: connectors, bit formats, etc.
• Data link: error detection and control
across a single link (single hop).
• Network: end-to-end multi-hop data
communication.
• Transport: provides connections; may
optimize network resources.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 348
OSI layers, cont’d.
• Session: services for end-user
applications: data grouping,
checkpointing, etc.
• Presentation: data formats,
transformation services.
• Application: interface between network
and end-user programs.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 349
Hardware architectures
• Many different types of networks:
• topology;
• scheduling of communication;
• routing.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 350
Point-to-point networks
• One source, one or more destinations, no
data switching (serial port):

PE 1 PE 2 PE 3
link 1 link 2

Overheads for Computers as

PE 1 PE 2 PE 3 PE 4

header address data ECC packet format

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 352
Bus arbitration
• Fixed: Same order of resolution every
time.
• Fair: every PE has same access over long
periods.
• round-robin: rotate top priority among Pes.

fixed A B C A B C
round-robin
A B C B C A
A,B,C A,B,C
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 353
Crossbar

out4

out3

out2

out1
in1 in2 in3 in4
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 354
Crossbar characteristics
• Non-blocking.
• Can handle arbitrary multi-cast
combinations.
• Size proportional to n2.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 355
Multi-stage networks
• Use several stages of switching elements.
• Often blocking.
• Often smaller than crossbar.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 356
Message-based programming
• Transport layer provides message-based
programming interface:
send_msg(adrs,data1);
• Data must be broken into packets at
source, reassembled at destination.
• Data-push programming: make things
happen in network based on data
transfers.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 357
I2C bus
• Designed for low-cost, medium data rate
applications.
• Characteristics:
• serial;
• multiple-master;
• fixed-priority arbitration.
• Several microcontrollers come with built-in
I2C controllers.

Overheads for Computers as

master 1 master 2
data line
SDL
clock line
SCL

slave 1 slave 2

Overheads for Computers as

SCL ... ...

SDL ...

start MSB ack

Overheads for Computers as

• Open collector interface: +

SDL
+

SCL

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 361
I2C signaling
• Sender pulls down bus for 0.
• Sender listens to bus---if it tried to send a
1 and heard a 0, someone else is
simultaneously transmitting.
• Transmissions occur in 8-bit bytes.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 362
I2C data link layer
• Every device has an address (7 bits in
standard, 10 bits in extension).
• Bit 8 of address signals read or write.
• General call address allows broadcast.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 363
I2C bus arbitration
• Sender listens while sending address.
• When sender hears a conflict, if its
address is higher, it stops signaling.
• Low-priority senders relinquish control
early enough in clock cycle to allow bit to
be transmitted reliably.

Overheads for Computers as

multi-byte write

S adrs 0 data data P

read from slave

S adrs 1 data P

write, then read

S adrs 0 data S adrs 1 data P

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 365
Ethernet
• Dominant non-telephone LAN.
• Versions: 10 Mb/s, 100 Mb/s, 1 Gb/s
• Goal: reliable communication over an
unreliable medium.

Overheads for Computers as

A B C

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 367
CSMA/CD
• Carrier sense multiple access with collision
detection:
• sense collisions;
• exponentially back off in time;
• retransmit.

Overheads for Computers as

start source dest data

preamble length padding CRC
frame adrs adrs payload

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 370
Ethernet performance
• Quality-of-service tends to non-linearly
decrease at high load levels.
• Can’t guarantee real-time deadlines.
However, may provide very good service
at proper load levels.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 371
Fieldbus
• Used for industrial control and
instrumentation---factories, etc.
• H1 standard based on 31.25 MB/s twisted
pair medium.
• High Speed Ethernet (HSE) standard
based on 100 Mb/s Ethernet.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 372
Networks
• Network-based design.
• Communication analysis.
• System performance analysis.
• Internet.
• Internet-enabled systems.
• Vehicles as networks.
• Sensor networks

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 373
Communication analysis
• First, understand delay for single
message.
• Delay for multiple messages depends on:
• network protocol;
• devices on network.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 374
Message delay
• Assume:
• single message;
• no contention.
• Delay:
• tm = tx + tn + tr
• = xmtr overhead + network xmit time +
rcvr overhead

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 375
Example: I2C message delay
• Network transmission time dominates.
• Assume 100 kbits/sec, one 8-bit byte.
• Number of bits in packet:
• npacket = start + address + data + stop
• = 1 + 8 + 8 + 1 = 18 bits
• Time required to transmit: 1.8 x 10-4 sec.
• 20 instructions on 8 MHz controller adds 2.5 x
10-6 delay on xmtr, rcvr.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 376
Multiple messages
• If messages can interfere with each other,
analysis is more complex.
• Model total message delay:
• ty = td + tm
• = wait time for network + message delay

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 377
Arbitration and delay
• Fixed-priority arbitration introduces
unbounded delay for all but highest-
priority device.
• Unless higher-priority devices are known to
have limited rates that allow lower devices to
transmit.
• Round-robin arbitration introduces
bounded delay proportional to N.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 379
Priority inversion in networks
• In many networks, a packet cannot be
interrupted.
• Result is priority inversion:
• low-priority message holds up higher-priority
message.
• Doesn’t cause deadlock, but can slow
down important communications.

Overheads for Computers as

• In multihop networks, one node receives

message, then retransmits to destination
(or intermediate).
hop 1 hop 2

A B C
Network 1 Network 2

Overheads for Computers as

• System analysis is difficult in general.

• multiprocessor performance analysis is hard;
• communication performance analysis is hard.
• Simple example: uncertainty in P1 finish
time -> uncertainty in P2 start time.

P1 P2

Overheads for Computers as

• P2 and P3 can delay

P1
each other, even
though they are in
separate tasks. P2
• Delays in P1 P3
propagate to P2, then
P3, then to P4.
P4

Overheads for Computers as

• Computational • Communication
requirements: requirements:
• sum up process • Count all
requirements over transmissions in one
least-common multiple period.
of periods, average
over one period.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 384
Hardware platform design
• Need to choose:
• number and types of PEs;
• number and types of networks.
• Evaluate a platform by allocating
processes, scheduling processes and
communication.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 385
I/O-intensive systems
• Start with I/O devices, then consider
computation:
• inventory required devices;
• identify critical deadlines;
• chooses devices that can share PEs;
• analyze communication times;
• choose PEs to go with devices.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 386
Computation-intensive systems
• Start with shortest-deadline tasks:
• Put shortest-deadline tasks on separate PEs.
• Check for interference on critical
communications.
• Allocate low-priority tasks to common PEs
wherever possible.
• Balance loads wherever possible.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 387
Internet Protocol
• Internet Protocol (IP) is basis for Internet.
• Provides an internetworking standard:
between two Ethernets, Ethernet and
token ring, etc.
• Higher-level services are built on top of
IP.

Overheads for Computers as

application application
presentation presentation
session session
transport IP transport
network network network
data link data link data link
physical physical physical

node A router node B

Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 389
IP packet
• Includes:
• version, service type, length
• time to live, protocol
• source and destination address
• data payload
• Maximum data payload is 65,535 bytes.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 390
IP addresses
• 32 bits in early IP, 128 bits in IPv6.
• Typically written in form xxx.xx.xx.xx.
• Names (foo.baz.com) translated to IP
address by domain name server (DNS).

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 391
Internet routing
• Best effort routing:
• doesn’t guarantee data delivery at IP layer.
• Routing can vary:
• session to session;
• packet to packet.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 392
Higher-level Internet services
• Transmission Control Protocol (TCP)
provides connection-oriented service.
• Quality-of-service (QoS) guaranteed
services are under development.

Overheads for Computers as

FTP HTTP SMTP telnet SNMP

User
TCP UDP Datagram
Protocol
IP

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 394
Internet-enabled embedded
system
• Internet-enabled embedded system: any
embedded system that includes an Internet
interface (e.g., refrigerator).
• Internet appliance: embedded system designed
for a particular Internet task (e.g. email).
• Examples:
• Cell phone.
• Laser printer.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 395
Example: Javacam
• Hardware platform:
• parallel-port camera;
• National Semi NS486SXF;
• 1.5 Mbytes memory.
• Uses memory-efficient Java Nanokernel.

Overheads for Computers as

QuickCam Web browser

applet

Quickcam HTTP
server QuickCam
Java VM

Java nanokernel

486

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 397
Vehicles as networks
• 1/3 of cost of car/airplane is
electronics/avionics.
• Dozens of microprocessors are used throughout
the vehicle.
• Network applications:
• Vehicle control.
• Instrumentation.
• Communication.
• Passenger entertainment systems.

Overheads for Computers as

• First used in 1991.

• Serial bus, 1 Mb/sec up
to 40 m.
• Synchronous bus.
• Logic 0 dominates logic 1
on bus.
• Arbitrated with
CSMA/AMP:
• Arbitration on message
priority.

Overheads for Computers as

• 11 bit destination
address.
• RTR bit determines
read/write from/to
destination.
• Any node can detect
bus error, interrupt
packet for
retransmission.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 400
CAN controller

• Controller implements
physical and data link
layers.
• No network layer
needed---bus
provides end-to-end
connections.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 401
Other vehicle busses
• FlexRay is next generation:
• Time triggered protocol.
• 10 Mb/s.
• Local Interconnect Network (LIN) connects
devices in a small area (e.g., door).
• Passenger entertainment networks:
• Bluetooth.
• Media Oriented Systems Transport (MOST).

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 402
Avionics
• Anything permanently attached to the aircraft
must be certified by FAA/national agency.
• Traditional architecture uses separate
electronics for each instrument/device.
• Line replaceable unit (LRU) can be physically
removed and replaced.
• Federated architecture shares processors across
a subsystem (nav/comm, etc.)

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 403
Sensor networks
• Wireless networks, small nodes.
• Ad hoc networks---organizes itself without
system administrator:
• Must be able to declare membership in
network, find other networks.
• Must be able to determine routes for data.
• Must update configuration as nodes
enter/leave.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 404
Node capabilities
• Must be able to turn radio on/off quickly
with low power overhead.
• Communication/computation power = 100x.
• Radios should operate at several different
power levels to avoid interference with
other nodes.
• Must buffer, route network traffic.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 406
Terminology
• Elevator car: holds passengers.
• Hoistway: elevator shaft.
• Car control panel: buttons in each car.
• Floor control panel: elevator request, etc.
per floor.

Overheads for Computers as

floor

Hoistway 1 Hoistway 2
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 408
Theory of operation
• Each floor has control panel, display.
• Each car has control panel:
• one button per floor;
• emergency stop.
• Controlled by a single controller.

Overheads for Computers as

sensor

fine

coarse

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 410
Elevator control
• Elevator control has up and down.
• To stop, disable both.
• Master controller:
• reads elevator positions;
• reads requests;
• schedules elevators;
• controls movement;
• controls doors.

Overheads for Computers as

name elevator system

inputs F floor control, N position, N car
control, 1 master
outputs F displays, N motor controllers
functions responds to requests, operates
safely
performance elevator control is time-critical
manufacturing cost electronics is small part of total
power electronics consumes small
fraction of total
physical size/weight cabling is important

Overheads for Computers as

1
Coarse-sensor*
Master-control-panel*
1 1
1 N 1
Fine-sensor* Car 1
1 1
1
1 Controller
Car-control-panel* 1
1
1 Floor F N
Floor-control-panel* 1 Motor*

Overheads for Computers as

Sensor* Car-control-panel*
hit: boolean Floors[1..F]: boolean
emergency-stop:
boolean
open-door, close-door:
Coarse-sensor* Fine-sensor* boolean

Master-control-panel...
Motor* Floor-control-panel*
speed: {o,s,f} up, down: boolean
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 414
Car and Floor classes

Car Floor
request-lights[1..F]:
up-light, down-light:
boolean
boolean
current-floor: integer

Overheads for Computers as

Controller
car-floor[1..H]: integer
emergency-stop[1..H]:
integer
scan-cars()
scan-floors()
scan-master-panel()
operate()

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 416
Architecture
• Computation and I/O occur at:
• floor control panels/displays;
• elevator cars;
• system controller.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 417
Panels and cab controller
• Panels are straightforward---no real-time
requirements.
• Cab controller:
• read buttons and send events to system
controller;
• read sensor inputs and send to system
controller.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 418
System controller
• Must take inputs from many sources:
• car controllers;
• floors.
• Must control cars to hard real-time
deadlines.
• User interface, scheduling are soft
deadlines.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 419
Testing
• Build an elevator simulator using an
FPGA:
• simulate multiple elevators;
• simulate real-time control demands.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 420
System design techniques
• Design methodologies.
• Requirements and specification.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 421
Design methodologies
• Process for creating a system.
• Many systems are complex:
• large specifications;
• multiple designers;
• interface to manufacturing.
• Proper processes improve:
• quality;
• cost of design and manufacture.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 422
Product metrics
• Time-to-market:
• beat competitors to market;
• meet marketing window (back-to-school).
• Design cost.
• Manufacturing cost.
• Quality.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 423
Mars Climate Observer
• Lost on Mars in September 1999.
• Requirements problem:
• Requirements did not specify units.
• Lockheed Martin used English; JPL wanted
metric.
• Not caught by manual inspections.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 424
Design flow
• Design flow: sequence of steps in a
design methodology.
• May be partially or fully automated.
• Use tools to transform, verify design.
• Design flow is one component of
methodology. Methodology also includes
management organization, etc.

Overheads for Computers as

• Early model for software development:

requirements

architecture
coding

testing

maintenance
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 426
Waterfall model steps
• Requirements: determine basic
characteristics.
• Architecture: decompose into basic
modules.
• Coding: implement and integrate.
• Testing: exercise and uncover bugs.
• Maintenance: deploy, fix bugs, upgrade.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 427
Waterfall model critique
• Only local feedback---may need iterations
between coding and requirements, for
example.
• Doesn’t integrate top-down and bottom-
up design.
• Assumes hardware is given.

Overheads for Computers as

system feasibility

specification

prototype

initial system

enhanced system
requirements
design
test

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 429
Spiral model critique
• Successive refinement of system.
• Start with mock-ups, move through simple
systems to full-scale systems.
• Provides bottom-up feedback from
previous stages.
• Working through stages may take too
much time.

Overheads for Computers as

specify specify

architect architect

design design
build build
test test

initial system refined system

Overheads for Computers as

requirements and
specification

architecture

hardware design software design

integration

testing
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 432
Co-design methodology
• Must architect hardware and software
together:
• provide sufficient resources;
• avoid software bottlenecks.
• Can build pieces somewhat
independently, but integration is major
step.
• Also requires bottom-up feedback.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 433
Hierarchical design flow
• Embedded systems must be designed
across multiple levels of abstraction:
• system architecture;
• hardware and software systems;
• hardware and software components.
• Often need design flows within design
flows.

Overheads for Computers as

spec spec
spec
architecture HWSW
architecture
architecture

HW SW detailed
detailed
design
design

integrate integration
integration

test testtest

system hardware
software
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 435
Concurrent engineering
• Large projects use many people from
multiple disciplines.
• Work on several tasks at once to reduce
design time.
• Feedback between tasks helps improve
quality, reduce number of later design
problems.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 436
Concurrent engineering
techniques
• Cross-functional teams.
• Concurrent product realization.
• Incremental information sharing.
• Integrated product management.
• Supplier involvement.
• Customer focus.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 437
AT&T PBX concurrent
engineering
• Benchmark against competitors.
• Identify breakthrough improvements.
• Characterize current process.
• Create new process.
• Verify new process.
• Implement.
• Measure and improve.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 438
Requirements analysis
• Requirements: informal description of
what customer wants.
• Specification: precise description of what
design team should deliver.
• Requirements phase links customers with
designers.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 439
Types of requirements
• Functional: input/output relationships.
• Non-functional:
• timing;
• power consumption;
• manufacturing cost;
• physical size;
• time-to-market;
• reliability.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 440
Good requirements
• Correct.
• Unambiguous.
• Complete.
• Verifiable: is each requirement satisfied in
the final system?
• Consistent: requirements do not
contradict each other.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 441
Good requirements, cont’d.
• Modifiable: can update requirements
easily.
• Traceable:
• know why each requirement exists;
• go from source documents to requirements;
• go from requirement to implementation;
• back from implementation to requirement.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 442
Setting requirements
• Customer interviews.
• Comparison with competitors.
• Sales feedback.
• Mock-ups, prototypes.
• Next-bench syndrome (HP): design a
product for someone like you.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 443
Specifications
• Capture functional and non-functional
properties:
• verify correctness of spec;
• compare spec to implementation.
• Many specification styles:
• control-oriented vs. data-oriented;
• textual vs. graphical.
• UML is one specification/design language.

Overheads for Computers as

• Used in telephone
on-hook
telecommunications
protocol design. caller goes
• Event-oriented state off-hook
machine model.
dial tone

caller gets
dial tone

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 445
Statecharts
• Ancestor of UML state diagrams.
• Provided composite states:
• OR states;
• AND states.
• Composite states reduce the size of the
state transition graph.

Overheads for Computers as

S3 S3

traditional OR state
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 447
Statechart AND state
sab
c
S1-3 S1-4 S1 S3
d
b a b a b a c d
c
S2-3 S2-4 S2 S4
d r
r r
S5
S5
traditional AND state
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 448
AND-OR tables
• Alternate way of specifying complex
conditions:
cond1 or (cond2 and !cond3)

cond1 T
OR -
cond2 - T
AND cond3 - F

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 449
TCAS II specification
• TCAS II: aircraft collision avoidance
system.
• Monitors aircraft and air traffic info.
• Provides audio warnings and directives to
avoid collisions.
• Leveson et al used RMSL language to
capture the TCAS specification.

Overheads for Computers as

• State description: • Transition bus for

transitions between
state1 many states:
inputs
a

state description b

power-on power-off
Inputs:
TCAS-operational-status {operational,not-operational}
fully-operational
own-aircraft C

other-aircraft i:[1..30]
standby
mode-s-ground-station i:[1..15]

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 452
Own-Aircraft AND state
CAS
Inputs:
own-alt-radio: integer standby-discrete-input: {true,false}
own-alt-barometric:integer, etc.

Effective-SL Alt-SL Alt-layer Climb-inibit Descend-inibit

... ...
1 1 ...
Increase-climb-inibit
2 2
... Increase-Descend-inibit ...
... ...
7 7 Advisory-Status ...

Outputs:
sound-aural-alarm: {true,false} aural-alarm-inhibit: {true, false}
combined-control-out: enumerated, etc.
Overheads for Computers as
© 2008 Wayne Wolf Components 2nd ed. 453
CRC cards
• Well-known method for analyzing a
system and developing an architecture.
• CRC:
• classes;
• responsibilities of each class;
• collaborators are other classes that work with
a class.
• Team-oriented methodology.

Overheads for Computers as

Class name: Class name:

Superclasses: Class’s function:
Subclasses: Attributes:
Responsibilities: Collaborators:

front back

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 455
CRC methodology
• Develop an initial list of classes.
• Simple description is OK.
• Team members should discuss their choices.
• Write initial responsibilities/collaborators.
• Helps to define the classes.
• Create some usage scenarios.
• Major uses of system and classes.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 456
CRC methodology, cont’d.
• Walk through scenarios.
• See what works and doesn’t work.
• Refine the classes, responsibilities, and
collaborators.
• Add class relatoinships:
• superclass, subclass.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 457
CRC cards for elevator
• Real-world classes:
• elevator car, passenger, floor control, car
control, car sensor.
• Architectural classes: car state, floor
control reader, car control reader, car
control sender, scheduler.

Overheads for Computers as

class responsibilities collaborators

Elevator car* Move up and down Car control, car

sensor, car control
sender
Car control* Transmits car Passenger, floor
requests control reader
Car state Reads current Scheduler, car
position of car sensor

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 460
Quality assurance
• Quality judged by how well product
satisfies its intended function.
• May be measured in different ways for
different kinds of products.
• Quality assurance (QA) makes sure that
all stages of the design process help to
deliver a quality product.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 461
Therac-25 Medical Imager
(Leveson and Turner)
• Six known accidents: radiation overdoses
leading to death and serious injury.
• Radiation gun controlled by PDP-11.
• Four major software components:
• stored data;
• scheduler;
• set of tasks;
• interrupt services.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 462
Therac-25 tasks
• Treatment monitor controlled and
monitored setup and delivery of treatment
in eight phases.
• Servo task controlled radiation gun.
• Housekeeper task took care of status
interlocks and limit checks.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 463
Treatment monitor task
• Treat was main monitor task.
• Eight subroutines.
• Treat rescheduled itself after every
subroutine.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 464
Software timing race
• Timing-dependent use of mode and
energy:
• if keyboard handler sets completion behavior
before operator changes mode/energy data,
Datent task will not detect the change, but
Hand task will.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 465
Software timing errors
• Changes to parameters made by operator
may show on screen but not be sensed by
Datent task.
• One accident caused by entering
mode/energy, changing mode/energy,
returning to command line in 8 seconds.
• Skilled operators typed faster, more likely
to exercise bug.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 466
Leveson and Turner
observations
• Performed limited safety analysis:
guessed at error probabilities, etc.
• Did not use mechanical backups to check
machine operation.
• Used overly complex programs written in
unreliable styles.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 467
ISO 9000
• Developed by International Standards
organization.
• Applies to a broad range industries.
• Concentrates on process.
• Validation based on extensive
documentation of organization’s process.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 468
CMU Capability Maturity Model
• Five levels of organizational maturity:
• Initial: poorly organized process, depends on
individuals.
• Repeatable: basic tracking mechanisms.
• Defined: processes documented and
standardized.
• Managed: makes detailed measurements.
• Optimizing: measurements used for
improvement.

Overheads for Computers as

• Verification and testing are important

throughout the design flow.
• Early bugs are more expensive to fix:
cost to fix

requirements
bug coding bug

Overheads for Computers as

time
© 2008 Wayne Wolf Components 2nd ed. 470
Verifying requirements and
specification
• Requirements:
• prototypes;
• prototyping languages;
• pre-existing systems.
• Specifications:
• usage scenarios;
• formal techniques.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 471
Design review
• Uses meetings to catch design flaws.
• Simple, low-cost.
• Proven by experiments to be effective.
• Use other people in the project/company
to help spot design problems.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 472
Design review players
• Designers: present design to rest of team,
make changes.
• Review leader: coordinates process.
• Review scribe: takes notes of meetings.
• Review audience: looks for bugs.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 473
Before the design review
• Design team prepares documents used to
describe the design.
• Leader recruits audience, coordinates
meetings, distributes handouts, etc.
• Audience members familiarize themselves
with the documents before they go to the
meeting.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 474
Design review meeting
• Leader keeps meeting moving; scribe
takes notes.
• Designers present the design:
• use handouts;
• explain what is going on;
• go through details.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 475
Design review audience
• Look for any problems:
• Is the design consistent with the
specification?
• Is the interface correct?
• How well is the component’s internal
architecture designed?
• Did they use good design/coding practices?
• Is the testing strategy adequate?

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 476
Follow-up
• Designers make suggested changes.
• Document changes.
• Leader checks on results of changes, may
distribute to audience for further review
or additional reviews.

Overheads for Computers as

© 2008 Wayne Wolf Components 2nd ed. 477
Measurements
• Measurements help ground our beliefs:
• Do our practices really work?
• Do they work where we think they work?
• Types of measurements:
• bugs found at different stages of design;
• bugs as a function of time;
• bugs in different types of components;
• how bugs are found.

Overheads for Computers as

Hourglass Workout Program by Luisagiuliet 2
76% (21)
Hourglass Workout Program by Luisagiuliet 2
51 pages
12 Week Program: Summer Body Starts Now
87% (46)
12 Week Program: Summer Body Starts Now
70 pages
Read People Like A Book by Patrick King-Edited
57% (82)
Read People Like A Book by Patrick King-Edited
12 pages
Livingood, Blake - Livingood Daily Your 21-Day Guide To Experience Real Health
77% (13)
Livingood, Blake - Livingood Daily Your 21-Day Guide To Experience Real Health
260 pages
Cheat Code To The Universe
94% (79)
Cheat Code To The Universe
34 pages
Facial Gains Guide (001 081)
91% (45)
Facial Gains Guide (001 081)
81 pages
Curse of Strahd
95% (467)
Curse of Strahd
258 pages
The Psychiatric Interview - Daniel Carlat
91% (34)
The Psychiatric Interview - Daniel Carlat
473 pages
The Borax Conspiracy
91% (57)
The Borax Conspiracy
14 pages
The Secret Language of Attraction
86% (108)
The Secret Language of Attraction
278 pages
How To Develop and Write A Grant Proposal
83% (542)
How To Develop and Write A Grant Proposal
17 pages
Penis Enlargement Secret
60% (124)
Penis Enlargement Secret
12 pages
Workbook For The Body Keeps The Score
89% (53)
Workbook For The Body Keeps The Score
111 pages
Donald Trump & Jeffrey Epstein Rape Lawsuit and Affidavits
83% (1016)
Donald Trump & Jeffrey Epstein Rape Lawsuit and Affidavits
13 pages
KamaSutra Positions
78% (69)
KamaSutra Positions
55 pages
7 Hermetic Principles
93% (30)
7 Hermetic Principles
3 pages
27 Feedback Mechanisms Pogil Key
77% (13)
27 Feedback Mechanisms Pogil Key
6 pages
Frank Hammond - List of Demons
92% (92)
Frank Hammond - List of Demons
3 pages
Phone Codes
79% (28)
Phone Codes
5 pages
36 Questions That Lead To Love
91% (35)
36 Questions That Lead To Love
3 pages
How 2 Setup Trust
97% (307)
How 2 Setup Trust
3 pages
The 36 Questions That Lead To Love - The New York Times
91% (35)
The 36 Questions That Lead To Love - The New York Times
3 pages
100 Questions To Ask Your Partner
78% (36)
100 Questions To Ask Your Partner
2 pages
Satanic Calendar
25% (56)
Satanic Calendar
4 pages
The 36 Questions That Lead To Love - The New York Times
95% (21)
The 36 Questions That Lead To Love - The New York Times
3 pages
Jeffrey Epstein39s Little Black Book Unredacted PDF
75% (12)
Jeffrey Epstein39s Little Black Book Unredacted PDF
95 pages
14 Easiest & Hardest Muscles To Build (Ranked With Solutions)
100% (8)
14 Easiest & Hardest Muscles To Build (Ranked With Solutions)
27 pages
1001 Songs
70% (73)
1001 Songs
1,798 pages
The 4 Hour Workweek, Expanded and Updated by Timothy Ferriss - Excerpt
23% (954)
The 4 Hour Workweek, Expanded and Updated by Timothy Ferriss - Excerpt
38 pages
Zodiac Sign & Their Most Common Addictions
63% (30)
Zodiac Sign & Their Most Common Addictions
9 pages
Project Report
100% (1)
Project Report
53 pages
Software Design Document
No ratings yet
Software Design Document
6 pages
Panvalet Userguide
No ratings yet
Panvalet Userguide
155 pages
M1 Part 2
No ratings yet
M1 Part 2
54 pages
Chapter2_2017SemIEmbSysStd_1in1
No ratings yet
Chapter2_2017SemIEmbSysStd_1in1
33 pages
Chapter2_2017SemIEmbSysStd_4in1
No ratings yet
Chapter2_2017SemIEmbSysStd_4in1
9 pages
Design Process Steps
No ratings yet
Design Process Steps
6 pages
ES Design Process
No ratings yet
ES Design Process
6 pages
CSC 125 LECTURE 2
No ratings yet
CSC 125 LECTURE 2
7 pages
The Embedded System Design Process: Wolf Text - Chapter 1.3
No ratings yet
The Embedded System Design Process: Wolf Text - Chapter 1.3
22 pages
Concept of Embedded Systems Design
No ratings yet
Concept of Embedded Systems Design
123 pages
Chapter1b Design Method
No ratings yet
Chapter1b Design Method
32 pages
UML: Unified Modeling Language
No ratings yet
UML: Unified Modeling Language
69 pages
Embedded Iunit1
No ratings yet
Embedded Iunit1
31 pages
MODULE 3
No ratings yet
MODULE 3
124 pages
Lecture 1 - SE DesignRevision
No ratings yet
Lecture 1 - SE DesignRevision
49 pages
Lecture2010 9 1
No ratings yet
Lecture2010 9 1
41 pages
Unit 7 Design-and-Implementation
No ratings yet
Unit 7 Design-and-Implementation
31 pages
Modularization Is A Technique To Divide A Software System Into Multiple Discrete and Independent Modules
No ratings yet
Modularization Is A Technique To Divide A Software System Into Multiple Discrete and Independent Modules
6 pages
SDA-5
No ratings yet
SDA-5
43 pages
Design Methodologies and Applications
No ratings yet
Design Methodologies and Applications
82 pages
Chapt 5SE (Design)
No ratings yet
Chapt 5SE (Design)
73 pages
5 Computer Organization Concept and Memory: 1.6 The Embedded System Design Process
No ratings yet
5 Computer Organization Concept and Memory: 1.6 The Embedded System Design Process
3 pages
10 1 1 101 5457 PDF
No ratings yet
10 1 1 101 5457 PDF
321 pages
U2 - Embedded Design Process
No ratings yet
U2 - Embedded Design Process
57 pages
Embedded system design process
No ratings yet
Embedded system design process
8 pages
UNIT_III_Design Engineering
No ratings yet
UNIT_III_Design Engineering
124 pages
Unit 3 (SE)
No ratings yet
Unit 3 (SE)
9 pages
Software Engineering B.Tech IT/II Sem-II
No ratings yet
Software Engineering B.Tech IT/II Sem-II
33 pages
Chapter 11
No ratings yet
Chapter 11
53 pages
Es Mod-1
No ratings yet
Es Mod-1
66 pages
Chapter 4a - High Level Design
No ratings yet
Chapter 4a - High Level Design
26 pages
05+06 SE Modeling Architecture
No ratings yet
05+06 SE Modeling Architecture
47 pages
Unit-3
No ratings yet
Unit-3
100 pages
05-InterfaceDesign
No ratings yet
05-InterfaceDesign
16 pages
SE Unit 4
No ratings yet
SE Unit 4
38 pages
RTE ch4
No ratings yet
RTE ch4
29 pages
Software Engineering B.Tech IT/II Sem-II
No ratings yet
Software Engineering B.Tech IT/II Sem-II
34 pages
Chapter1c UML Overview
No ratings yet
Chapter1c UML Overview
41 pages
Chapter Five: Interaction Design and HCI in The Software Process
No ratings yet
Chapter Five: Interaction Design and HCI in The Software Process
52 pages
ESD - CS6 - Small Scale Embedded System Design Example
No ratings yet
ESD - CS6 - Small Scale Embedded System Design Example
54 pages
Week7-System Models
No ratings yet
Week7-System Models
38 pages
Object Oriented SAD-Chapt 5 Part I
No ratings yet
Object Oriented SAD-Chapt 5 Part I
47 pages
Design Engineering: Software Engineering: A Practitioner's Approach, 6th Edition
No ratings yet
Design Engineering: Software Engineering: A Practitioner's Approach, 6th Edition
28 pages
UNIT-3-OOSE-part 1
No ratings yet
UNIT-3-OOSE-part 1
27 pages
Design Process 1111111
No ratings yet
Design Process 1111111
42 pages
Multi-Tracking System: Department of Information Technology
No ratings yet
Multi-Tracking System: Department of Information Technology
53 pages
Software Design Description For: COMSATS University Islamabad, Sahiwal Campus - Pakistan
No ratings yet
Software Design Description For: COMSATS University Islamabad, Sahiwal Campus - Pakistan
8 pages
MODULE-III(CSE3005) [Autosaved] (1)
No ratings yet
MODULE-III(CSE3005) [Autosaved] (1)
32 pages
SE Chapter 5 - Software Design
No ratings yet
SE Chapter 5 - Software Design
23 pages
Topic 5 - Design and Implementation
No ratings yet
Topic 5 - Design and Implementation
81 pages
Software Design Specification Template
No ratings yet
Software Design Specification Template
6 pages
Unit 3
No ratings yet
Unit 3
45 pages
Se Unit3 Part1
No ratings yet
Se Unit3 Part1
45 pages
Pocket Campus Tour: Architecture/Design Document
No ratings yet
Pocket Campus Tour: Architecture/Design Document
12 pages
Debre Markos University: Institute: Dmit Program: Software Engineering Year: 4 Course: Software Component Design
No ratings yet
Debre Markos University: Institute: Dmit Program: Software Engineering Year: 4 Course: Software Component Design
78 pages
Software Engineering-Unit-3
No ratings yet
Software Engineering-Unit-3
36 pages
Software Engineering (203105303) : Shaikh Amin F.
No ratings yet
Software Engineering (203105303) : Shaikh Amin F.
172 pages
FSE Chap 4
No ratings yet
FSE Chap 4
72 pages
Unit-Iv Design Engineering
No ratings yet
Unit-Iv Design Engineering
8 pages
Java / J2EE Interview Questions You'll Most Likely Be Asked
From Everand
Java / J2EE Interview Questions You'll Most Likely Be Asked
Vibrant Publishers
No ratings yet
F IREWALL
No ratings yet
F IREWALL
133 pages
How to Reset the Photoconductor Page Count on a Lexmark E340 or E342
No ratings yet
How to Reset the Photoconductor Page Count on a Lexmark E340 or E342
3 pages
K Means Clustering Lecture
No ratings yet
K Means Clustering Lecture
32 pages
Great Lakes Extraa_Learn Project Business Report - 2-Kavish-Rathod
No ratings yet
Great Lakes Extraa_Learn Project Business Report - 2-Kavish-Rathod
22 pages
Labplot 2
No ratings yet
Labplot 2
62 pages
Quanta Zsa Rev 1a
No ratings yet
Quanta Zsa Rev 1a
55 pages
Management Information Systems Question Bank
No ratings yet
Management Information Systems Question Bank
41 pages
Flutter - Animation
100% (1)
Flutter - Animation
5 pages
Pmp122 Manual
No ratings yet
Pmp122 Manual
91 pages
NSC Unit Important Questions
No ratings yet
NSC Unit Important Questions
50 pages
Introduction To Computer Com 101
No ratings yet
Introduction To Computer Com 101
12 pages
Charotar University of Science & Technology Semester: 3 CE (B. Tech) Subject: DBMS Practical List
33% (3)
Charotar University of Science & Technology Semester: 3 CE (B. Tech) Subject: DBMS Practical List
8 pages
ONB 2.0 Furnish Equipment Integration to External_v2.1
No ratings yet
ONB 2.0 Furnish Equipment Integration to External_v2.1
29 pages
Daniel Batalla Queirolo at Nexton
No ratings yet
Daniel Batalla Queirolo at Nexton
7 pages
CCNP Routing Switching Syllabus
100% (1)
CCNP Routing Switching Syllabus
8 pages
Telephone Billing System Java Project
No ratings yet
Telephone Billing System Java Project
3 pages
Devialet Phantom English
No ratings yet
Devialet Phantom English
11 pages
8085 Microprocessor Unit II All Questions 10PlusPages
No ratings yet
8085 Microprocessor Unit II All Questions 10PlusPages
10 pages
Chapter 4 - Introduction To Source Coding
No ratings yet
Chapter 4 - Introduction To Source Coding
72 pages
Information Management System Assignment 1
No ratings yet
Information Management System Assignment 1
17 pages
Mobile App Development Proposal: Prepared For
No ratings yet
Mobile App Development Proposal: Prepared For
7 pages
Social Media Statistics EBOOK
No ratings yet
Social Media Statistics EBOOK
64 pages
exam-dd2459-2025-03-11
No ratings yet
exam-dd2459-2025-03-11
6 pages
Accenture-Open-Banking-In-The-Middle-East-Part-1
No ratings yet
Accenture-Open-Banking-In-The-Middle-East-Part-1
18 pages
9 - Operating System
No ratings yet
9 - Operating System
61 pages
Mf720 Series
No ratings yet
Mf720 Series
327 pages
Blockchain and AI Technology Convergence Applications in Transportation Systems
No ratings yet
Blockchain and AI Technology Convergence Applications in Transportation Systems
32 pages
Abbas Moallem (Editor) - Smart and Intelligent Systems - The Human Elements in Artificial Intelligence, Robotics, and Cybersecurity (The Human Element in (2021, CRC Press) - Libgen - Li
No ratings yet
Abbas Moallem (Editor) - Smart and Intelligent Systems - The Human Elements in Artificial Intelligence, Robotics, and Cybersecurity (The Human Element in (2021, CRC Press) - Libgen - Li
188 pages
Simplicial Complexes
No ratings yet
Simplicial Complexes
72 pages