EC8791

EMBEDDED AND REAL

TIME SYSTEMS
 UNIT I INTRODUCTION TO EMBEDDED
SYSTEM DESIGN

Complex systems and micro processors

Embedded system design process
Design example: Model train controller
Design methodologies
 Design flows - Requirement Analysis –Specifications-
System analysis and architecture design
Quality Assurance techniques
Designing with computing platforms
 consumer electronics architecture
 platform-level performance analysis.
 What is an Embedded System (ES)?
Embedded basically reflects the facts that they are an integral part of
the system.

“ It is a computer system that is built to control one or a few dedicated

functions, and is not designed to be programmed by the end user in
the same way that a desktop computer is”

It Contains processing cores that are either Micro-controllers or DSPs.

“An embedded system is some combination of computer hardware

and software, either fixed in capability or programmable, that is
specifically designed for a particular function.”
What is an Embedded System (ES)? Contd…

“Computing systems performing specific tasks within a

framework of real-world constraints”

“An Embedded System is a microprocessor based system

that is embedded as a subsystem, in a larger system
(which may or may not be a computer system).”

“An ES is designed to run on its own without human

intervention, and may be required to respond to events
in real time”
 Application of ES

Automotive: ECS, ABS; Aircraft

Network Appliances: Routers, Modems
Cell Phones, PDA, Mouse, E-Star Power
Printers, Hand Mixers, Toasters!
 What is a real time system?
• A real-time system is one that must process
information and produce a response within a
specified time, else risk severe consequences,
including failure.
 Modern Embedded Systems

DSP Application Analog

Code Specific Gates I/O

Processor
Memory
Cores

• Embedded systems employ a combination of

– application-specific h/w (boards, ASICs, FPGAs etc.)
• performance, low power
– s/w on prog. processors: DSPs, controllers etc.
• flexibility, complexity
– mechanical transducers and actuators
 INTRODUCTION TO EMBEDDED COMPUTING AND ARM
PROCESSORS

We first need to understand how and why microprocessors are

used for control, user interface, signal processing, and many other
tasks.

The microprocessor has become so common that it is easy to

forget how hard some things are to do without it.
 COMPLEX SYSTEMS AND MICROPROCESSORS

Embedded Computer System:

“It is any device that includes a programmable computer but

is not itself intended to be a general-purpose computer”.

Thus a PC is not itself an embedded computing system,

although PCs are often used to build embedded computing
systems.
But a fax machine or a clock built from a microprocessor is
an embedded computing system.
EX: Automobiles, cell phones, and even household
appliances
COMPLEX SYSTEMS AND MICROPROCESSORS contd…

Designers in many fields must be able to identify where microprocessors can be used,
design a hardware platform with I/O devices that can support the required tasks, and
implement software that performs the required processing.

Embedding Computers

Characteristics of Embedded Computing

Applications: output analog
Complex algorithms
User interface (Sophisticated functionality)
Real time input analog
Multirate CPU
Manufacturing cost
Power and energy
Finally, most embedded computing systems are mem
designed by small teams on tight deadlines. embedded
computer
CODESIGN LADDER
COMPLEX SYSTEMS AND MICROPROCESSORS contd…

Why Use Microprocessors?

■ Microprocessors are a very efficient way to implement digital systems.
■ Microprocessors make it easier to design families of products that can be built
to provide various feature sets at different price points and can be extended to
provide new features to keep up with rapidly changing markets.
■ Microprocessors execute programs very efficiently.
Modern RISC processors can execute one instruction per clock cycle most of
the time, and high performance processors can execute several instructions per
cycle (MIPS).
■ Microprocessor manufacturers spend a great deal of money to make their CPUs
run very fast.
■ Microprocessors generally dominate new fabrication lines because they can be
manufactured in large volume and are guaranteed to command high prices.
■ Microprocessors are very efficient utilizers of logic. The generality of a
microprocessor and the need for a separate memory may suggest that
microprocessor-based designs are inherently much larger than custom logic
designs
COMPLEX SYSTEMS AND MICROPROCESSORS contd…

