OUTLINE

 Introduction
 Design Challenges
CHAPTER 2  Design Process
EMBEDDED SYSTEM DESIGN  Example
PROCESS  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
1

INTRODUCTION DESIGN CHALLENGES AND CONSTRAINTS

 ESD is unlike the design/development
g / p of application
pp on  An ES Designer must construct an implementation that fulfills
standard platform, where the hardware is a done deal the desired functionality that simultaneously optimizes
numerous design metrics (parameters that define design
requirements)
 ESD requires both Hardware and Software to be  Common design metrics used in embedded systems are
designed in Parallel/Serially  Unit cost, NRE cost, size, performance, power, flexibility, time to
market, time to prototype, correctness, safety , flexibility,
 An ESD projects are usually an optimization exercise that maintenance…
maintenance

strive to create both hardware and software, that  To best meet the optimization challenge the designer must be
 An expert in HW/SW technologies
complement
p each other
 FFamiliar
ili with
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
 Embedded systems projects aren’t just either “software
on small machines.
machines ” nor “writing
writing ‘C’
C code
code” 3  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 DESIGN PROCESS…
 Major
j abstraction levels of the design
g pprocesses are  Two types of design process
 Top‐Down
 Requirements, Specification, Architecture, Components,  Bottom‐Up
System Integration
 These are important steps in developing an embedded  Top Down
Top‐Down
system  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
5  Most preferred approach for beginners 6

DESIGN PROCESS… DESIGN PROCESS – REQUIREMENTS…

 Requirements
q  Requirement
q analysis
y of bigg systems
y can be complex
p and
 Are informal descriptions gathered from customers time consuming
 Before designing the system know the system you are  However, capturing a relatively small amount of
building i f
information
ti i a clear,
in l simple
i l format
f t is
i a good
d start
t t
 Can be of two types toward understanding system requirements
 Functional  A requirement form as shown below could be used when the
 Non‐Functional project is in the initial stage and acts like a checklist
 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 8
 DESIGN PROCESS – REQUIREMENTS… DESIGN PROCESS – REQUIREMENTS…
 Requirements Form entries  Requirements Form entries…

 Name  Performance
 Essential that the performance requirements be identified early since they must
 Giving a name to the project not only simplifies talking about it to be carefully measured during implementation, to ensure that the system works
other people but can also crystallize the purpose of the machine properly
 Purpose  Manufacturing cost
 Includes primarily the cost of the hardware components
 This should be a brief one or two‐line description of what the system is  You should have some idea of the eventual cost range
supposed to do
 Power
 Inputs and outputs  A rough idea of how much power the system can consume would be helpful.
 Encompass a wealth of detail  Decision whether the machine will be battery powered or plugged into the wall
 Types of data: Analog electronic signals? Digital data? Mechanical inputs? will be based on this information
 Data characteristics: Periodically arriving data, such as digital audio samples?  Physical size and weight
Occasional user inputs? How many bits per data element?  Give some indication of the physical size of the system to help guide certain
 Types of I/O devices: Buttons? Analog/digital converters? Video displays? architectural decisions
 A desktop machine has much more flexibility in the components used than, for
 Functions 9 example,
l a lapel
l l mounted
t d voice
i recorder
d 10
 A more detailed description of what the system does

DESIGN PROCESS – REQUIREMENTS… DESIGN PROCESS – REQUIREMENTS…

 Example:
p Requirements
q analysis
y of a GPS movingg map
p  Example: Requirements analysis of a GPS moving map – Initial
Requirement Form
 The moving map is a handheld device that displays for the user a map  Functionality
of the terrain around the user’s current position  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
 The map display changes as the user and the map device change major roads and other landmarks available in standard topographic databases.
position. The moving map obtains its position from the GPS, a satellite‐  User interface
 The screen should have at least 400600 pixel resolution. The device should be
based navigation system 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.
 The moving map display might look something like figure below
 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.
11 12
 DESIGN PROCESS – REQUIREMENTS… DESIGN PROCESS – SPECIFICATIONS
 Example:
p Requirements
q analysis
y of a GPS movingg map
p‐  Refinement of the requirements
 More detailed description of what we want
Initial Requirement Chart  States only how the system behaves, not how it is built
 Using Engineering terms  does not say how the system does things, only what the system does
 keeping a record of what the customer wants can help to resolve  More precise
p
 Should also be unambiguous enough that designers know what they need to
questions about the specification that may crop up later during build
design  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
13 meets system requirements and overall expectations of the customer 14

