UNIT-I

EMBEDDED COMPUTING

Embedded System An embedded system is some combination of computer hardware andsoftware, either fixed in capability or programmable, that is specifically designed for a particular function. Examples:

Industrial machines Automobiles Medical equipment Cameras Household appliances Vending machines and Toys (as well as the more obvious cellular phone and PDA) */

Challenges in Embedded Computing System Design External constraints are one important source of difficulty in embedded system design. Lets consider some important problems that must be taken into account in embedded system design.
1. How much hardware do we need? 2. How do we meet deadlines? 3. How do we minimize power consumption? 4. How do we design for upgradability? 5. Does it really work? 1. How much hardware do we need? We have a great deal of control over the amount of computing power we

apply to our problem.

We cannot only select the type of microprocessor used, but also select the

amount of memory, the peripheral devices, and more.

Since it must meet both performance deadlines and manufacturing cost

constraints, the choice of hardware is importanttoo little hardware and the system fails to meet its deadlines, too much hardware and it becomes too expensive.

2. How do we meet deadlines? The brute force way of meeting a deadline is to speed up the hardware so

that the program runs faster.

Of course, that makes the system more expensive. It is also entirely possible that increasing the CPU clock rate may not make

enough difference to execution time, since the programs speed may be limited by the memory system.
3. How do we minimize power consumption? In battery-powered applications, power consumption is extremely

important.
Even in non battery applications, excessive power consumption can

increase heat dissipation.

One way to make a digital system consume less power is to make it run

more slowly, but naively slowing down the system can obviously lead to missed deadlines.
Careful design is required to slow down the noncritical parts of the

machine

for

power

consumption

while

still

meeting

necessary

performance goals.
4. How do we design for upgradability? The hardware platform may be used over several product generations or

for several different versions of a product in the same generation, with few or no changes.
However, we want to be able to add features by changing software. How can we design a machine that will provide the required performance

for software that we havent yet written?

5. Does it really work? Reliability is always important when selling productscustomers rightly

expect that products they buy will work.

Reliability is especially important in some applications, such as safety-

critical systems.
If we wait until we have a running system and try to eliminate the bugs, we

will be too latewe wont find enough bugs, it will be too expensive to fix them, and it will take too long as well.

 Another set of challenges comes from the characteristics of the

components and systems themselves.

If workstation programming is like assembling a machine on a bench, then

embedded system design is often more like working on a car cramped, delicate, and difficult.
Lets consider some ways in which the nature of embedded computing

machines makes their design more difficult. Complex testing:

Exercising an embedded system is generally more difficult than

typing in some data.

We may have to run a real machine in order to generate the

proper data.
The timing of data is often important, meaning that we cannot

separate the testing of an embedded computer from the machine in which it is embedded. Limited observability and controllability:
Embedded computing systems usually do not come with keyboards

and screens.
This makes it more difficult to see what is going on and to affect the

systems operation.
We may be forced to watch the values of electrical signals on the

microprocessor bus, for example, to know what is going on inside the system. Restricted development environments:
The development environments for embedded systems (the tools

used to develop software and hardware) are often much more limited than those available for PCs and workstations.
We generally compile code on one type of machine, such as a PC,

and download it onto the embedded system.

To debug the code, we must usually rely on programs that run on

the PC or workstation and then look inside the embedded system. THE EMBEDDED SYSTEM DESIGN PROCESS

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

design before we delve into them in more detail.

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 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. By defining the overall process, team members can more easily understand what they are supposed to do, what they should receive from other team members at certain times, and what they are to hand off when they complete their assigned steps.
Since most embedded systems are designed by teams, coordination is

perhaps the most important role of a well-de.ned design methodology.

In this topdown view, we start with the system requirements. In the next step, specification, we create a more detailed description of

what we want. But the specification states only how the system behaves, not how it is built.

 The details of the systems internals begin to take shape when we develop

the architecture, which gives the system structure in terms of large components.
Once we know the components we need, we can design those components,

including both software modules and any specialized hardware we need.

Based on those components, we can finally build a complete system. We will consider design from the topdownwe will begin with the most

abstract description of the system and conclude with concrete details.

The alternative is a bottomup view in which we start with components to

build a system. Bottomup design steps are shown in the figure as dashedline arrows.
We also need to consider the major goals of the design: manufacturing cost performance Power consumption. 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. Requirements

Clearly, before we design a system, we must know what we are designing. The initial stages of the design process capture this information for use in

creating the architecture and components.

We generally proceed in two phases:

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

Two types Requirements are

Functional

Nonfunctional Functional Requirements: the basic functions of the embedded system, Nonfunctional Requirements: Performance:
The speed of the system is often a major consideration both for the

usability of the system and for its ultimate cost. Cost:

The target cost or purchase price for the system is almost always a

consideration.
Cost typically has two major components: manufacturing cost

