Chapter 4: Embedded Systems

Design Issues
 10.1 Introduction
 Embedded systems are different from general-
purpose systems in several important ways. Some key
differences are:
 Embedded systems are resource constrained. Utilization
of memory and power are critical. The economy of
hardware and software is often paramount, and can affect
design decisions.
 Partitioning of hardware and software is fluid.
 Embedded systems programmers must understand every
detail about the hardware.
 Signal timing and event handling are crucial.
 10.1 Introduction
 The design process for embedded systems is a systems
engineering process that has to consider, in detail, the design and
performance of the system hardware.
 Part of the design process may involve deciding which system
capabilities are to be implemented in software and which in
hardware.
 Low-level decisions on hardware, support software and system
timing must be considered early in the process.
 These may mean that additional software functionality, such as
battery and power management, has to be included in the system.
 10.1 Introduction
 Real-time systems are often considered to be reactive
systems
 Given a stimulus, the system must produce a reaction or
response within a specified time.
 Periodic stimuli - Stimuli which occur at predictable time
intervals
 For example, a temperature sensor may be polled 10 times per
second.
 Aperiodic stimuli -Stimuli which occur at unpredictable
times
 For example, a system power failure may trigger an interrupt which
must be processed by the system
 Stimuli come from sensors in the systems environment and
from actuators controlled by the system
 1.Design Requirements
 In general, an embedded system design must consider the
following :
1. It should handle real time operations and react to external events
2. It should conform to size and weight limits
3. It should be within the power budget and cooling requirements.
4. It should satisfy safety and reliability requirements
5. It must meet tight cost targets.
 Con..
1.1 Real time/Reactive operation
In real time system, it needs to work quickly but correctly.

Real time system operation means that the correctness of a

computation depends, in part, on the time at which it is delivered.

System design must consider worst case performance also On
complicated architectures, predicting worst case performance is
difficult.
Examples of the Real time operations are Signal Processing and

Mission Critical Systems.

In Reactive operation, software executes in response to an external

event . These events can either be periodic or aperiodic.

Periodic events results in guaranteed performance whereas

aperiodic events may end up with the worst case situations.

 Con…
1.2 Small size and Low weight
Embedded computers are physically located within artifacts .

If the shape is non-rectangular and non-planar geometries, then it is

difficult to reduce the size as well as its weight. Packaging and

integration of digital, analog and power circuits will lead to reduction in
size.
1.3 Safe and reliable
 Embedded system failures may result in severe damages.

For example in mission critical applications such as aircraft flight

control, embedded system failures may result in severe personal injury

and equipment damage.
Embedded system that fails cannot tolerate the added cost of

redundancy in hardware. At the same time, it cannot have processing

capacity needed for traditional fault tolerance techniques. Low-cost
reliability with minimal redundancy will be a difficult task to achieve.
 Con…
1.4 Harsh environment
 Embedded systems may not operate in a controlled environment.

They may be subject to excessive heat, vibration, shock, lightning,

power supply fluctuations, water, corrosion, fire, and general
physical abuse.
1.5 Cost Sensitivity
Cost is one of the issues in developing a system .

 A little change in cost affects the manufacturing quantity of the

system. Although designers of systems large and small may talk

about the importance of cost with equal urgency, their sensitivity to
cost changes can vary dramatically. A reason for this may be that
the effect of computer costs on profitability is more a function of
the proportion of cost changes compared to the total system cost,
rather than compared to the digital electronics cost alone.
 2. System-level requirements
 Designer should consider the End-product utility, System safety
& reliability, Controlling physical systems and Power
management .
 3. Life-cycle support
First a need or opportunity to deploy new technology is identified. Then a product
concept is developed. This is followed by concurrent product and manufacturing
process design, production, and deployment. The designer must take into account
support, maintenance, upgrades, and system retirement issues in order to actually
create a profitable design.
 Memory management
 Memory Architecture: Issues
 Types of memory - volatile vs. non-volatile, SRAM vs. DRAM
 Memory maps
Harvard architecture and Memory-mapped I/O
 Memory organization - statically allocated , stacks , heaps
(allocation, fragmentation, garbage collection)
 The memory model of C
 Memory hierarchies - scratchpads, caches, virtual memory
 Memory protection - segmented spaces
 Memory management

 Embedded system memory can consist of

several different kinds, including RAM, ROM,
and flash, all sharing the same address space.

Memory leaks in embedded systems are

especially problematic.

