Файл: Embedded Systems Design - An Introduction to Processes Tools and Techniques (A. Berger, 2002).pdf

The general methods of debugging that you’ve learned to use on your PC or workstation are pretty much the same as in embedded systems. The exceptions are what make it interesting. It is an exercise in futility to try to debug a software module when the source of the problem lies in the underlying hardware or the operating system. Similarly, it is nearly impossible to find a bug that can only be observed when the system is running at full speed when the only trace capability available is to single-step the processor. However, with these tools at your disposal, your approach to debugging will be remarkably similar to debugging an application designed to run on your PC or workstation.

Product Testing and Release

Product testing takes on special significance when the performance of the embedded system has life or death consequences attached. You can shrug off an occasional lock-up of your PC, but you can ill-afford a software failure if the PC controls a nuclear power generating station’s emergency system. Therefore, the testing and reliability requirements for an embedded system are much more stringent than the vast majority of desktop applications. Consider the embedded systems currently supporting your desktop PC: IDE disk drive, CD-ROM, scanner, printer, and other devices are all embedded systems in their own right. How many times have they failed to function so that you had to cycle power to them?

From the Trenches For the longest time, my PC had a nagging problem of crashing in the middle of my word processor or graphics application. This problem persisted through Windows 95, 95 Sr-1, 98, and 98 SE. After blaming Microsoft for shoddy software, I later discovered that I had a hardware problem in my video card. After replacing the drivers and the card, the crashes went away, and my computer is behaving well. I guess hardware/software integration problems exist on the desktop as well.

However, testing is more than making sure the software doesn’t crash at a critical moment, although it is by no means an insignificant consideration. Because embedded systems usually have extremely tight design margins to meet cost goals, testing must determine whether the system is performing close to its optimal capabilities. This is especially true if the code is written in a high-level language and the design team consists of many developers.

Many desktop applications have small memory leaks. Presumably, if the application ran long enough, the PC would run out of heap space, and the computer would crash. However, on a desktop machine with 64MB of RAM and virtual swap space, this is unlikely to be a problem. On the other side, in an embedded system, running continuously for weeks at a time, even a small memory leak is potentially disastrous.

Who Does the Testing?

In many companies, the job of testing the embedded product goes to a separate team of engineers and technicians because asking a designer to test his own code or product usually results in erratic test results. It also might lead to a “circle the wagons” mentality on the part of the design team, who view the testers as a roadblock to product release, rather than equal partners trying to prevent a defective product from reaching the customer.

Compliance Testing

Compliance testing is often overlooked. Modern embedded systems are awash in radio frequency (RF) energy. If you’ve traveled on a plane in the last five years, you’re familiar with the requirement that all electronic devices be turned off when the plane descends below 10,000 feet. I’m not qualified to discuss the finer points of RF suppression and regulatory compliance requirements; however, I have spent many hours at open field test sites with various compliance engineering (CE) engineers trying just to get one peak down below the threshold to pass the class B test and ship the product.

I can remember one disaster when the total cost of the RF suppression hardware that had to be added came to about one-third of the cost of all the other hardware combined. Although it can be argued that this is the realm of the hardware designer and not a hardware/software design issue, most digital hardware designers have little or no training in the arcane art of RF suppression. Usually, the hotshot digital wizard has to seek out the last remaining analog designer to get clued in on how to knock down the fourth harmonic at 240MHz. Anyway, CE testing is just as crucial to a product’s release as any other aspect of the test program.

CE testing had a negative impact on my hardware/software integration activities in one case. I thought we had done a great job of staying on top of the CE test requirements and had built up an early prototype especially for CE testing. The day of the tests, I proudly presented it to the CE engineer on schedule. He then asked for the test software that was supposed to exercise the hardware while the RF emissions were being monitored. Whoops, I completely forgot to write drivers to exercise the hardware. After some scrambling, we pieced together some of the turn-on code and convinced the CE engineer (after all, he had to sign all the forms) that the code was representative of the actual operational code.

Referring to Figure 1.4, notice the exponential rise in the cost to fix a defect the later you are in the design cycle. In many instances, the Test Engineering Group is the last line of defense between a smooth product release and a major financial disaster.

