Download Introduction to Embedded Systems

Introduction to Embedded
Systems
EE 454 Embedded Architectures


Necessity is not the mother of
invention…
Laziness is!!
New Gadgets define needs
What is an Embedded System

An embedded system contains a
computer as part of a larger system and
does not exist primarily to provide
standard computing services to a user.
Definition




A special-purpose computer system
Designed to perform one or a few
dedicated functions, sometimes with
real-time computing constraints.
Usually containing sensors and
actuators (and its control loop)
Usually embedded as part of another
system
Characteristics of Embedded
Systems

Must be dependable:





Reliability: R(t) = probability of system working
correctly provided that is was working at t=0
Maintainability: M(d) = probability of system
working correctly d time units after error occurred.
Availability: probability of system working at
time t
Safety: no harm to be caused
Security: confidential and authentic
communication
Characteristics of Embedded
Systems (cont’)

Must be efficient:


Energy efficient
Code-size efficient (especially for systems
on a chip)



Run-time efficient
Weight efficient
Cost efficient
Characteristics of Embedded
Systems (cont’)

Many of them must meet real-time
constraints:


A real-time system must react to stimuli
from the controlled object (or the operator)
within the time interval dictated by the
environment.
For real-time systems, right answers
arriving too late (or even too early) are
wrong.
Characteristics of Embedded
Systems (cont’)



Unlike the general purpose computers,
an embedded computer must interact
with a wide variety of analog and/or
digital devices.
Our old friends Maxwell, Faraday,
Gauss, and Lenz are there to quickly
point out when we’ve violated one of
their laws!!
Solving problems are arising from
signal coupling, noise, electromagnetic
interference, or propagation delays is
challenging, but necessary.
Boeing conducted electromagnetic
interference testing for the EA-18G
program at Patuxent River, Md.
Comparison

Embedded Systems




Few applications that are
known at design-time.
Not programmable by
end user. (?)
Fixed run-time
requirements (additional
computing power not
useful).
Criteria:




cost
power consumption
predictability
…

General Purpose
Computing




Broad class of
applications.
Programmable by end
user.
Faster is better.
Criteria:


cost
average speed
System Specialization


The main difference between general purpose
highest volume microprocessors and embedded
systems is specialization.
Specialization should respect flexibility



application domain specific systems shall cover a class of
applications
some flexibility is required to account for late changes,
debugging
System analysis required


identification of application properties which can be used for
specialization
quantification of individual specialization effects
Design Issues




