1.2 THE EMBEDDED SYSTEM DESIGN PROCESS

This section provides an overview of the embedded system design process aimed at two objectives. First, it will give us an introduction to the various steps in embedded system design before we delve into them in more detail. Second, 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-defined design methodology.

Figure 1.1 summarizes the major steps in the embedded system design process. In this top-down view, we start with the system requirements. In the next step,

hinh ve:

System integration

Components

Architecture

Specification

Requirements

Bottom-up

design

Top-down

design

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 system’s 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. In this section we will consider design from the top-down? we will begin with the most abstract description of the system and conclude with concrete details. The alternative is a bottom-up view in which we start with components to build a system. Bottom-up design steps are shown in the figure as dashed-line arrows. We need bottom-up design because we do not have perfect insight into how later stages of the design process will turn out. Decisions at one stage of design are based upon estimates of what will happen later: How fast can we make a particular function run? How much memory will we need? How much system bus capacity do we need? If our estimates are inadequate, we may have to backtrack and amend our original decisions to take the new facts into account. In general, the less experience we have with the design of similar systems, the more we will have to rely on bottom-up design information to help us refine the system. But the steps in the design process are only one axis along which we can view embedded system design. We also need to consider 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.

1.2.1 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,we gather an informal description from the customers known as requirements, and we re?ne the requirements into a speci?cation that contains enough information to begin designing the system architecture. Separating out requirements analysis and speci?cation is often necessary because of the large gap between what the customers can describe about the system they want and what the architects need to design the system. Consumers of embedded systems are usually not themselves embedded system designers or even product designers. Their understanding of the system is based on how they envision users’ interactions with the system. They may have unrealistic expectations as to what can be done within their budgets; and they may also express their desires in a language very different from system architects’ jargon. Capturing a consistent set of requirements from the customer and then massaging those requirements into a more formal speci?cation is a structured way to manage the process of translating from the consumer’s language to the designer’s.

Requirementsmay be functional or nonfunctional .Wemust of course capture the basic functions of the embedded system,but functional description is often not sufficient. Typical nonfunctional requirements include:

■ Performance: The speed of the system is often a major consideration both for the usability of the system and for its ultimate cost. As we have noted, performance may be a combination of soft performance metrics such as approximate time to perform a user-level function and hard deadlines by which a particular operation must be completed.

■ 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. Validating a set of requirements is ultimately a psychological task since it requires understanding both what people want and how they communicate those needs.

One goodway to re?ne at least the user interface portion of a system’s requirements is to build a mock-up.The mock-up may use canned data to simulate functionality in a restricted demonstration, and it may be executed on a PC or a workstation. But it should give the customer a good idea of how the system will be used and how the user can react to it. Physical, nonfunctional models of devices can also give customers a better idea of characteristics such as size and weight.

Name

Purpose

Inputs

Outputs

Functions

Performance

Manufacturing cost

Power

Physical size and weight

FIGURE 1.2

Sample requirements form.

Requirements analysis for big systems can be complex and time consuming.

However, capturing a relatively small amount of information in a clear, simple format is a good start toward understanding system requirements. To introduce the discipline of requirements analysis as part of system design, we will use a simple requirements methodology.

Figure 1.2 shows a sample requirements form that can be ?lled out at the start of the project. We can use the form as a checklist in considering the basic characteristics of the system. Let’s consider the entries in the 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 ofwhat the system is supposed to do. If you can’t describe the essence of your system in one or two lines, chances are that you don’t 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:

-  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 don’t 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 $100 system.

■ 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.

A more thorough requirements analysis for a large system might use a form similar to Figure 1.2 as a summary of the longer requirements document. After an introductory section containing this form, a longer requirements document could include details on each of the items mentioned in the introduction. For example, each individual feature described in the introduction in a single sentence may be described in detail in a section of the specification. After writing the requirements, you should check them for internal consistency: Did you forget to assign a function to an input or output? Did you consider all the modes in which you want the system to operate? Did you place an unrealistic number of features into a battery-powered, low-cost machine?

To practice the capture of system requirements, Example 1.1 creates the requirements for a GPS moving map system.

Example 1.1

Requirements analysis of a GPS moving map

The moving map is a handheld device that displays for the user amap of the terrain around the user’s current position; the map display changes as the user and the map device change position. The moving map obtains its position from the GPS, a satellite-based navigation system.

The moving map display might look something like the following figure.

What requirements might we have for our GPS moving map? 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 400

600 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 ?t comfortably in the palm of the hand.