12
 memory hierarchy
 What is the memory hierarchy?
 Different levels of memory
 Some are small & fast
 Others are large & slow
 What levels are usually included?
 Cache: small amount of fast, expensive memory
 L1 (level 1) cache: usually on the CPU chip
 L2 & L3 cache: off-chip, made of SRAM
 Main memory: medium-speed, medium price memory (DRAM)
 Disk: many gigabytes of slow, cheap, non-volatile storage
 Memory manager handles the memory hierarchy
 Basic memory management
 Components include
 Operating system (perhaps with device drivers)
 Single process
 Goal: lay these out in memory
 Memory protection may not be an issue (only one program)
 Flexibility may still be useful (allow OS changes, etc.)
 No swapping or paging
 Fixed partitions: multiple programs
 Fixed memory partitions
 Divide memory into fixed spaces
 Assign a process to a space when it’s free
 Mechanisms
 Separate input queues for each partition
 Single input queue: better ability to optimize CPU usage
 How many programs is enough?
 Several memory partitions (fixed or variable size)
 Lots of processes wanting to use the CPU
 Tradeoff
 More processes utilize the CPU better

 Fewer processes use less memory (cheaper!)

 How many processes do we need to keep the CPU fully utilized?

 This will help determine how much memory we need

 Is this still relevant with memory costing less than $1/GB?

 Hardware development
 We will classify embedded hardware according to the
extent to which it is adapted or adaptable by the
people who program and install the system into the
device that it supports.
 Accordingly, we say that embedded hardware falls into
categories of:
 Off-the-shelf
 Configurable
 Fully-Customized
 Hardware
 Using off-the-shelf hardware, minimal hardware
customization possible.
 Perhaps add memory or peripherals. The internal wiring
stays the same.
 The most common off-the-shelf hardware is the
microcontroller.
 Microcontrollers are often derivatives of “old” PC
technology. They are inexpensive because development
costs were recouped long ago.
 There are thousands of different microcontrollers
 Hardware
 Example microcontrollers are Motorola's 68HC12, Intel’s
8051, Microchip's 16F84A, and the PIC family.
 A simplified block diagram of a microcontroller is shown at
the right.
 Hardware
 A watchdog timer helps guard against system hangs by
continually checking for live ness.
 Watchdog timers are not used in all microcontrollers.
 Hardware
 For some applications, microcontrollers are too limited
in their functionality.
 Systems-on-a-chip (SOCs) are full blown computer
systems-- including all supporting circuits-- that are
etched on a single die.
 Alternatively, separate chips are needed to provide the
same services.
 The additional chips are costly and consume power and
space.
 Hardware
 Semi-custom systems-on-a-chip can be fabricated whenever a
suitable off-the-shelf SOC is unavailable.
 The chip mask is created using blocks of pre-designed, pre-
tested intellectual property (IP) circuits.
 The semi-custom approach is costly. To save money, off-the-
shelf SOCs are preferred, even when their functionality is not
an exact fit for the application.
 Programmable logic devices (PLDs) are configurable
devices in which the behavior of the circuits can be
changed to suit the needs of an application.
 Programmable array logic (PAL) chips consist of programmable
AND gates connected to a set of fixed OR gates.
 Programmable logic array (PLA) chips consist of programmable
AND gates connected through programmable OR gates.
 Hardware

A programmed PAL and a programmed PLA:

 Hardware
 The behavior of field programmable gate arrays (FPGAs) is
controlled through values stored in memory lookup tables
rather than by changing connections between logic
elements.
 Hardware
 Truth tables are entered directly into FPGA memory.
 Hardware
 FPGAs typically consist of blocks of logic elements
interconnected by switches and multiplexers in an “island”
configuration.
 Hardware
 When:
 Off-the-shelf microcontrollers and SOCs do not have
sufficient functionality for the task at hand...
 Or off-the-shelf microcontrollers and SOCs have too much
functionality, with the excess consuming resources
needlessly…
 And a semi-custom chip cannot be economically fabricated
from commercially available IP designs...
 And PLDs are too expensive or too slow…
 The only option left is to design an application-specific
integrated circuit (ASIC) from scratch.
 Hardware
 To design a chip from scratch we need to think about it
from three points of view:
 What do we need the chip to do?
 Which logic components can provide the behavior we
need?
 What is the best way to position the components on the
silicon die in order to reduce cost and provide the best
performance?
 Hardware
 Gajski’s Logic Synthesis Y-Chart depicts the relationship of
these three dimensions of circuit design.
 Hardware
 Creating circuit designs along all three dimensions is an
enormously complex task that is nearly impossible to do--
with any amount of accuracy or effectiveness-- without a
good toolset.
 Hardware definition languages (HDLs) were invented in the
latter part of the twentieth century. HDLs help designers
manage circuit complexity by expressing circuit logic in
algorithmic terms.
 Hardware
 SystemC is an extension of C++ that includes classes
and libraries specifically created for embedded
systems design, to include modeling events, timing
specifications, and concurrency.
 SpecC is a C-like language, created from the outset
as a system design language.
 A SpecC development package includes a
methodology that guides engineers through four
phases of system development:
 Specification, architecture, communication channels, and
implementation.
 Hardware
 Embedded systems have been traditionally
developed by specialized teams that collaboratively:
 Produce a detailed specification derived from a functional