Figure 1.4: Where design time is spent.

The percentage of project time spent in each phase of the embedded design life cycle. The curve shows the cost associated with fixing a defect at each stage of the process.

Like debugging, many of the elements of reliability and performance testing map directly on the best practices for host-based software development. Much has been

written about the correct way to develop software, so I won’t cover that again here. What is relevant to this subject is the best practices for testing software that has mission-critical or tight performance constraints associated with it. Just as with the particular problems associated with debugging a real-time system, testing the same system can be equally challenging. I’ll address this and other testing issues in Chapter 9.

Maintaining and Upgrading Existing Products

The embedded system tool community has made almost no effort to develop tools specifically targeted to products already in service. At first blush, you might not see this as a problem. Most commercially developed products are well documented, right?

The majority of embedded system designers (around 60 percent) maintain and upgrade existing products, rather than design new products. Most of these engineers were not members of the original design team for a particular product, so they must rely on only their experience, their skills, the existing documentation, and the old product to understand the original design well enough to maintain and improve it.

From the silicon vendor’s point of view, this is an important gap in the tool chain because the vendor wants to keep that customer buying its silicon, instead of giving the customer the chance to do a “clean sheet of paper” redesign. Clean sheets of paper tend to have someone else’s chip on them.

This phase of a product’s life cycle requires tools that are especially tailored to reverse engineering and rapidly facilitating “what if …” scenarios. For example, it’s tempting to try a quick fix by speeding up the processor clock by 25 percent; however, this could cause a major ripple effect through the entire design, from memory chip access time margins to increased RF emissions. If such a possibility could be as easily explored as making measurements on a few critical code modules, however, you would have an extremely powerful tool on your hands.

Sometimes, the solutions to improved performance are embarrassingly simple. For example, a data communications manufacturer was about to completely redesign a product when the critical product review uncovered that the processor was spending most of its time in a debug module that was erroneously left in the final build of the object code. It was easy to find because the support teams had access to sophisticated tools that enabled them to observe the code as it executed in real time. Without the tools, the task might have been too time-consuming to be worthwhile.

Even with these test cases, every marketing flyer for every tool touts the tool’s capability to speed “time to market.” I’ve yet to hear any tool vendor advertise its tool as speeding “time to reverse-engineer,” although one company claimed that its logic analyzer sped up the “time to insight.”

Embedded systems projects aren’t just “software on small machines.” Unlike application development, where the hardware is a fait accompli, embedded

projects are usually optimization exercises that strive to create both hardware and software that complement each other. This difference is the driving force that defines the three most characteristic elements of the embedded design cycle: selection, partitioning, and system integration. This difference also colors testing and debugging, which must be adapted to work with unproven, proprietary hardware.

1. Barr, Michael. “ArchitectingTEmbedded Systems for Add-on Software Modules.” Embedded Systems Programming, September 1999, 49.

Team-Fly®

Chapter 2: The Selection Process

Overview

Embedded systems represent target platforms that are usually specific to a single task. This specificity means the system design can be highly optimized because the range of tasks the device must perform is well bounded. In other words, you wouldn’t use your PC to run your coffee machine (you might, but that’s beside the point). Unlike your desktop processor, the 4-bit microcontroller that runs your coffee machine costs less than $1 in large quantities. It does exactly what it’s supposed to do to — make your coffee. It doesn’t play Zelda, nor does it exchange data with an Internet service provider (ISP), although that might change soon. Because the functionality of the device is so narrowly defined, you must find the optimal processing element (CPU) for the design. Given the several hundred choices available and the many variations within those choices, choosing the right CPU can be a daunting task.

Although choosing a processor is a complex task that defies simple “optimization” (see Figure 2.1) in all but the simplest projects, the final choice must pass four critical tests:

Figure 2.1: Choosing the right processor.

Considerations for choosing the right microprocessor for an embedded application.

Is it available in a suitable implementation?

Is it capable of sufficient performance?

Is it supported by a suitable operating system?

Is it supported by appropriate and adequate tools?