■ Power consumption: The device should run for at least eight hours on four AA batteries.

Note that many of these requirements are not specified in engineering units? for example, physical size is measured relative to a hand, not in centimeters. Although these requirements must ultimately be translated into something that can be used by the designers, keeping a record of what the customer wants can help to resolve questions about the specification that may crop up later during design.

Based on this discussion, let’s write a requirements chart for our moving map system:

Name GPS moving map

Purpose Consumer-grade moving map for driving use

Inputs Power button, two control buttons

Outputs Back-lit LCD display 400

 600

Functions Uses 5-receiver GPS system; three user-selectable resolutions; always displays current latitude and longitude

Performance Updates screen within 0.25 seconds upon movement

Manufacturing cost $30

Power 100mW

Physical size and weight No more than 2”

 6, ” 12 ounces

This chart adds some requirements in engineering terms that will be of use to the designers.

For example, it provides actual dimensions of the device. The manufacturing cost was derived from the selling price by using a simple rule of thumb: The selling price is four to five times the cost of goods sold (the total of all the component costs).

1.2.2 Speci?cation

The speci?cation is more precise?it serves as the contract between the customer and the architects. As such, the speci?cation must be carefully written so that it accurately re?ects the customer’s requirements and does so in a way that can be clearly followed during design.

Speci?cation 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. Designers who lack a clear idea of what they want to build when they begin typically make faulty assumptions early in the process that aren’t obvious until they have a working system. At that point, the only solution is to take the machine apart, throw away some of it, and start again. Not only does this take a lot of extra time, the resulting system is also very likely to be inelegant, kludgey, and bug-ridden. The speci?cation should be understandable enough so that someone can verify that itmeets system requirements and overall expectations of the customer. It should also be unambiguous enough that designers know what they need to build. Designers can run into several different types of problems caused by unclear specifications. If the behavior of some feature in a particular situation is unclear from the speci?cation, the designer may implement the wrong functionality. If global characteristics of the speci?cation are wrong or incomplete, the overall system architecture derived from the speci?cation may be inadequate to meet the needs of implementation.

A speci?cation 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.

UML, a language for describing speci?cations,will be introduced in Section 1.3, and we will use it to write a speci?cation in Section 1.4.We will practice writing

speci?cations in each chapter as we work through example system designs.We will

also study speci?cation techniques in more detail in Chapter 9.

1.2.3 Architecture Design

The speci?cation 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 ?rst phase of what many designers think of as design. To understand what an architectural description is, let’s look at a sample architecture for the moving map of Example 1.1. Figure 1.3 shows a sample system architecture in the form of a block diagram that shows major operations and data flows among them.

This block diagram is still quite abstract? we have not yet speci?ed which operations will be performed by software running on a CPU, what will be done by special-purpose hardware, and so on. The diagram does, however, go a long way toward describing how to implement the functions described in the speci?cation. We clearly see, for example, that we need to search the topographic database and to render (i.e., draw) 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 may help us update the screen more ?uidly. 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. These two more re?ned block diagrams are shown in Figure 1.4.The hardware block diagram clearly shows that we have one central CPU surrounded by memory and I/O devices. In particular, we have chosen to use two memories: a frame buffer for the pixels to be displayed and a separate program/data memory for general use by the CPU.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 non- functional 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 re?ning that to hardware and software architectures is one goodway to ensure thatwemeet all speci?cations:We can concentrate on the functional elements in the system block diagram, and then consider the nonfunctional constraints when creating the hardware and software architectures.

How do we know that our hardware and software architectures in fact meet constraints on speed, cost, and so on? We must somehow be able to estimate the properties of the components of the block diagrams, such as the search and rendering functions in the moving map system. Accurate estimation derives in part from experience, both general design experience and particular experience with similar systems. However, we can sometimes create simpli?ed models to help us make more accurate estimates. Sound estimates of all nonfunctional constraints during the architecture phase are crucial, since decisions based on bad data will show up during the ?nal phases of design, indicating that we did not, in fact, meet the speci?cation.

1.2.4 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 speci?cation. The components will in general include both hardware? FPGAs, boards,

and so on? and 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 stan-

dard routines to access the database ?not 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 power?for

example,sincememory accesses are amajor source of power consumption,memory transactions must be carefully planned to avoid reading the same data several times.

1.2.5 System Integration

Only after the components are built do we have the satisfaction of putting them together and seeing a working system. Of course, 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. 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. Only by fixing the simple bugs early will we be able to uncover the more complex or obscure bugs that can be identi?ed 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. 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.