description.
 Select a suitable processor or decide to build one.
 Determine the hardware-software partition.
 Design the circuit and write the program(s) that will run on
the system.
 Prototype and test the system.
Hardware
 Hardware
 System C and Spec C facilitate changes to the
traditional design lifecycle.
 Hardware developers and software developers can speak the
same language.
 Cod Development teams work side-by-side simultaneously
creating hardware designs and writing programs.
 Cod development shortens the development lifecycle and
improves product quality.
Hardware
 What is Embedded SW?
 “Software that is directly in contact with, or significantly
affected by, the hardware that it executes on, or can directly
influence the behavior of that hardware.”
 Common Design Metrics
 Unit cost
 Size (bytes, gates)
 Performance (execution time)
 Power (more power=> more heat & less battery time)
 Flexibility (ability to change functionality)
 Time to prototype
 Time to market
 Maintainability
 Correctness
 Safety (probability that system won’t cause harm)
 software design
 The activities that may be included in a real-time
software design process:
 Platform selection - hardware and the real-time
operating system are selected. The choice depends on
timing constraints on the
system, limitations on power available, the experience of
the development team, and the price target for the
delivered system.
 Stimuli/response identification - identify stimuli and
associated response
 Timing analysis – for each hardware and the real-time
operating system identify time constraint
 software design
 Process design - aggregate the stimulus and response
processing into a number of concurrent processes.
Architectural patterns are good starting points
 Algorithm design - For each stimulus and response, design
algorithms to carry out the required computations.
 Data design - specify the information that is exchanged by
processes and the events that coordinate information exchange,
and design data structures to manage this information
exchange. Several concurrent processes may share these data
structures.
 Process scheduling - design a scheduling system that will
ensure that processes are started in time to meet their deadlines
 The order of these activities in the real-time software design
process depends on the type of system being developed, as well
as its process and platform requirements
Software development
Tools Processing
 Software development

 Software development for embedded systems

presents a distinct set of challenges.
 Some of these challenges are related to the
uniqueness of the hardware, such as its particular
memory organization.
 Memory limitations are almost always a software
development constraint.
 Virtual memory is not suitable for most embedded
applications.

41
 Software development

 Embedded operating systems differ from general-

purpose operating systems in a number of ways.
 Responsiveness is one of the major distinguishing
features.
 Not all embedded operating systems are real-time
operating systems.
 Timing requirements may differ little from a desktop
computer.
 Hard real-time systems have strict timing constraints.
 In soft real-time systems, timing is important but not
critical.
42
 Software development

 Interrupt latency is the elapsed time between the

occurrence of an interrupt and the execution of the
first instruction of the interrupt service routine (ISR).
 Interrupt latency is indirectly related to system
responsiveness. The smaller the latency, the faster the
response.
 Interrupts can happen at any time and in any order.
 The ISR for one interrupt possibly may not be
completed before another interrupt occurs.
 High-quality systems support such interrupt nesting.

43
 Software development

 Memory footprint is another critical concern with embedded

systems.
 If an operating system takes up too much memory, additional
memory may be required.
 Memory consumes power.
 Thus, the smaller the operating system, the better.
 Most embedded operating systems are modular, allowing
only the most necessary features to be installed.

44
 Software development

 IEEE 1003.1-2001, POSIX, is the specification for

standardized Unix, to which Embedded Linux
adheres.
 Other popular embedded operating systems
include Windows CE, Windows XP Embedded,
QNX, and MS-DOS.
 There are hundreds of others, each having its
distinctive behavior and target hardware.
 Licensing costs for the operating system are as
great a concern as hardware costs.

45
 Software development

 General-purpose software development is usually

iterative and incremental.
 Code a little, test a little.
 Embedded systems development requires a much
more rigorous and linear path.
 Functional requirements must be clear, complete,
and accurate when work begins.
 Formal languages, such as Z, are helpful in
providing accuracy and correctness.

46
 Software development

 Large software projects are usually partitioned into

chunks so that the chunks can be assigned to
different teams.
 Embedded software doesn’t partition so easily,
making team assignments difficult.
 To improve performance, some embedded
programmers advocate the use of global variables
and unstructured code.
 Others rail against this idea, saying that it is not good
engineering practice regardless of the platform for
which the software is written.

47
 Software development

 Event handling is a major challenge to the

embedded programmer.
 It lies at the heart of embedded systems functionality
 Events can happen asynchronously and in any
order.
 It is virtually impossible to test all possible
sequences of events.
 Testing must be rigorous and thorough.

48
 Software development

 Embedded programming is essentially a matter of

raising and responding to signals.
 Hardware support may be designed into a chip to
facilitate the tracing and debugging of signal patterns.
 Examples are ICE, Motorola’s BDM, IEEE 1149.1 JTAG,
and IEEE 5001 Nexus.
 Some platforms offer no tool support in the way of
debuggers or even compilers.
 Writing software for these systems is called bare metal
programming.

49