Embedded Systems Design - An Introduction to Processes Tools and Techniques (A. Berger, 2002)

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.

Silicon Economics

For most of the major silicon vendors in the United States, Japan, and Europe, high-performance processors also mean high profit margins. Thus, the newest CPU designs tend to be introduced into applications in which cost isn’t the allconsuming factor as it is in embedded applications. Not surprisingly, a new CPU architecture first appears in desktop or other highperformance applications.

As the family of products continues to evolve, the newer design takes its place as the flagship product. The latest design is characterized by having the highest transistor count, the lowest yield of good dies, the most advanced fabrication process, the fastest clock speeds, and the best performance. Many customers pay a premium to access this advanced technology in an attempt to gain an advantage in their own markets. Many other customers won’t pay the premium, however.

As the silicon vendor continues to improve the process, its yields begin to rise, and its profit margins go up. The earlier members of the family can now take advantage of the new process and be re-engineered in this new process (silicon vendors call this a shrink), and the resulting part can be sold at a reduced cost because the die size is now smaller, yielding many more parts for a given wafer size. Also, because the R&D costs have been recovered by selling the microprocessor version at a premium, a lower price becomes acceptable for the older members of the family.

Using the Core As the Basis of a Microcontroller

The silicon vendor also can take the basic microprocessor core and use it as the basis of a microcontroller. Cost-reducing the microprocessor core might inevitably lead to a family of microcontroller devices, all based on a core architecture that once was a stand-alone microprocessor. For example, Intel’s 8086 processor led to the 80186 family of devices. Motorola’s 68000 and 68020 CPUs led to the 68300 family of devices. The list goes on.

System-on-Silicon (SoS)

Today, it’s common for a customer with reasonable volume projections to completely design an application-specific microcontroller containing multiple CPU elements and multiple peripheral devices on a single silicon die. Typically, the individual elements are not designed from scratch but are licensed (in the form of “synthesizable” VHDL[1] or Verilog specifications) from various IC design houses. Engineers connect these modules with custom interconnect logic, creating a chip that contains the entire design. Condensing these elements onto a single piece of silicon is called system-on- silicon (SoS) or SOC. Chapter 3 on hardware and software partitioning discusses this trend. The complexity of modern SOCs are going far beyond the relatively “simple” microcontrollers in use today.

[1]VHDl stands for VHSIC (very high-speed IC) hardware description language

Adequate Performance

Although performance is only one of the considerations when selecting processors, engineers are inclined to place it above the others, perhaps because performance is expected to be a tangible metric both absolutely and relatively with respect to other processors. However, as you’ll see in the following sections, this is not the case.

Performance-Measuring Tools

For many professionals, benchmarking is almost synonymous with Dhrystones and MIPS. Engineers tend to expect that if processor A benchmarks at 1.5 MIPS, and Processor B benchmarks at 0.8 MIPS, then processor A is a better choice. This inference is so wrong that some have suggested MIPS should mean: Meaningless Indicator of Performance for Salesmen.

MIPS were originally defined in terms of the VAX 11/780 minicomputer. This was the first machine that could run 1 million instructions per second (1 MIPS). An instruction, however, is a one-dimensional metric that might not have anything to do with the way work scales on different machine architectures. With that in mind, which accounts for more work, executing 1,500 instructions on a RISC architecture or executing 1,000 instructions on a CISC architecture? Unless you are comparing VAX to VAX, MIPS doesn’t mean much.

The Dhrystone benchmark is a simple C program that compiles to about 2,000 lines of assembly code and is independent of operating system services. The Dhrystone benchmark was also calibrated to the venerable VAX. Because a VAX 11/70 could execute 1,757 loops through the Dhrystone benchmark in 1 second, 1,757 loops became 1 Dhrystone. The problem with the Dhrystone test is that a crafty compiler designer can optimize the compiler to blast through the Dhrystone benchmark and do little else well.

Distorting the Dhrystone Benchmark

Daniel Mann and Paul Cobb[5] provide an excellent analysis of the shortcomings of the Dhrystone benchmark. They analyze the Dhrystone and other benchmarks and point out the problems inherent in using the Dhrystone to compare embedded processor performance. The Dhrystone often misrepresents expected performance because the benchmark doesn’t always use the processor in ways that parallel typical application use. For example, a particular problem arises because of the presence of on-chip instructions and data caches. If significant amounts (or all) of a benchmark can fit in an on-chip cache, this can skew the performance results.

Figure 2.3 compares the performance of three microprocessors for the Dhrystone benchmark on the left side of the chart and for the Link Access Protocol-D (LAPD) benchmark on the right side. The LAPD benchmark is more representative of communication applications. LAPD is the signaling protocol for the D- channel of ISDN. The benchmark is intended to measure a processor’s capability to process a typical layered protocol stack.