DESIGN PROCESS – SPECIFICATIONS… DESIGN PROCESS – SPECIFICATIONS…

 Example:
p Specifications
p of GPS movingg map
p – Include  Comparison
p of the focus of Requirement
q and
several components Specification
 Operations that must be performed to satisfy customer Requirements Specifications
requests
An informal description gathered from A contract between customer and system
 Background actions required to keep the system running, customer architects
such as operating the GPS receiver Requirement form used to give a formal UML is used to give clear and proper
listing of the requirements specifications
 Data received from the GPS satellite constellation
The basic needs to design a system are The description of a project is given by
 Map data given by system requirements system specification
 User interface 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
 UML would
ld b
be used
d to prepare specifications
ifi i 15
produce good system requirements produce good specifications
16
 DESIGN PROCESS – ARCHITECTURE DESIGN PROCESS – ARCHITECTURE…
 Ap plan for the overall structure of the system
y that will be  Example:
p Architecture of GPS movingg map
p – System
y
used later to design the components that make up the Architecture
architecture  Figure below shows a sample system architecture in the form
 Its
It purpose is i describing
d ibi how
h th system
the t i l
implements t of a block diagram that shows major operations and data
flows among them
the functions stated in the specifications
 The block diagram is still abstract, does not specify which operation
 The creation of the architecture is the first p phase of will be performed by software running in a CPU,
CPU what to be done by
what many designers think of as design special purpose software. Yet goes a long way towards describing
how to implement the functions described in the specifications
 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 18

DESIGN PROCESS – ARCHITECTURE… DESIGN PROCESS – ARCHITECTURE…

 Example: Architecture of GPS moving map – System  Example:
p Architecture of GPS movingg map
p – Hardware
Architecture…
 Consists of one central CPU surrounded by memory and I/O
 The block diagram explains about
devices
 The GPS navigation system where GPS receiver gets the current position
and the destination is taken from the user  Two memories used
 Digital map from source to destination is found from database and  The frame buffer holds the pixel to be displayed
displayed by the renderer
 Another memory for program/data which will be used by the CPU
 The block diagram clearly shows that we need to search the
 The
Th bus
b interconnects
i t t allll these
th componentst
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 20
 One for Hardware and another for Software
 DESIGN PROCESS – ARCHITECTURE… DESIGN PROCESS – ARCHITECTURE…
 Example:
p Architecture of GPS movingg map
p – Software  To have a truly complete architectural description, more
 This block diagram is the same as the initial architecture, detail designs are required such as
with additional timer, which is used to control when we read  Where units in the software block diagram will be executed in the
the buttons on the user interface and render data onto the hardware block diagram
screen  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
21  Consider the non‐functional constraints when creating the 22
hardware and software architecture

DESIGN PROCESS
DESIGN PROCESS – ARCHITECTURE… HARDWARE AND SOFTWARE COMPONENTS
 How do we know our HW and SW architectures meet  The architectural description tells us what components we need
design metrics ?  The component design effort builds those components in
 Estimate the properties of the components of the block conformance to the architecture and specification
diagram  The components will in general include both HW & SW modules
 Accurate estimation derives from experience  Some of the components will be ready‐made (CPU, memory
 Create simplified models for more accurate estimations chips…)
 When creating Embedded SW module,
module ensure the system runs on
properly in real time, and doesn’t take more memory space
 Sound estimates of all non‐functional requirements
 Carefully analyze the power consumption
during the architecture phase are crucial, since decision  E
Example:
l Memory
M transactions
i must be
b carefully
f ll planned
l d to avoid
id reading
di
based on bad data will show up during the final phase of the same data several times, since memory accesses are the major source
design of power consumption

23 24
 DESIGN PROCESS
HARDWARE AND SOFTWARE COMPONENTS… DESIGN PROCESS - SYSTEM INTEGRATION
 Example: Hardware and Software component of GPS moving map  Deal with the integration/assembly of the components created
 GPS receiver  After the components are built, they are integrated
 A predesigned standard HW component  Bugs are typically found during system integration
 Topographic
p g p software  However, good planning, phase level development, good test runs
 A standard SW module with standard routines to access DB at each phase can assist in finding bugs well/early
 PCB  By debugging few simple bugs early, more complex or other bugs
 Houses custom and off
off‐the
the shelf components can be uncovered
 Lots of custom programming also required  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
25 26

TRADITIONAL EMBEDDED SYSTEM TRADITIONAL EMBEDDED SYSTEM

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

CONTEMPORARY EMBEDDED SYSTEM

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

33