In addition to the design of instruction
set, CPU datapath, CPU control,
memory, I/O,
Cost efficiency (least expensive
computers able to meet the functional
and performance requirements
Recurring cost (strategy: low hardware
cost, high software development cost)
Real Time Constraints (soft, hard, firm)
Design Issues (cont’)

Programming





Array allocation, algorithmic optimization
Cross compiler tools (more buggy)
I/Os are hard to simulate
Validation and testing are more difficult
Robustness and reliability(e.g. cardiac
pacemaker, unmanned space probes,
avionics controllers)
Application Specific Instruction
Sets


Example: Multimedia-Instructions
Multimedia instructions exploit that many registers, adders etc are quite
wide (32/64 bit), whereas most multimedia data types are narrow (e.g. 8
bit per color, 16 bit per audio sample per channel) " 2-8 values can be
stored per register and added. E.g.:
64 bits
Word 3
Word 2
64 bits
Word 1
Word 0
Word 3
+
Word 2
Word 1
Word 1
Word 0
4 additions per instruction;
carry disabled at word
boundaries.
64 bits
Word 3
Word 2
Word 0
Typical Architecture
VLIW Technology


Key idea: detection of possible parallelism
to be done by compiler, not by hardware
at run-time (inefficient).
VLIW: parallel operations (instructions)
encoded in one long word (instruction
packet), each instruction controlling one
functional unit.

Example:
TriMedia Nexperia
PNX1300
Field-programmable
gate array (FPGA)



A semiconductor device
containing programmable logic
components called "logic blocks",
and programmable interconnects.
Logic blocks can be programmed
to perform the function of basic
logic gates such as AND, and
XOR, or more complex
combinational functions such as
decoders or simple mathematical
functions.
In most FPGAs, the logic blocks
also include memory elements,
which may be simple flip-flops or
more complete blocks of
memory.
Application Specific Integrated
Circuits (ASIC)

Custom-designed circuits necessary



if ultimate speed or energy efficiency
is the goal and
large numbers can be sold.
Approach suffers from



long design times,
lack of flexibility (changing standards)
and
high costs
Image Signal Processor ASIC for High-Quality CCD Camera
System on a Chip (SoC)


SoC or SOC refers to
integrating all components of
a computer or other electronic
system into a single integrated
circuit (chip).
It may contain digital, analog,
mixed-signal, and often radiofrequency functions – all on
one chip. A typical application
is in the area of embedded
systems.
SoC: PXA270
Memory Technology
Challenges



Capacity
Size - mobility
Power consumption
Concurrency and Scheduling



High-level tasks spawn lower-level
activities (concurrency)
Single processor can only do one task a
time
Scheduling is needed
Major Aspects in Development
of Embedded Applications






Digital hardware and software architecture
Formal design, development, and
optimization process
Safety and reliability
Digital hardware and software/firmware
design
Interface to physical world analog and digital
signals
Debug, troubleshooting, and test of the
design
Modeling


A model is an integrated set of
abstractions and their internal relations
Can be expressed in modeling
languages


Syntax
Semantics
Time, Performance, and Quality
of Service

In 2002, the Object Management Group
(OMG) adopted the Unified Modeling
Language™ (UML) profile that provided
a standardized means for specifying
timeliness, performance, and
schedulability aspects of systems and
parts of systems, the so-called RealTime Profile (RTP)
Actions &
Concurrency
Timing Constraints
 Hard
 Soft
Actions – initiated by events
Message (event) Arrival Pattern
 Periodic
 Aperiodic (episodic)



Bounded
Burst irregular
Stochastic
Concurrency

Concurrency - actions executed at the
same time

Synchronization patterns describe how
different concurrent actions rendezvous
and exchange messages
Resources


An element whose (computational)
service capacity is limited
Must take into account the block time
(priority scheduling issues…)
Time

An ordered series of time instants



Duration, or
Time intervals
Measuring time:

Clocks



With a starting origin
May have offset, skew, drift
Timers – generate timeout events, then be
reset
Time (cont’)


Clock interrupt: periodic, representing
fundamental timing frequencies
Timeout event: result of achieving a
specified time from the start of the
timer
Schedulability




Stable: a-priori prediction
of failure of task scheduling
if overloaded
Optimal: best solution
Responsive: tasks handled
in a timely way
Robust: the timeliness of
one task is not affected by
the misbehavior of another
Whenever a scheduling
event occurs (task finishes,
new task released, etc.) the
queue will be searched for
the process closest to its
deadline. This process is the
next to be scheduled
Forming Critical
Section for atomic
access of shared
resource
Enforced by mutex
Performance

Workload






Computation,
Communication
Context switch
Access time
Response time
Throughput
Architectures
Rapid ObjectOriented Process
for Embedded
Systems
(ROPES)
Systems Engineering vs. Software
Engineering

The primary activities encompassed by
systems engineering include





Capturing, specifying and validating the
requirements of the system as a whole
Specification of the high-level subsystem
architecture
Definition of the subsystem interfaces and
functionality
Mapping the system requirements onto the
various subsystems
Decomposing the subsystems into the various
disciplines—electronic, mechanical, software, and
chemical—and defining the abstract interfaces
between those aspects
The Rapid Object-Oriented Process
for Embedded Systems (ROPES)
Process

The ROPES process exists on three time
scales simultaneously:



Macro— The entire length of the project, typically
one to several years
Micro— The time required to produce a single
increment or version of the system that achieves
some targeted functionality—typically four to six
weeks
Nano— The time needed to produce, compile,
execute, and/or test some very small portion of
the system—typically 30 minutes to an hour
Example (ROPES) Process
Figure 1-8
and Table 1-5
Model-Driven Development (MDD)



Iterative Development— Iterative
development is based on the concept of
incremental construction.
Use of Models— Large, complex systems
can't be effectively constructed using only
source-code-level constructs.
Model-Code Bidirectional Associativity— For
model-based systems, it is absolutely crucial
that the code and the diagrams are different
views of the very same underlying model.


Executable Models— You can only test
things that execute—therefore, build
primarily executable things, both early
and often.
Debug and Test at the Design Level of
Abstraction— Because today's
applications are extremely complex, we
use abstract design models to help us
understand and create them.

Test What You Fly and Fly What You
Test— Simulation has its place, but the
purpose of building and testing
executable models is to quickly develop
defect-free applications that meet all of
their functional and performance
requirements.
MDA and Platform-Independent
Models


A model may support any number of different
views. A UML class diagram may show a
number of classes interacting together to
realize a use case.
Another class diagram may show the same
class in a generalization taxonomy. Still
another class diagram may show how the
class fits within its domain of interest.
MDA and Platform-Independent
Models


An executable model is a model that is
defined with a rich enough set of semantics
that its execution behavior is predictable. One
can argue that any model that can be
represented ultimately as executable machine
code is, in fact, an executable model.
MDA is an approach that separates aspects of
a model that are independent of underlying
technologies from those that are dependent
upon those aspects.
MDA and Platform-Independent
Models

The platform-independent model (PIM)
is constructed to be independent of the
processor(s) on which it runs, the
communication infrastructure (such as
Ethernet and TCP/IP), middleware
(such as COM or CORBA), and even the
implementation language (such as C or
Ada).
Scheduling Model-Based Projects

Why Schedule?







When will the project be done?
How much will it cost?
Is this project likely to provide a good return on
investment (ROI)?
Should I invest in this project or another project?
How many resources must I apply to it?
Do I need to hire people and if so, with what skills?
When should I begin ancillary activities, such as
gearing up manufacturing, starting the marketing
campaign, beginning the next project?
Scheduling
Model-Based Projects

Estimation

BERT: Bruce’s Evaluation and Review Techniques

ERNIE: Effect Review for Nanocycle Iteration Estimation
BERT
ERNIE
Working with Model-Based
Projects




Company's (or project's) software
development plan (SDP).
One of the key activities in the daily workings
of a project is configuration management
(CM).
In a model-based project, the primary artifact
being configured with the CM system is the
model.
UML supports the modeling needs.
Embedded Software Design
Architecture Analysis





Hardware Fundamentals
Processor Instructions
Getting Started
Interrupts
Detailed Design




Software Architectures
Peripherals
Real-time OS