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

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.

kernel should be optimized for the platform on which it is running. A kernel written in C and recompiled (without careful retargeting) for a new platform can significantly reduce the system performance. Table 2.2 is a checklist to help you decide which RTOS is appropriate. Most of the factors are self-explanatory, but you’ll find additional comments in the following sections.

Language/Microprocessor Support

Increasingly, RTOS vendors attempt to supply the design team with a “cradle-to- grave solution,” which is also called “one-stop shopping.” This approach makes sense for many applications but not all. To provide an integrated solution, the RTOS vendor often chooses compatible tool vendors and then further custom recrafts their tools to better fit the RTOS requirements. This means you might have to select the RTOS vendor’s compiler, instead of your first choice. In other cases, to get the RTOS vendor’s tools suite, you must choose from that vendor’s list of supported microprocessors. Again, it depends on your priorities.

Table 2.2: Real-time operating system checklist. [4]

This checklist can help you determine which RTOS products are suitable for your project

Operating systems provide a variety of services. Make sure that your OS supports the services, such as queues, times, semaphores, etc., that you expect to use in your design.

RTOSs are often scalable, including only those services you end up needing for your application. Based on what services you’ll need, the number of tasks, sema phores, and everything else you expect to use, make sure your RTOS will work in the RAM space and ROM space you have allocated for your design.

Can your RTOS meet your performance requirements? Make sure that you under stand the benchmarks the vendors give you and how they actually apply to the hardware you really will be using.

Are required components, such as protocol stacks, communication services, realtime databases, Web services, virtual machines, graphic libraries, and so on

Team-Fly®