Why not use PCs for all embedded computing?

PCs are widely used and provide a very flexible programming

environment. Components of PCs are, in fact, used in many
embedded computing systems.

1. Real-time performance requirements often drive us to different

architectures.

2. Low power and low cost also drive us away from PC architectures
and toward multiprocessors. Personal computers are designed to
satisfy a broad mix of computing requirements and to be very
flexible. Those features increase the complexity and price of the
components. They also cause the processor and other components
to use more energy to perform a given function.
COMPLEX SYSTEMS AND MICROPROCESSORS contd…

Challenges in Embedded Computing System Design

How much hardware do we need?

How do we meet deadlines?
How do we minimize power consumption?
How do we design for upgradability?
Does it really work? (Reliability)
■ Complex testing
■ Limited observability and controllability
■ Restricted development environments
COMPLEX SYSTEMS AND MICROPROCESSORS contd…

Performance in Embedded Computing

In order to understand the real-time behavior of an embedded computing
system, we have to analyze the system at several different levels of abstraction

Those layers include:

■ CPU: The CPU clearly influences the behavior of the program,
particularly when the CPU is a pipelined processor with a cache.

■ Platform: The platform includes the bus and I/O devices. The
platform components that surround the CPU are responsible for
feeding the CPU and can dramatically affect its performance.

■ Program: Programs are very large and the CPU sees only a small
window of the program at a time. We must consider the structure
of the entire program to determine its overall behavior.
 Contd….

■ Task: We generally run several programs simultaneously on a

CPU, creating a multitasking system. The tasks interact with each
other in ways that have profound implications for performance.

■ Multiprocessor: Many embedded systems have more than one

processor— they may include multiple programmable CPUs as well
as accelerators. Once again, the interaction between these
processors adds yet more complexity to the analysis of overall
system performance.
THE EMBEDDED SYSTEM DESIGN PROCESS
 THE EMBEDDED SYSTEM DESIGN PROCESS
Embedded system design process aimed at two objectives:

1. It will give us an introduction to the various steps in embedded

system design before we delve into them in more detail.
2. It will allow us to consider the design methodology itself.

A design methodology is important for three reasons. ,

First, it allows us to keep a Scorecard on a design to ensure that we have done
everything we need to do, such as optimizing performance or performing
functional tests.
Second, it allows us to develop computer-aided design(CAD) tools. Developing
a single program that takes in a concept for an embedded system and emits a
completed design would be a daunting task, but by first breaking the process into
manageable steps, we can work on automating (or at least semi automating) the
steps one at a time.
Third, a design methodology makes it much easier for members of a design
team to communicate.
THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

The major goals of the design:

■ manufacturing cost
■ performance (both overall speed and deadlines); and
■ power consumption.

We must also consider the tasks we need to perform at every step in

the design process. At each step in the design, we add detail:

■ We must analyze the design at each step to determine how we

can meet the specifications.
■ We must then refine the design to add detail.
■ And we must verify the design to ensure that it still meets all
system goals, such as cost, speed, and so on.
 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

1. Requirements

-Creating the architecture and components.

-First, we gather an informal description from the customers known
as requirements, and we refine the requirements into a specification
that contains enough information to begin designing the system
architecture.

Requirements may be functional or nonfunctional

Typical nonfunctional requirements include:
■ Performance
■ Cost (manufacturing cost ; Nonrecurring engineering(NRE) costs)
■ Physical size and weight
■ Power consumption
THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

Sample requirements form.

THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

EX:
GPS Moving Map

What requirements might we have

for our GPS moving map?
 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

Here is an initial list:

■ 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.
■ 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.
THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

Finally the Requirement form,

 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
2.Specification

Specification serves as the contract between the customer

and the architects.

Specification is probably the least familiar phase of this

methodology for neophyte designers, but it is essential to creating
working systems with a minimum of designer effort.

The specification should be understandable enough so that

someone can verify that it meets system requirements and overall
expectations of the customer.
 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..