includes the cost of components and assembly; nonrecurring engineering(NRE) costs include the personnel and other costs of designing the system. Physical size and weight:
The physical aspects of the Final system can vary greatly depending upon

the application.
An industrial control system for an assembly line may be designed to fit

into a standard-size rack with no strict limitations on weight.

A handheld device typically has tight requirements on both size and

weight that can ripple through the entire system design.

Power consumption:
Power, of course, is important in battery-powered systems and is often

important in other applications as well.

Power can be specified in the requirements stage in terms of battery life

the customer is unlikely to be able to describe the allowable wattage. Name Purpose Inputs Outputs Functions Performance

Manufacturing cost Power Physical size and weight

Sample requirements form

Name:
This is simple but helpful. 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.

If you cant describe the essence of your system in one or two lines, chances are that you dont understand it well enough.

Inputs and outputs:

These two entries are more complex than they seem. The inputs and outputs to the system encompass a wealth of detail: o

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:

This is a more detailed description of what the system does. A good way to approach this is to work from the inputs to the outputs: When the system receives an input, what does it do? How do user interface inputs affect these functions? How do different functions interact?

Performance:

 Many embedded computing systems spend at least some time controlling

physical devices or processing data coming from the physical world.

In most of these cases, the computations must be performed within a

certain time frame.

It is 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:
This includes primarily the cost of the hardware components. Even if you dont know exactly how much you can afford to spend on

system components, you should have some idea of the eventual cost range.
Cost has a substantial influence on architecture: A machine that is meant

to sell at $10 most likely has a very different internal structure than a $100system. Power:
Similarly, you may have only a rough idea of how much power the system

can consume, but a little information can go a long way.

Typically, the most important decision is whether the machine will be

battery powered or plugged into the wall.

Battery-powered machines must be much more careful about how they

spend energy. Physical size and weight:

You should 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, a lapel mounted voice recorder.

Specification:
The specification is more preciseit serves as the contract between the

customer and the architects.

 The specification must be carefully written so that it accurately reflects the

customers requirements and does so in a way that can be clearly followed during design.
The specification should be understandable enough so that someone can

verify that it meets system requirements and overall expectations of the customer.
It should also be unambiguous enough that designers know what they

need to build.

A specification of the GPS system would include several components:

1. Data received from the GPS satellite constellation. 2. Map data. 3. User interface. 4. Operations that must be performed to satisfy customer requests. 5. Background actions required to keep the system running, such as

operating the GPS receiver. Architecture Design

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 block diagram is still quite abstractwe have not yet specified which

operations will be performed by software running on a CPU, what will be done by special-purpose hardware, and so on.

Block diagram for the moving map.

The diagram does, however, go a long way toward describing how to

implement the functions described in the specification.

 Only after we have designed an initial architecture that is not biased

toward too many implementation details should we re.ne that system block diagram into two block diagrams: one for hardware and another for software.
The hardware block diagram clearly shows that we have one central CPU

surrounded by memory and I/O devices.

The software block diagram fairly closely follows the system block

diagram, but we have added a timer to control when we read the buttons on the user interface and render data onto the screen.
To have a truly complete architectural description, we require more detail,

such as where units in the software block diagram will be executed in the hardware block diagram and when operations will be performed in time.
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

Hardware and software architectures for the moving map. Designing 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 hardwareFPGAs, boards, and so onand software modules.
Some of the components will be ready-made. The CPU, for example, will be

a standard component in almost all cases, as will memory chips and many other components.
In the moving map, the GPS receiver is a good example of a specialized

component that will nonetheless be a predesigned, standard component. We can also make use of standard software modules. One good example is the topographic database. Standard topographic databases exist, and you probably want to use standard routines to access the databasenot only is the data in a prede.ned format, but it is highly compressed to save storage. Using standard software for these access functions not only saves us design time, but it may give us a faster implementation for specialized functions such as the data decompression phase.
You will have to design some components yourself. Even if you are using

only standard integrated circuits, you may have to design the printed circuit board that connects them. You will probably have to do a lot of custom programming as well.
When creating these embedded software modules, you must of course

make use of your expertise to ensure that the system runs properly in real time and that it does not take up more memory space than is allowed. The power consumption of the moving map software example is particularly important. You may need to be very careful about how you read and write memory to minimize powerfor example, since memory accesses are a major source of power consumption, memory transactions must be carefully planned to avoid reading the same data several times. System Integration
Only after the components are built do we have the satisfaction of putting

them together and seeing a working system.

This phase usually consists of a lot more than just plugging everything

together and standing back. Bugs are typically found during system integration, and good planning can help us find the bugs quickly.

 Only by fixing the simple bugs early will we be able to uncover the more

complex or obscure bugs that can be identified only by giving the system a hard workout. We need to ensure during the architectural and component design phases that we make it as easy as possible to assemble the system in phases and test functions relatively independently.
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.