Unit V - System Design Techniques

EMBEDDED SYSTEM DESIGN/ EEE18R423
Presented By
Mr.S.Kalimuthu Kumar
Asst. Prof./EEE
KalasalingamAcademy of Research & Education

UNIT V (Design simple product using system design
technology CO5)
1
• Design methodologies
• Requirement analysis – specification - system analysis and

2
architecture design, Quality assurance
3
• Design example: telephone PBX-System Architecture
4
• Ink jet printer – hardware design and software design.
5
• Personal digital assistants, Set-top boxes
2
System design techniques
Design methodologies.
Requirements and specification.
Overheads for Computers as Components 2nd

© 2008 Wayne Wolf ed.
Design process
It is a sequence of steps necessary to build a product

Important goals of design process are
Function
Performance
Power
4
Design process
Time to Market: products should be manufactured with

new features and sold out on the right time(calculator)
Design cost: the cost of designing a system
Quality: to obtain high quality product, the product

should be designed with these three factors- Usability,
reliability and correctness
5
Design methodology
A good design methodology can build a system that

works properly
A Design flow is a sequence of steps to be followed

during a design
Some of the steps can be performed by tools, such as

compilers or CAD systems; other steps can be performed
by hand. 6
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.

Requirements analysis
Requirements: informal description of what customer

wants.
Specification: precise description of what design team
should deliver.
Requirements phase links customers with designers.

Types of requirements
Functional: input/output relationships.

Non-functional:
timing;
power consumption;
manufacturing cost;
physical size;
time-to-market;
reliability.
Good requirements
Correct.(need of customer correctly)

Unambiguous.(document should be clear)
Complete.(all the requirements should be included)
Verifiable: is each requirement satisfied in the final
system?
Consistent: requirements do not contradict each other.

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.

Setting requirements
Customer interviews.
Comparison with competitors.
Sales feedback.
Mock-ups, prototypes.
Next-bench syndrome (HP): design a product for
someone like you.

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.

Types of design methodology
Design models used in software development process are

 Waterfall model
Spiral model
Successive refinement model
Hardware/software design methodology
14
Waterfall model
Early model for software development:
requirements
architecture
coding
testing
maintenance
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.

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.
Unrealistic design processes

Spiral model
Many versions of a system which will be build

Every phase needs more work. so that spiral is enlarged
At starting , it is small & shorter
At bottom of spiral ,it additionally holds detail taken from
earlier cycles of spiral
18
Spiral model
system feasibility
specification
prototype
initial system
enhanced system
requirements
design
test

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.

Spiral model
Advantages
- More realistic than waterfall model because many iterations
are required to include enough detail to fulfill a design.
Disadvantages
- it holds more number of spiral . So that it takes more time
when the design time is an important criteria.
21
Successive refinement model
Series of design cycles

System is developed many times
Initial system is takes as rough prototype.
Next model again refined
If the designer does not know enough detail about
process-very useful
22
Successive refinement model
specify specify
architect architect
design design
build build
test test
initial system refined system

Hardware/software design flow
requirements and
specification
architecture
hardware design software design
integration
testing
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.

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.

Hierarchical HW/SW flow
spec specspec
architecture HWSW
architecture
architecture
HW SW detailed
detailed
design
design
integrate integration
integration
test test test
system hardware
software
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.

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

AT&T PBX concurrent engineering
Private branch exchange
Benchmark against competitors.
Identify breakthrough improvements.
Characterize current process.
Create new process.
Verify new process.
Implement.
Measure and improve.
SDL(specification description language)
Used in telecommunications telephone

on-hook
protocol design.
Event-oriented state machine caller goes
model. off-hook
dial tone
caller gets
dial tone

Quality assurance.
If the product performs it’s work correctly & it satisfies the
customer then it has good quality
Sometime it may poor quality due to
Improper design of the component
Poor architecture
Manufacturing problems
Poor understanding of product’s need
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.

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.

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

Verification
Verification and testing are important throughout the

design flow.
Early bugs are more expensive to fix:
cost to fix
requirements
bug coding bug

time
Verifying requirements and
specification
Requirements:
prototypes;
prototyping languages;
pre-existing systems.
Specifications:
usage scenarios;
formal techniques.

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.

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.

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.

Design review meeting
Leader keeps meeting moving; scribe takes notes.

Designers present the design:
use handouts;
explain what is going on;
go through details.

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?

Follow-up
Designers make suggested changes.

Document changes.
Leader checks on results of changes, may distribute to
audience for further review or additional reviews.

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.
Private branch exchange (PBX).

Ink-jet printer.
PDAs.
Set-top boxes.
© 2000 Morgan Kaufman Overheads for Computers as Components

Digital telephone switches
High-end switches are highly reliable:

30 seconds downtime per year.
Companies, homes install private branch exchanges
(PBXs):
intercom features;
management of long distance charges.

