CHAPTER 2

EMBEDDED SYSTEM DESIGN

PROCESS

1
OUTLINE
 Introduction
 Design Challenges

 Design Process
 Example
 Traditional Embedded System Development
 Modern
M d E
Embedded
b dd d System
S t D
Development
l t
 Hardware Software Co-Design
 Comparison and Application Areas

2
INTRODUCTION
 ESD is unlike the design/development
g / p of application
pp on
standard platform, where the hardware is a done deal

 ESD requires both Hardware and Software to be

designed in Parallel/Serially

 An ESD projects are usually an optimization exercise that

strive to create both hardware and software, that
p
complement each other

 Embedded systems projects aren’t just either “software

on small machines.
machines ” nor “writing
writing ‘C’
C code
code” 3
DESIGN CHALLENGES AND CONSTRAINTS
 An ES Designer must construct an implementation that fulfills
the desired functionality that simultaneously optimizes
numerous design metrics (parameters that define design
requirements)
 Common design metrics used in embedded systems are
 Unit cost, NRE cost, size, performance, power, flexibility, time to
market, time to prototype, correctness, safety , flexibility,
maintenance…
maintenance
 To best meet the optimization challenge the designer must be
 An expert in HW/SW technologies
 F ili with
Familiar ith State‐of‐the
St t f th artt design
d i technologies
t h l i ini both
b th HW and
d
SW design

 A design
d i process should
h ld take
t k into
i t accountt the
th design
d i metrics
ti 4
through out the development process
 DESIGN PROCESS
 Major
j abstraction levels of the design
g pprocesses are
 Requirements, Specification, Architecture, Components,
System Integration
 These are important steps in developing an embedded
system

5
 DESIGN PROCESS…
 Two types of design process
 Top‐Down
 Bottom‐Up

 Top Down
Top‐Down
 Begins with the most abstract description of the system and
conclude with the concrete detail
 Most favored approach
pp
 Bottom‐Up
 Start with components to build the system, ending up with
particular requirements
 U d when
Used h we do d nott have
h perfect
f t insight
i i ht into
i t how
h l t stages
later t off
the design process will turn out
 Used when we have the less experience with the design of such
systems
 Most preferred approach for beginners 6
 DESIGN PROCESS…
 Requirements
q
 Are informal descriptions gathered from customers
 Before designing the system know the system you are
building
 Can be of two types
 Functional
 Non‐Functional

 After writing requirements check for consistency

 Separating requirement analysis and specifications are need
because of gap between what customers describe and what
architects need to design the system

7
 DESIGN PROCESS – REQUIREMENTS…
 Requirement
q analysis
y of bigg systems
y can be complex
p and
time consuming
 However, capturing a relatively small amount of
i f
information
ti i a clear,
in l simple
i l format
f t is
i a good
d start
t t
toward understanding system requirements
 A requirement form as shown below could be used when the
project is in the initial stage and acts like a checklist

8
 DESIGN PROCESS – REQUIREMENTS…
 Requirements Form entries

 Name
 Giving a name to the project not only simplifies talking about it to
other people but can also crystallize the purpose of the machine
 Purpose
 This should be a brief one or two‐line description of what the system is
supposed to do
 Inputs and outputs
 Encompass a wealth of detail
 Types of data: Analog electronic signals? Digital data? Mechanical inputs?
 Data characteristics: Periodically arriving data, such as digital audio samples?
Occasional user inputs? How many bits per data element?
 Types of I/O devices: Buttons? Analog/digital converters? Video displays?
 Functions 9
 A more detailed description of what the system does
 DESIGN PROCESS – REQUIREMENTS…
 Requirements Form entries…

 Performance
 Essential that the performance requirements be identified early since they must
be carefully measured during implementation, to ensure that the system works
properly
 Manufacturing cost
 Includes primarily the cost of the hardware components
 You should have some idea of the eventual cost range
 Power
 A rough idea of how much power the system can consume would be helpful.
 Decision whether the machine will be battery powered or plugged into the wall
will be based on this information
 Physical size and weight
 Give some indication of the physical size of the system to help guide certain
architectural decisions
 A desktop machine has much more flexibility in the components used than, for
example,
l a lapel
l l mounted
t d voice
i recorder
d 10
 DESIGN PROCESS – REQUIREMENTS…
 Example:
p Requirements
q analysis
y of a GPS movingg map
p
 The moving map is a handheld device that displays for the user a map
of the terrain around the user’s current position
 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 might look something like figure below

11
 DESIGN PROCESS – REQUIREMENTS…
 Example: Requirements analysis of a GPS moving map – Initial
Requirement Form
 Functionality
 This system is designed for highway driving and similar uses, not nautical or aviation
uses that require more specialized databases and functions. The system should show
major roads and other landmarks available in standard topographic 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 to allow the user to make selections to control the system.
 Performance
 The map should scroll smoothly. Upon power‐up, a display should take no more than