Figure 2.3: Dhrystone comparison chart.

Comparing microprocessor performance for two benchmarks (courtesy of Mann and Cobb)[5].

Furthermore, Mann and Cobb point out that developers usually compile the Dhrystone benchmark using the string manipulation functions that are part of the C run-time library, which is normally part of the compiler vendor’s software package. The compiler vendor usually optimizes these library functions as a good compromise between speed and code size. However, the compiler vendor could create optimized versions of these string-handling functions to yield more favorable Dhrystone results. This practice isn’t necessarily dishonest, as long as a full disclosure is made to the end user.

A manufacturer can further abuse benchmark data by benchmarking its processor with a board that has fast static SRAM and then compare the results to a competitor’s board that contains slower, but more economical, DRAM.

Meaningful Benchmarking

Real benchmarking involves carefully balancing system requirements and variables. How a processor runs in your application might be very different from its performance in a different application. You must consider many things when determining how well or poorly a processor might perform in benchmarking tests.

In particular, it’s important to analyze the real-time behavior of the processor. Because most embedded processors must deal with real-time events, you might assume that the designers have factored this into their performance requirements for the processor. This assumption might or might not be correct because, once again, how to optimize for real-time problems isn’t as obvious as you might expect. Real-time performance can be generally categorized into two buckets: interrupt handling and task switching. Both relate to the general problem of switching the context of the processor from one operation to another. Registers must be saved, variables must be pushed onto the stack, memory spaces must be swapped, and other housekeeping events must take place in both instances. How easy this is to accomplish, as well as how fast it can be carried out, are important in evaluating a processor that must be interfaced to events in the real world.

Predicting performance isn’t easy. Many companies that blindly relied (sometimes with fervent reassurance from vendors) on overly simplistic benchmarking data have suffered severe consequences. The semiconductor vendors were often just as guilty as the compiler vendors of aggressively tweaking their processors to perform well in the Dhrystone tests.

From the Trenches When you base early decisions on simplistic measures, such as benchmarks and throughput, you risk disasterous late surprises, as this story illustrates:

A certain embedded controller manufacturer, who shall remain nameless, was faced with a dilemma. The current product family was running out of gas, and it was time to do a re-evaluation of the current architecture. There was a strong desire to stay with the same processor family that they used in the previous design. The silicon manufacturer claimed that the newest member of the family benchmarked at twice the throughput of the previous version of the device (The clue here is benchmarked. What was the benchmark? How did it relate to the application code being used by this product team?). Since one of the design requirements was to double the throughput of the product, the design team opted to replace the existing embedded processor with the new one.

At first, the project progressed rapidly, since the designers could reuse much of their C and assembly code, as well as many of the software tools they had already purchased or developed. The problems became apparent when they finally began to run their own performance metrics on the new prototype hardware. Instead of the expected two-fold performance boost, their new design gave them only a 15percent performance improvement, far less than what they needed to stay competitive in their market space.

The post-mortem analysis showed that the performance boost they expected could not be achieved by simply doubling the clock frequency or by using a more powerful processor. Their system design had bottlenecks liberally sprinkled throughout the hardware and software design. The processor could have been infinitely fast, and they still would not have gotten much better than a 15-percent boost.

EEMBC

Clearly, MIPS and Dhrystone measurements aren’t adequate; designers still need something more tangible than marketing copy to use as a basis for their processor selection. To address this need, representatives of the semiconductor vendors, the compiler vendors, and their customers met under the leadership of Markus Levy (who was then the technical editor of EDN magazine) to create a more meaningful benchmark. The result is the EDN Embedded Microprocessor Benchmark Consortium, or EEMBC (pronounced “Embassy”).

The EEMBC benchmark consists of industry-specific tests. Version 1.0 currently has 46 tests divided into five application suites. Table 2.1 shows the benchmark tests that make up 1.0 of the test suite.

Table 2.1: EEMBC tests list.

The 46 tests in the EEMBC benchmark are organized as five industryspecific suites.

EEMBC Test

Automotive/Industrial Suite

Unlike the Dhrystone benchmarks, the benchmarks developed by the EEMBC technical committee represent real-world algorithms against which the processor can be measured. Looking at the Automotive/Industrial suite of tests, for example, it’s obvious that any embedded microprocessor involved in an engine-management system should be able to calculate a tooth-to-spark time interval efficiently.

The EEMBC benchmark produces statistics on the number of times per second the algorithm executes and the size of the compiled code. Because the compiler could have a dramatic impact on the code size and efficiency, each benchmark must contain a significant amount of information about the compiler and the settings of the various optimization switches.