Telephone switching systems
Establish telephone calls:

within switch, find other phone line;
outside switch, find route to other line.
Route voice samples between phones.
Measure call time for billing.
Provide maintenance access to switch.

Telephone terminology
Line: distinct telephone connection.

Line card: PBX/subscriber line interface.
Off-hook: active telephone.
On-hook: inactive telephone.
Trunk line: phone lines between switches.
POTS: plain old telephone service (analog, no fancy
services).

Computer-controlled telephone
switching
Voice data rates:

8 bits sample (m or A law); line
125 m s period (8 kHz). CPU
card
Telephones are I/O devices.

Computer bus is switch.
memory
line
card

Dialing
Dual-tone multi-frequency
(DTMF): tones define row, 1 2 3
column of key.
Must be held for 0.1 sec. 4 5 6
7 8 9
* 0 #

Call states
Line 1
Receive call
Incoming Rcv ringing Take off-hook
call
Return on-hook Call

On-hook
Other phone
off-hook
Take off-hook
Line 2 Place
Dial decoder ready ringing
Place call
Dial
Off-hook Dialing
tone Number
complete

PBX model
Calls are parallel processes:
Call coordination, billing, etc.
...
Call 1 Call n

Tigerswitch system architecture
PC platform.
Switch calls over ISA bus.
Line cards are custom devices.

DTMF sensing
Software process on CPU.

Uses lots of CPU time. line
card
Analog filter bank on line CPU
cards.
DTMF card
Expensive in volume.
DSP on separate card. memory
line
Requires new design. card

Switching
Process-per-call is bad for (i=0; i<n_calls; i++) {

implementation. /* from 1 to 2 */
Context switch per call per 125 data = read(call[i].line1);
ms.
write(call[i].line2,data);
Unroll calls into one loop.
Each loop iteration is one call /* from 2 to 1 */
for one sample. data = read(call[i].line2);
write(call[i].line1,data);
}

HP DesignJet drafting plotter
Plots up to 36 inches wide at 300 DPI.

Combines a variety of tasks:
host communication;
graphics language interpretation;
rasterization;
device control.

The plotting process
HP-GL/2 PostScript
rasterizer
raster memory
plotter
controller

Design considerations
Memory utilization is important.

36 inches X large X 300 DPI X n bits/pixel is a lot of memory.
Requires clever algorithms to minimize raster memory
requirements.
Requires real-time control.
Requires concurrency: read new data, rasterize, control
print head.

HP DesignJet hardware architecture
adrs 1 MB
i960KA ROM
latch
pen bus 2 MB
swath if
EEPROM ctrl DRAM
RAM
ASIC
proc.
servo support ||
proc. ASIC if
(8052)
carriage RS-
DRAM
front panel stepper PC board ctrl 422
motor

Early architectural decisions
Chose Intel 80960KA as main processor.

Handled parsing, rasterization control, print engine control.
Multiplexed bus reduced pin count.
Could be upgraded to floating-point if necessary.
Used modular I/O to host system.
Did not use disk for local storage.

System components
2 MB RAM (SIMM sockets for more).

Three ASICs:
pen interface;
processor support;
carriage.
Servo processing performed by 8052 microcontroller.

Rasterization
Plot is generated in swaths.

Separate swath memory.
Pixels are generated in row order by main processor.
Pixels are fed to pens in column order.
Pen interface ASIC transforms row order to column
order.

Data flows
parsing and rasterization
adrs 1 MB
i960KA ROM
latch
swath generation
pen bus 2 MB
swath if
EEPROM ctrl DRAM
RAM
ASIC
proc.
servo drawing support ||
proc. ASIC if
(8052)
carriage RS-
DRAM
front panel stepper PC board ctrl 422
motor

Operations
Servo processor controls stepper motor.

Carriage processor must write, read pen alignment
marks.
Processor support ASIC provides multiple functions:
interrupt and mailbox communication.
Motion controller decodes position of print carriage and
paper; watchdogs servo.

Pen interface ASIC
Interfaces to i960 bus, swath memory, carriage ASIC.

Pen interface reads pixels from swath in predetermined
pattern using pixel address generator.
Must support bidirectional printing since head prints both
ways.

Carriage ASIC
Interrfaces to processor bus, pen interface ASIC, servo

controller.
Reads timing control registers using the CPU bus.
Delay registers add correction for pen alignment.

Development process
Pixel shuffling algorithm for pen interface/carriage ASICs

was prototyped in C.
Built emulators for ASICs to allow parallel development
of i960 software and hardware.

Software development environment
Plotter software could be run on Unix workstation or

target platform.
Differed in I/O and print engine subsystems.
Print engine was emulated on host with X window interface
showing swath state.
Used in-house RTOS.
HP-GL/2 parser was legacy code.