one second to appear, and the system should be able to verify its position and display
the current map within 15 s.
 Cost
 The selling cost (street price) of the unit should be no more than $100.
$100
 Physical size and weight
 The device should fit comfortably in the palm of the hand.
 Power consumption
 The device should run for at least eight hours on four AA batteries.
12
 DESIGN PROCESS – REQUIREMENTS…
 Example:
p Requirements
q analysis
y of a GPS movingg map
p‐
Initial Requirement Chart
 Using Engineering terms
 keeping a record of what the customer wants can help to resolve
questions about the specification that may crop up later during
design

13
 DESIGN PROCESS – SPECIFICATIONS
 Refinement of the requirements
 More detailed description of what we want
 States only how the system behaves, not how it is built
 does not say how the system does things, only what the system does
 More precise
p
 Should also be unambiguous enough that designers know what they need to
build
 Serves as the contract between the customer and the architects
 Must be carefully written so that it accurately reflects the customer
customer’ss
requirements and does so in a way that can be clearly followed during
design
 Contains enough information to begin designing the system
architecture
 Essential to creating working systems with a minimum of designer
effort
 Should be understandable enough so that someone can verify that it
meets system requirements and overall expectations of the customer 14
 DESIGN PROCESS – SPECIFICATIONS…
 Example:
p Specifications
p of GPS movingg map
p – Include
several components
 Operations that must be performed to satisfy customer
requests
 Background actions required to keep the system running,
such as operating the GPS receiver
 Data received from the GPS satellite constellation
 Map data
 User interface

 UML would
ld b
be used
d to prepare specifications
ifi i 15
 DESIGN PROCESS – SPECIFICATIONS…
 Comparison
p of the focus of Requirement
q and
Specification
Requirements Specifications

An informal description gathered from A contract between customer and system

customer architects
Requirement form used to give a formal UML is used to give clear and proper
listing of the requirements specifications
The basic needs to design a system are The description of a project is given by
given by system requirements system specification
Less challenging
g g task More complex
p and challenging
g g task

Requirements need not be perfect Specifications s should be perfect enough

in order to develop correct application
Good psychological skills are required to Good engineering skills are required to
16
produce good system requirements produce good specifications
 DESIGN PROCESS – ARCHITECTURE
 Ap plan for the overall structure of the system
y that will be
used later to design the components that make up the
architecture
 Its
It purpose is i describing
d ibi how
h th system
the t i l
implements t
the functions stated in the specifications
 The creation of the architecture is the first p phase of
what many designers think of as design
 Architectural descriptions must be designed to satisfy
b h functional
both f i l and
d nonfunctional
f i l requirements
i
 The system architecture will be in the form of block
diagram that shows major operations and data flows
17
 DESIGN PROCESS – ARCHITECTURE…
 Example:
p Architecture of GPS movingg map
p – System
y
Architecture
 Figure below shows a sample system architecture in the form
of a block diagram that shows major operations and data
flows among them
 The block diagram is still abstract, does not specify which operation
will be performed by software running in a CPU,
CPU what to be done by
special purpose software. Yet goes a long way towards describing
how to implement the functions described in the specifications

18
 DESIGN PROCESS – ARCHITECTURE…
 Example: Architecture of GPS moving map – System
Architecture…
 The block diagram explains about
 The GPS navigation system where GPS receiver gets the current position
and the destination is taken from the user
 Digital map from source to destination is found from database and
displayed by the renderer
 The block diagram clearly shows that we need to search the
topographic database and to render the results for the display
 We have chosen to separate those functions so that we can potentially
do them in parallel—performing rendering separately from searching
the database mayy help
p us update
p the screen more fluidlyy

 Next the system block diagram is refined into two block

diagrams
19
 One for Hardware and another for Software
 DESIGN PROCESS – ARCHITECTURE…
 Example:
p Architecture of GPS movingg map
p – Hardware
 Consists of one central CPU surrounded by memory and I/O
devices
 Two memories used
 The frame buffer holds the pixel to be displayed
 Another memory for program/data which will be used by the CPU

 The
Th bus
b interconnects
i t t allll these
th componentst

20
 DESIGN PROCESS – ARCHITECTURE…
 Example:
p Architecture of GPS movingg map
p – Software
 This block diagram is the same as the initial architecture,
with additional timer, which is used to control when we read
the buttons on the user interface and render data onto the
screen

21
 DESIGN PROCESS – ARCHITECTURE…
 To have a truly complete architectural description, more
detail designs are required such as
 Where units in the software block diagram will be executed in the
hardware block diagram
 When operations will be performed in time
 Not only must all the required functions be present, but we
must meet design goals,
goals and other non
non‐functional
functional constraints
 One good way to ensure meeting all specifications is to
starting with a system architecture and refining that into
h d
hardware and
d software
ft architectures
hit t
 Concentrate on the functional elements in the system block
diagram
 Consider the non‐functional constraints when creating the 22
