Design Methodologies and

Applications
(Lecture Slide #11)

K.PRAVEEN,
AP(Sl. Gr.)/DECE,
CEG, ANNA UNIVERSITY,
CHENNAI -
600025
1
 System design techniques
• Design methodologies.
• Requirements and specification.

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

3
 Product metrics
• Time-to-market:
– beat competitors to market;
– meet marketing window (back-to-school).
• Design cost.
• Manufacturing cost.
• Quality.

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

5
 Waterfall model
• Early model for software development:

requirements

architecture
coding

testing

maintenance
6
 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. 7
 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.

8
 Spiral model
system feasibility

specification

prototype

initial system

enhanced
system
requirements
design
test

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

10
Successive refinement model

specify specify
architect architect

design design

build build
test test

initial system refined system

11
Hardware/software design flow
requirements and
specification

architecture

hardware design software design

integration

testing
12
 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.

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

14
Hierarchical HW/SW flow
spec spescp
ec
architecture HWSWarcahrictehcitteucrteur
e
HW SW detadielteadildeedsdigensig
n
integrate inteignrteagtiroantio
n
test testtes
t
system harsdowftawrear
e 15
 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.

16
 Concurrent engineering
techniques
• Cross-functional teams.
• Concurrent product realization.
• Incremental information sharing.
• Integrated product management.
• Supplier involvement.
• Customer focus.

17
 AT&T PBX concurrent
engineering
• Benchmark against competitors.
• Identify breakthrough improvements.
• Characterize current process.
• Create new process.
• Verify new process.
• Implement.
• Measure and improve.

18
 Requirements analysis
• Requirements: informal description of what
customer wants.
• Specification: precise description of what
design team should deliver.
• Requirements phase links customers with
designers.

19
 Types of requirements
• Functional: input/output relationships.
• Non-functional:
– timing;
– power consumption;
– manufacturing cost;
– physical size;
– time-to-market;
– reliability.

20
 Good requirements
• Correct.
• Unambiguous.
• Complete.
• Verifiable: is each requirement satisfied in
the final system?
• Consistent: requirements do not contradict
each other.

21
 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. 22
 Setting requirements
• Customer interviews.
• Comparison with competitors.
• Sales feedback.
• Mock-ups, prototypes.
• Next-bench syndrome (HP): design a
product for someone like you.

23
 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.
24
 SDL
• Used in
telephone
telecommunications on-hook
protocol design.
• Event-oriented state caller goes
off-hook
machine model.
dial tone

caller gets
dial tone

25
 Statecharts
• Ancestor of UML state diagrams.
• Provided composite states:
– OR states;
– AND states.
• Composite states reduce the size of the
state transition graph.

26
 Statechart OR state
s123
i1 i1
S1 S1
i2
i1 i1 i2
i2
S2 S4 S2 S4

i2

S3 S3

traditional OR state
27
 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
traditional S5 AND state

28
 AND-OR tables
• Alternate way of specifying complex
conditions:
cond1 or (cond2 and !cond3)
OR
cond1 T
- T
AND --
cond2 F

cond3 29
 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.

30
 RMSL
• State description: • Transition bus for
transitions between
state1
many states:

inputs
a
state description b

outputs
c
31
TCAS top-level description
CAS

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

other-aircraft i:[1..30] standby

32
 Own-Aircraft AND state
CAS
Inputs:
own-alt-radio: integer standby-discrete-input:
{true,false} own-alt-barometric:integer, etc.
Clim.b..-inibit Descen.d..-inibit
Effective-SL Alt-SL Alt-layer
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.
33
 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.

34
 CRC card format

Class name: Class name:

Collaborator
s:

front back

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

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

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

38
 Elevator responsibilities and
collaborators
c la s s re s p o n s ib ilit ie s c o lla b o ra
to rs

E le v a to r c M o v eu p a n d d o w C a r c o n tro l, c a
a r* n r
sensor, car co
Car con T ra n s m its n tro l s e n d e r
tro l* ca P a s s e n g e r , f lo
or
r re q u e s ts
C a r s ta Reads cur c oc n
S h tro
e d lu re
le ar ,d e r
te re n t p o s it io car sensor
n of car
39
 Application Example
• Digital Alarm Clock
• Data Compressor
• Software Modem
• PDA
• Settop Box

40
DIGITAL ALARM CLOCK
Specification-UML Class Diagram
State diagram for Time Updation
State diagram for scan-keyboard.
 Data Compressor- Goals
• Compress data transmitted over serial
line.
– Receives byte-size input symbols.
– Produces output symbols packed into
bytes.
• Will build software module only here.

45
 Collaboration diagram for
compressor

1..m: packed
1..n: input output
symbols symbols
:input :data compressor :output

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

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

48
 Example Huffman code
• Read code from root to leaves:
a 1
b 01
c 0000
d 0001
e 0010
f 0011

49
Huffman coder requirements
table
name d a t a c o m p r e s s io n m o d
u le
p u rp o s c o d e m o d u le f o r H u f f m
e a n c o m p r e s s io n
in p u e n c o d in g t a b le , u n c o
ts
d e d b y t e - s iz e in p u t s
o u tp u p a c k e d c o m p r e s s io n
ts o u tp u t

f u n c t io n s y m b o ls
s H u f f m a n c o d in g
p e r fo rm a n fa s
ce t
m a n u f a c t u r in g c N/
ost A
powe N/
r A
p h y s ic a l s iz e / w e N/
ig h t A

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

51
Data-compressor class
data-compressor
buffer: data-buffer
table: symbol-table
current-bit:
integer
encode(): boolean,
data-buffer
flush()
new-symbol-
table()

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

53
 Auxiliary classes

data-buffer symbol-table
Databuf [databuflen] : Symbols [nsymbols] :
character data-
len : integer buffer len :
integer
insert()
length() : integer value() : symbol
load()

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

55
 Class Relationships

data-compressor
1 1
1 1
data-buffer symbol-table

56
 Encode Behavior

create new buffer return true

F add to buffer return false

57
 Insert Behavior

pack into
input T this
symbol buffer
update
fills buffer?
length
F pack bottom bits
into this buffer,
top bits into
overflow buffer

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

59
 Testing
• Test by encoding, then decoding:

symbol table

input symbols encoder decoder result

compare

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

61
 Software Modem :Theory of
operation
• Frequency-shift keying:
– separate frequencies for 0 and 1.

0 1

time

62
 FSK Encoding
• Generate waveforms based on current bit:

0110101 bit-controlled
waveform
generator

63
 FSK Decoding

0 bit
A/D converter
zero filter detector

one filter detector 1 bit

64
 Transmission Scheme
• Send data in 8-bit bytes. Arbitrary spacing
between bytes.
• Byte starts with 0 start bit.
• Receiver measures length of start bit to
synchronize itself to remaining 8 bits.

start (0) bit 1 bit 2 bit 3 ... bit 8

65
 Requirements
Inputs A n a l o g s o u n d input, re s e t b u tt o n .

Outputs A n a l o g s o u n d o u t p u t , L E D bit dis play.

Functions Tra n s m i t t e r : S e n d s d a t a f r o m m e m o r y
in 8-bit b y t e s p lu s start bit.
Re c e i ve r : A u t o m a t i c a l l y d e t e c t s b y t e s
a n d r e a d s bits. Dis play s c u rre n t bit o n
L E D.
Pe r f o r m a n c e 1200 baud.

Manufacturing cost Dominated by microprocessor and

P hy s ic a l S m a l l d e s k t o p objec t.
s i z e / w e ig h t

66
 Specification
Line-in* Receiver
1
1

sample-in()
input()
bit-out()
Transmitter Line-out*
1
1

bit-in()
output()
sample-out() 67
 System Architecture
• Interrupt handlers for samples:
– input and output.
• Transmitter.
• Receiver.

68
 Transmitter
• Waveform generation by table lookup.
– float sine_wave[N_SAMP] = { 0.0, 0.5, 0.866,
1, 0.866, 0.5, 0.0, -0.5, -0.866, -1.0, -0.866, -
0.5, 0};

time

69
 Receiver
• Filters (FIR for simplicity) use circular
buffers to hold data.
• Timer measures bit length.
• State machine recognizes start bits, data
bits.

70
 Hardware Platform
• CPU.
• A/D converter.
• D/A converter.
• Timer.

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

72
 System Integration and Testing
• Use loop back mode to test components
against each other.
– Loop back in software or by connecting D/A
and A/D converters.

73
 PDA
Hardware Architecture of Newton
Message PAD

74
Motorola Envoy PDA

75
Organization of InfoPad

76
Set-top Box

77
Set-top Box for Fiber to the Curb
Video Delivery

78
Software Architecture of Set-top Box

79
Software Architecture of Set-top Box
(Alternate)

80
System On Silicon

81
THANK
YOU
82