A specification of the GPS system would include several components:

■ Data received from the GPS satellite constellation.

■ Map data.
■ User interface.
■ Operations that must be performed to satisfy customer requests.
■ Background actions required to keep the system running, such as
operating the GPS receiver.
 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
3. Architecture Design
The specification does not say how the system does things, only
what the system does. Describing how the system implements those
functions is the purpose of the architecture.

The architecture is a plan for the overall structure of the system that
will be used later to design the components that make up the
architecture.

The creation of the architecture is the first phase of what many

designers think of as design.
 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
3. Architecture Design

Figure below shows a sample system architecture in the form of a block

diagram that shows major operations and data flows among them.

Architectural descriptions must be designed to satisfy both functional and

nonfunctional requirements. Not only must all the required functions be
present, but we must meet cost, speed, power,and other nonfunctional
constraints.
Starting out with a system architecture and refining that to hardware and
software architectures,
THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
3. Architecture Design

Hardware

Software
THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
4. Designing Hardware and Software Components

The components will in general include both hardware—FPGAs, boards, and so on and
software modules.

Some of the components will be ready-made.

You will have to design some components yourself.

 THE EMBEDDED SYSTEM DESIGN PROCESS Contd..
5. System Integration
Bugs are typically found during system integration, and good planning can help us find
the bugs quickly.

By building up the system in phases and running properly chosen tests, we can often find
bugs more easily.

If we debug only a few modules at a time, we are more likely to uncover the simple bugs
and able to easily recognize them.

System integration is difficult because it usually uncovers problems. It is often hard to

observe the system in sufficient detail to determine exactly what is wrong— the
debugging facilities for embedded systems are usually much more limited than what you
would find on desktop systems. As a result, determining why things do not stet work
correctly and how they can be fixed is a challenge in itself.

Careful attention to inserting appropriate debugging facilities during design can help
ease system integration problems, but the nature of embedded computing means that
this phase will always be a challenge.
 WHY DESIGN METHODOLOGIES?

 the complete design methodology—a design process (steps)—for

embedded computing systems.
 If you are designing embedded systems in your basement by
yourself, having your own work habits is fine. 
 But when several people work together on a project, they need to
agree on who will do things and how they will get done
 many embedded computing systems are too complex to be
designed and built by one person, we have to think about design
processes
 Product metrics

The obvious goal of a design process is to create a product that

does something useful.
Typical specifications for a product will include
 functionality
performance
power consumption
A design process has several important goals beyond function,
performance, and power:

Time-to-market.
Design cost.

Quality.
•Processes evolve over time.
•They change due to external and internal forces.
•Customers may change, requirements change, products change,
and available components change.
•Internally, people learn how to do things better, people move on
to other projects and others come in, and companies are bought
and sold to merge and shape corporate cultures.
•A good methodology is critical to building systems that work
properly.
•Delivering buggy systems to customers always causes
dissatisfaction. But in some applications, such as medical and
automotive systems, bugs create serious safety problems that can
endanger the lives of users
Example 7.1 Loss of the Mars Climate Observer
In September 1999, the Mars Climate Observer, an unmanned U.S.
spacecraft designed to study Mars, was lost—it most likely exploded as it
heated up in the atmosphere of Mars after approaching the planet too
closely. The spacecraft came too close to Mars because of a series of
problems, according to an analysis by IEEE Spectrum and contributing editor
James Oberg [Obe99]. From an embedded systems perspective, the first
problem is best classified as a requirements problem. The contractors who
built the spacecraft at Lockheed Martin calculated values for flight
controllers at the Jet Propulsion Laboratory (JPL). JPL did not specify the
physical units to be used, but they expected them to be in newtons. The
Lockheed Martin engineers returned values in units of pound force. This
discrepancy resulted in trajectory adjustments being 4.45 times larger than
they should have been. The error was not caught by a software
configuration process nor was it caught by manual inspections. Although
there were concerns about the spacecraft’s trajectory, errors in the
calculation of the spacecraft’s position were not caught in time.
 DESIGN FLOWS

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 computer-aided design (CAD) systems; other steps
can be performed by hand. In this section we look at the basic
characteristics of design flows.
Waterfall model
Spiral model
Successive refinement
Hierarchical design flows
Concurrent engineering
 1. Waterfall model