hardware and software architecture
 DESIGN PROCESS – ARCHITECTURE…
 How do we know our HW and SW architectures meet
design metrics ?
 Estimate the properties of the components of the block
diagram
 Accurate estimation derives from experience
 Create simplified models for more accurate estimations

 Sound estimates of all non‐functional requirements

during the architecture phase are crucial, since decision
based on bad data will show up during the final phase of
design
23
 DESIGN PROCESS
HARDWARE AND SOFTWARE COMPONENTS
 The architectural description tells us what components we need
 The component design effort builds those components in
conformance to the architecture and specification
 The components will in general include both HW & SW modules
 Some of the components will be ready‐made (CPU, memory
chips…)
 When creating Embedded SW module,
module ensure the system runs on
properly in real time, and doesn’t take more memory space
 Carefully analyze the power consumption
 EExample:
l Memory
M transactions
i must be
b carefully
f ll planned
l d to avoid
id reading
di
the same data several times, since memory accesses are the major source
of power consumption

24
 DESIGN PROCESS
HARDWARE AND SOFTWARE COMPONENTS…
 Example: Hardware and Software component of GPS moving map
 GPS receiver
 A predesigned standard HW component
 Topographic
p g p software
 A standard SW module with standard routines to access DB
 PCB
 Houses custom and off
off‐the
the shelf components
 Lots of custom programming also required

25
DESIGN PROCESS - SYSTEM INTEGRATION
 Deal with the integration/assembly of the components created
 After the components are built, they are integrated
 Bugs are typically found during system integration
 However, good planning, phase level development, good test runs
at each phase can assist in finding bugs well/early
 By debugging few simple bugs early, more complex or other bugs
can be uncovered
 System integration is difficult because it usually uncovers problems
 The debugging facilities for ES are usually much more limited than
the desktop systems
 Careful attention to inserting appropriate debugging facilities
during design can help ease system integration problems
26
 TRADITIONAL EMBEDDED SYSTEM
DEVELOPMENT
 Figure depicting a high‐level flow of a
typical embedded system development
cycle
 Hardware software partitioning done at
early stage
 Limits hardware
h d software
f optimization
 Less interaction between hardware and
software teams
 Software and hardware teams build “a wall”
b
between them
h early
l
 HW and SW development happens serially
or in parallel
 Usuallyy the hardware design g first and
“Throw it over the Wall” strategy followed
 Once the hardware and software are
ready, the integration is performed
 Led to the philosophy of let the “the
the software
fix the hardware problems” 27
 TRADITIONAL EMBEDDED SYSTEM
DEVELOPMENT…
 Interactions between Software and hardware
determined and discovered later in the development
 Which might lead to poor quality designs, last second
modifications slipped schedules,
modifications, schedules costly design changes,
changes the
need for routine updates to correct problems over the
product’s lifetime and possibly cancelled project
 S h development
Such d l t cycle
l puts
t an increased
i d demand
d d that
th t
 Errors be identified and corrected early
 Requirements
q be veryy well established and understood p
prior
to the start of the design
 Where could it be applied ?
 I smallll embedded
In b dd d System
S t d i and
design d development
d l t 28
 CONTEMPORARY EMBEDDED SYSTEM
DEVELOPMENT
 Contemporary methodologies favor the combined and
“ i lt
“simultaneous”
” design
d i off both
b th the
th hardware
h d and
d the
th
software components
 To meet system‐level requirements through trade‐offs between
these two
 The key points of such approach are to specify and
(iteratively) design and develop both aspects of the system
concurrently with the goals of
 Increased productivity
 Reduced design cycle time and
 Improved product quality
 Such concurrency demands greater cooperation between all
designers
 Today delivering secure, robust, reliable, and well‐designed
embedded applications demand the modern hardware hardware‐
software co‐design approach 29
 CONTEMPORARY EMBEDDED SYSTEM
DEVELOPMENT…
 Permits both the hardware and the software to influence the
design during early stages of development
 Supports a continual verification of the design and design
alternatives throughout the development cycle
 Supports and encourages models and the interoperability of
hardware and software design tools throughout process,
particularly
ti l l during
d i architecture
hit t d fi iti
definition
 Enables greater exploration of design trade‐offs and more
interesting architectures
 Essential to the Co‐Design methodology was the use of
computer‐based tools and models
 Tools to model our designs,
designs to perform simulations,
simulations and to simplify
30
and interactively optimize the hardware, software, and firmware
 CONTEMPORARY EMBEDDED SYSTEM
DEVELOPMENT…

 A high‐level
g flow through
g the
contemporary Co‐Design
development cycle is depicted
in the figure
 The figure presents and
identifies the major elements of
the process
th
 The focus of the methodology
is on the design
g and synthesis
y
aspects
 Its domain is indicated in the
b d portion
boxed ti 31
COMPARISON AND APPLICATION AREAS
 Readingg Assignment
g
 Compare traditional and co‐design embedded system
development approaches exhaustively in a tabular format

32
End of Chapter 2

33