Software development environment,
cont’d.
Rewrote vector/raster converter from assembly language

to C to port to i960.
Used gdb960 as monitor debugger on target system,
communicating with host.
Front panel developed on PC, tested by user interface
designers, marketing.
Paper loading designed by mechanical engineers.

Personal digital assistant
PDA: portable, specialized information device.

Characteristics:
low cost for consumer market;
physically small;
battery-powered;
software-rich.

Apple Newton
First modern PDA.

Original used ARM 610; later version used StrongARM.
Support operations in Runt ASIC: DMA, real-time clock,
video interface, audio, PCMCIA.
Software written in NewtonScript language.

Newton hardware architecture
ARM 610 ROM RAM
PCMCIA Runt
serial I/F
infrared ASIC
A/D
LCD
tablet
speaker

Motorola Envoy hardware
architecture
PCMCIA 1 MB DRAM 4 MB flash
Magicbus
Astro infrared
audio system
ASIC
power supply
modem 68439
CPU A/D
touchscreen

Feature creep
Designers tend to add features to system during design.

Increases power consuption.
Changes mechanical design.
Makes software design more complex.
Software thrashing can reduce battery life.

PDA power supply
System must be designed to gracefully handle low

battery power.
Abrupt power loss can destroy lots of data in RAM.
Smart Battery System puts electronics in battery to
measure battery performance.

InfoPad
Brodersen et al: advanced networked multimedia

information appliance.
System performed many functions on remote systems to
increase battery life.
Made use of specialized hardware units to reduce power
consumption over software implementation.

InfoPad hardware architecture
Wireless network
interface
Speech
codec display
Video
decompressor Keyboard/pointer
ARM 60 other I/O

Set-top boxes
Interface between cable/satellite and TV:

digital television;
user interface;
may include back channel for purchases, etc.
Very cost-sensitive market.
Personal computer memory card international association
National television system committee

Set-top box in system
digital TV input
set-top box back

channel
IR

Philips fiber-to-curb box hardware
DRAM
Network MPEG MPEG

interface demux audio
MPEG
DRAM NVRAM video
kbd
I/O DRAM
IR NTSC
PCMCIA CD-I
card graphics

Fiber-to-curb box software
application
default apps custom apps layer
boot/monitor software
OS-9 kernel I/O manager

OS
layer
device drivers
network hardware
MPEG2 audio/video CD-I layer
interface demux interfaces graphics
processor

Unit V - System Design Techniques

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unit V - System Design Techniques

Transféré par

Droits d'auteur :

Formats disponibles

EMBEDDED SYSTEM DESIGN/ EEE18R423

KalasalingamAcademy of Research & Education

• Requirement analysis – specification - system analysis and

Overheads for Computers as Components 2nd

It is a sequence of steps necessary to build a product

Time to Market: products should be manufactured with

Design cost: the cost of designing a system

Quality: to obtain high quality product, the product

A good design methodology can build a system that

A Design flow is a sequence of steps to be followed

Some of the steps can be performed by tools, such as

Design flow: sequence of steps in a design methodology.

Overheads for Computers as Components 2nd

Requirements: informal description of what customer

Overheads for Computers as Components 2nd

Functional: input/output relationships.

Correct.(need of customer correctly)

Overheads for Computers as Components 2nd

Modifiable: can update requirements easily.

Overheads for Computers as Components 2nd

Overheads for Computers as Components 2nd

Capture functional and non-functional properties:

Overheads for Computers as Components 2nd

Design models used in software development process are

Successive refinement model

Hardware/software design methodology

Early model for software development:

Requirements: determine basic characteristics.

Overheads for Computers as Components 2nd

Only local feedback---may need iterations between

Overheads for Computers as Components 2nd

Many versions of a system which will be build

Overheads for Computers as Components 2nd

Successive refinement of system.

Overheads for Computers as Components 2nd

Series of design cycles

initial system refined system

Overheads for Computers as Components 2nd

hardware design software design

Must architect hardware and software together:

Overheads for Computers as Components 2nd

Embedded systems must be designed across multiple

Overheads for Computers as Components 2nd

test test test

Large projects use many people from multiple disciplines.

Overheads for Computers as Components 2nd

Overheads for Computers as Components 2nd

Used in telecommunications telephone

Overheads for Computers as Components 2nd

Quality judged by how well product satisfies its intended

Overheads for Computers as Components 2nd

Developed by International Standards organization.

Overheads for Computers as Components 2nd

Five levels of organizational maturity:

Overheads for Computers as Components 2nd

Verification and testing are important throughout the

Overheads for Computers as Components 2nd

Overheads for Computers as Components 2nd

Uses meetings to catch design flaws.

Overheads for Computers as Components 2nd

Designers: present design to rest of team, make

Overheads for Computers as Components 2nd

Design team prepares documents used to describe the