Introduced by Royce , the first model proposed for the software
development process.

• Early model for software development:

The waterfall model gets its name from the largely one-way flow of
work and information from higher levels of abstraction to more detailed
design steps
requirements

architecture

coding

testing

maintenance
 Waterfall model 5 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.
Most design projects entail experimentation and changes that
require bottom–up feedback. As a result, the waterfall model is
today cited as an unrealistic design process.

So, an alternative model of software development called the

spiral model .
2.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.
• A spiral methodology with too many spirals may
take too long when design time is a major
requirement.
 Successive refinement model

specify specify

architect architect

design design

build build

test test

initial system refined system

The system is built several times. A first system is used as a rough prototype,
and successive models of the system are further refined.
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.
A hierarchical design flow for an embedded system.
 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.
• Early and continual supplier involvement
• Early and continual customer focus
 Requirements analysis
• Requirements: informal description of what
customer wants.
• Specification: precise description of what design
team should deliver.
• The overall goal of creating a requirements
document is effective communication between
the customers and the designers. The designers
should know what they are expected to design for
the customers
 Types of requirements

• Functional: input/output relationships.( FFT )

• Non-functional:
– timing;
– power consumption;
– manufacturing cost;
– physical size;
– time-to-market;
– reliability.
 A good set of requirements should meet
several tests
• Correctness.
• Unambiguousness.
• Completeness.
• Verifiability: is each requirement satisfied in the final
system?
• Consistency: requirements do not contradict each other.
• 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.
 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.
 1.SDL

• State machine specification

language is the SDL telephone
language which was on-hook

developed by the
caller goes
communications industry off-hook

for specifying
communication protocols, dial tone

telephone systems, and so

caller gets
forth. dial tone

• Event-oriented state
machine model.
The SDL specification language
 2.State charts
Other techniques can be used to eliminate clutter and clarify the
important structure of a state-based specification. The State chart is
one well-known technique for state-based specification

• Ancestor of UML state diagrams.

• Provided composite states:
– OR states;
– AND states.
• Composite states reduce the size of the state
transition graph.
 State chart OR state
s123
i1 i1

S1 S1
i2

i1 i1 i2
i2
S2 S4 S2 S4

i2

S3 S3

traditional OR state
 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
 3. AND-OR tables
Leveson et al. [Lev94] used a different format, the AND/OR table,
to describe similar relationships between states

• Alternate way of specifying complex conditions:

OR

cond1 T -
AND cond2 - T
cond3 - F
System analysis and architecture design

• In this section we consider how to turn a

specification into an architecture design.
• we look at how to get a handle on the overall
system architecture.
• The CRC card methodology is a well-known and
useful way to help analyze a system’s structure.
• It is particularly well suited to object-oriented
design since it encourages the encapsulation of
data and functions.
 CRC cards

• The acronym CRC stands for the following

three major items that the methodology tries
to identify: CRC:
– Classes;
– Responsibilities of each class;
– Collaborators are other classes that work with a
class.
• Team-oriented methodology.
 CRC card format

Class name: Class name:

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

front back
The CRC card methodology is informal, but we should go
through the following steps when using it to analyze a
system:

• 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.
 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.
 EX: 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.
Elevator responsibilities and collaborators

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
 Quality Assurance
The quality of a product or service can be judged by how well it
satisfies its intended function.
The quality assurance (QA) process is vital for the delivery of a
satisfactory System.
In this section we will concentrate on portions of the methodology
particularly aimed at improving the quality of the resulting system.

“The pursuit of quality extends throughout the design flow.”

For example, settling on the proper requirements and
specification cannot be overlooked as an important determinant of
quality.

Quality assurance (QA) makes sure that all stages of the design
process help to deliver a quality product.
 Quality Assurance Techniques
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.