Is the Processor Available in a Suitable Implementation? Cost-sensitive projects might require an off-the-shelf, highly integrated part. High-performance applications might require gate-to-gate delays that are only practical when the entire design is fabricated on a single chip. What good is choosing the highest performing processor if the cost of goods makes your product noncompetitive in the marketplace? For example, industrial control equipment manufacturers that commonly provide product support and replacement parts with a 20-year lifetime won’t choose a microprocessor from a vendor that can’t guarantee product

availability over a reasonable span of time. Similarly, if a processor isn’t available in a military version, you wouldn’t choose it for a missile guidance system, no matter how good the specs are. In many cases, packaging and implementation technology issues significantly limit the choice of architecture and instruction set.

Is the Processor Capable of Sufficient Performance? Ultimately, the processor must be able to do the job on time. Unfortunately, as embedded systems become more complex, characterizing “the job” becomes more difficult. As the mix of tasks managed by the processor becomes more diverse (not just button presses and motor encoding but now also Digital Signal Processor [DSP] algorithms and network processing), the bottlenecks that limit performance often have less to do with computational power than with the “fit” between the architecture and the device’s more demanding tasks. For this reason, it can be difficult to correlate benchmark results with how a processor will perform in a particular device.

Is the Processor Supported by an Appropriate Operating System? With today’s 32-bit microprocessors, it’s natural to see an advantage in choosing a commercial RTOS. You might prefer one vendor’s RTOS, such as VxWorks or pSOS from Wind River Systems. Porting the RTOS kernel to a new or different microprocessor architecture and having it specifically optimized to take advantage of the low-level performance features of that microprocessor is not a task for the faint-hearted. So, the microprocessor selection also might depend on having support for the customer’s preferred RTOS.

Is the Processor Supported by Appropriate and Adequate Tools? Good tools are critical to project success. The specific toolset necessary depends on the nature of the project to a certain extent. At a minimum, you’ll need a good crosscompiler and good debugging support. In many situations, you’ll need far more, such as in-circuit emulators (ICE), simulators, and so on.

Although these four considerations must be addressed in every processorselection process, in many cases, the optimal fit to these criteria isn’t necessarily the best choice. Other organizational and business issues might limit your choices even further. For example, time-to-market constraints might make it imperative that you choose an architecture with which the design team is already familiar. A corporate commitment or industry preference for a particular vendor or family also can be an important factor.

Packaging the Silicon

Until recently, designers have been limited to the choice of microprocessor versus microcontroller. Recent advances in semiconductor technology have increased the designer’s choices. Now, at least for mass-market products, it might make sense to consider a system-on-a-chip (SOC) implementation, either using a standard part or using a semi-custom design compiled from licensed intellectual property. The following section begins the discussion of these issues by looking at the traditional microprocessor versus microcontroller trade-offs. Later sections explore some of the issues relating to more highly integrated solutions.

Microprocessor versus Microcontroller

Most embedded systems use microcontrollers instead of microprocessors. Sometimes the distinction is blurry, but in general, a microprocessor is the CPU without any additional peripheral or support devices. Microcontrollers are designed

to need a minimum complement of external parts. Figure 2.2 illustrates the difference. The diagram on the left side of the figure shows a typical microprocessor system constructed of discrete components. The diagram on the right shows the same system but now integrated within a single package.

Figure 2.2: Microcontrollers versus microprocessors.

In a microprocessor-based system, the CPU and the various I/O functions are packaged as separate ICs. In a microcontroller-based system many, if not all, of the I/O functions are integrated into the same package with the CPU.

The advantages of the microcontroller’s higher level of integration are easy to see:

Lower cost — One part replaces many parts.

More reliable — Fewer packages, fewer interconnects.

Better performance — System components are optimized for their environment.

Faster — Signals can stay on the chip.

Lower RF signature — Fast signals don’t radiate from a large PC board.

Thus, it’s obvious why microcontrollers have become so prevalent and even dominate the entire embedded world. Given that these benefits derive directly from the higher integration levels in microcontrollers, it’s only reasonable to ask “why not integrate even more on the main chip?” A quick examination of the economics of the process helps answer this question.