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

With one week to go until the Wireless World show, the team felt pretty good. Then disaster struck. Phase7 Systems, ComDelta’s chief competitor, planned to pre-announce its latest product. Their HyperX80 serviced 80 users at half the cost of the CD700. The team huddled. Desperate phone calls went to IME. The team decided to try to wring every last ounce of performance out of the Im46880 processor. Jerry Flemming flew out from Portland to assist in fine-tuning the code.

Now improvements came in little chunks, but they came. Using the tool systems Sys46K as a software performance analyzer, they were able to finetune module after module. They reached 175 users but felt they needed more. Then Ed stepped back into the picture. He had been in contact with IME’s . WCG had a two-channel, wireless LAN chip in development which was nearly pin-compatible with the existing part that ComDelta was already using. As ever, IME delivered. The chip appeared the next day. The team kludged-up a second channel in record time. Jerry helped integrate the ISR and add the additional tasks to the OS.

The next problem that the team faced was a pleasant one. Their simulation lab hardware could not simulate more than 200, users and the ComDelta was still chugging away.

The CD700 won the Best New Product Award at the Wireless World exhibition. Sue Mason was so pleased with IME’s program execution that she volunteered to appear on any future marketing or sales video that IME might produce.

Tool/Chip Tension

Why don’t we have the kind of comprehensive, integrated tool support and customer support illustrated by this story? You would think that with such a codependency, the tool vendors and chip vendors would be the model of cooperation and collaboration. In fact, the relationship between tool and chip vendors is more akin to a family with working parents, five teenagers, two dogs, a cat, and one bathroom.

A number of basic differences exist between the semiconductor manufacturers and the tool vendors that support their chips. These differences tend to weigh heavily on the world-views of both groups and create tension between them.

The semiconductor manufacturer wishes that every new processor would hit it big with in a few major accounts with incredible volumes (the vertical singularity in Figure 10.4). It is the dream of every semiconductor salesperson to win any of the following:

Figure 10.4: Worldviews.

The world view of chip vendors and development tool vendors.

An inkjet printer

Automobile engine management computer

Video game box

With a few customers, the semiconductor manufacturer can lavish attention and make sure the tools for that customer are the best. In the semiconductor manufacturer’s view, the desirable metric is known as time to money. This is the point that product shipments begin and volume purchases of microprocessors begin to take place. It is in the semiconductor manufacturer’s best interest to help the big volume customer (design team) get the product designed, debugged, tested, and shipped in quantity. Problems with the development tools usually translate to delays in realizing volume shipments of processors. That’s the reason I was hired. It was my responsibility to make sure the design process ran smoothly. If almost the entire volume of shipments of a microprocessor goes to a few megaVIP customers, my job was straightforward. However, under these ideal conditions, my real problem became the tool vendors.

It’s the Fabs

Shortly after arriving at my new employer, I was asked to present an informal seminar on the state of tool development as I saw it. Being basically naïve and honest, I proceeded to describe how I could design a pretty credible laser printer with anybody’s embedded processor. Furthermore, in my opinion, the differentiating factor was how quickly I could bring a new design to market. I remember making the point that it wouldn’t do any good if my hot, new laser printer is almost ready to go when Comdex rolled around. If I missed the Comdex introduction, I might as well kill the project.

The conclusion of my talk was met with stony silence. Afterwards, my supervisor explained that I completely missed the point. In short, my mantra was to become:

It’s the fabs, stupid!

The goal of any major semiconductor manufacturer, such as one that builds highperformance microprocessors for the embedded market, is to keep silicon flowing

through the foundry. That was the focus, not the quality of the tools. The tools had to be good enough to support the new design wins. I had to be able to go to a customer with a list of tools that supported our embedded microprocessors. It was not my province to expound on improving the state of embedded-tool development. As long as I had all the boxes on my product support matrix appropriately checked off, life was good.

It took me about two years of effort, but I think that I finally changed some minds, although it was probably wishful thinking on my part. Unfortunately, we did have some real situations in which the quality of our development-support tools were not up to the requirements of our customers, and my group had to step in and help. If some of the chip folks did eventually see the wisdom in my words, they never admitted it to my face.

From the perspective of the tool vendor, the semiconductor manufacturer’s ideal situation is a bad business arrangement.

Note

Coming from a background in tool development, I tend to think of processors as a necessary evil. Each new processor brings its own quirks to the task of designing the best development tools. Having a deep pipeline on the bus interface unit means that the tool vendor must design a clever state machine to mimic the pipeline behavior in the emulator so that the tool can accurately display real-time trace information.

For a tool vendor to develop a new product, such as a compiler, debugger, or ICE, to support a new processor, there must be a good probability of return on investment (ROI). Suppose the tool vendor invests $750,000 to develop several enhancements to existing products to support the new processor. (Although $750,000 might seem like a lot, good engineers don’t come cheap these days. This represents the cost of about five engineers for six to 12 months, depending on how you do your bookkeeping.)

The tool vendor might sell 50 seats of the debugger, if they are lucky, to the two big volume customers using this processor. At $5,000 per seat, their expected ROI is all of $250,000, leaving the tool vendor in the hole for $500,000. Therefore, in the tool vendor’s view, targeting a few big customers is a bad business plan. They aren’t going to risk their company’s money on a brand-new processor with only two or three design wins. A better strategy for them would be to wait a few months to see how well the new processor is accepted by the broader market. If their field sales offices get many phone calls from potential customers asking if they support the XYZ6000, the engineering team will crank up pretty quickly.

Note

A design win is a customer making a firm commitment to use a specific processor.

This wait-and-see attitude is not what the semiconductor manufacturer wants. Unless tools are available significantly before the first silicon reaches the general marketplace, they will not be available to the mega-VIP customers who want to be far into their development cycle.

Figure 10.4 show how these two players have conflicting goals. The tools vendor wants to see many design starts. (These design starts could be within the same company. A major telecommunication vendor buying 1,000 seats of a new debugger wouldn’t be too bad for business, but that’s usually rare.) The semiconductor manufacturer is primarily interested in a few critical, high-volume design wins.

The ideal solution is for the semiconductor manufacturer to provide the tool vendor additional funding to remove some or all of the riskof developing a new tool before there is good marketing data supporting the project.

Basically, the semiconductor manufacturer ends up giving the tool vendor nonrefundable engineering (NRE) payments to help balance the risk versus reward analysis that would normally tell them to stay away from this project. The size of this subsidy is heavily dependent on the customers and whether they already like the other products enough to require them for this new design. If you are a tool vendor, getting “spec’d in” by the customer is the only way to travel.

Anyway, all this behind-the-scenes intrigue is usually invisible to the customers, who have their own problems. If you are interested in which tools will support which processors, the way to find out is to see who is lunching together at the Embedded Systems Conference™.

Note

Today, most semiconductor vendors provide you with incredibly attractive data in the form of slick PowerPoint™ presentations describing in vague terms the large number of design starts forecast for this processor. However, if you ask them to name one, you are often told that this is proprietary information and they must protect their customer’s privacy.

From the Trenches

I once had the uncomfortable task of speaking to the Tool Support Group of a large telecommunications company that was in the process of evaluating a new processor (my company’s new embedded chip). The Tool Support Group had to evaluate the availability and the quality of the supporting tool suite that backed our processor. I was trying to convince them that, of the available compilers that supported our processor, their compiler of choice came out a distant third place out of three compilers that we evaluated. The compiler they preferred to use had performed satisfactorily with their old design, but the code generator section was a simple port from the old processor, with 16 registers, to our RISC processor, with many more registers. In our tests, their old compiler took about twice as long to run comparable sections of code as the best compiler. Naturally, I wanted them to switch to the new compiler.

I was politely, but firmly, informed that they had several million lines of code that they knew would compile with their current compiler, and they also owned several thousand seats of the old compiler. Furthermore, if my company and I really wanted them to switch to our processor, it was our job to improve the performance of their compiler to the point that it was reasonably close to the performance of the best compiler. I went back to the factory with the recommendation that we fund their compiler vendor’s improvement of the codegenerator section of their compiler.

Summary

Especially when coupled with pervasive network connectivity, reconfigurable hardware has the potential to revolutionize the industry. I’ve described reconfigurable hardware in terms of a processor coupled to a sea of gates, but, as Xilinx has demonstrated, the processor itself can be implemented within the sea of gates. What happens to the “processor selection” issue if the processor is just downloadable IP? If the entire program can be compiled directly to VHDL and then downloaded to an FPGA, will anyone care about the processor instruction set? Doesn’t the existence of a processor just become a cost optimization issue that can be solved by the silicon compiler? The compiler identifies the low performance portions of the algorithm and implements them as firmware executed by a processor, where the microcode for the processor is generated using something akin to a compression algorithm: most frequent operations in shortest opcode. Perhaps that’s far flung, but it’s not too far from what happens now in some resource scheduling tools available to IC designers.

If nothing else, widespread use of reconfigurable hardware could improve the likelihood of getting some good development tools. After all, FPGAs are pretty much a commodity product; one looks pretty much like another. Widespread use of commodity-class reconfigurable hardware would create a market in which tool vendors could focus on refining a small set of tools instead of continuously working to retarget their tool for the latest and greatest processor.

Unfortunately, the intrinsic difference between FPGA and other IC process costs might always favor fixed logic solutions. Still, if the toolset for reconfigurable hardware became refined and standardized enough, the promise of reduced development costs and improved time-to-market would be more than enough to offset the differential in hardware costs for projects with small-to-medium production runs. It could be that a few standard reconfigurable designs will eventually dominate the low-volume end of embedded systems (much as ARM and PowerPC now dominate the IP market). Who knows, perhaps some new process discovery will remove even the cost barrier.

At any rate, reconfigurable hardware is a technology to watch in the future.

Works Cited

1.Culbertson, W. Bruce et al. “Exploring Architectures for Volume Visualization on the Teramac Custom Computer,” in Proceedings of the 1996 IEEE Symposium on FPGA’s for Custom Computing Machines. Napa Valley, CA, 1996, 80–88.

2.Gott, Robert A. “Reconfigurable Processor Reincarnates the Venerable 8032.” Computer Design, October 1998, 38.

3.Snider, Greg et al. “The Teramac Configurable Computer Engine,” in Will Moore and Wayne Luk, editors, Field Programmable Logic and Applications. Berlin: Springer-Verlag, 1995, 44.

Index

Symbols

#pragma 90 _asm 90 _getmem() 81 _main 75, 78

Numerics

5001 Forum

See Nexus

A

absolute address 86 access time 178 address spaces code 71

data 71 I/O 72 system 71

unpopulated 72 addressing mode 86 algorithm

laser printer 8, 48 partitioning 8 allocation dynamic 71

architectural simulator 101, 115 arguments

passing 90 ARM 56

ASIC 50, 55, 62, 92 revision cost 58 assembly generating 76 inline 38, 90

pseudo-instruction 83 atomic code 99 automata

See statechart automatic variables 71

B

back annotation 107 background debug mode

See BDM

BDM 118, 149–155 command set 154 pinout 152

bed of nails 155 benchmarks 26–32 Dhrystone 26 distortions 27

EEMBC 29

LAPD 27

MIPS 26 big endian

See endian

bitwise operation 92 black-box tests 189, 191–192 board support package

See BSP

board tester 155 bond-outs 140 boot loader 105

boundary value tests 191 breakpoint xxiv, 116, 118–119, 122 hardware 173

register 119 BSP 35, 102 bugs

See also testing cost 53, 58, 187 historical 189 realtime 195 synchronization 99 burglar alarm 98

byte order 12, 112–114

See also endian

C

C run-time 78 cache 95, 139–140 D-cache 139

hit 101 I-cache 139

performance 204 traceable 140 triggering 141 CASE tools 107 cast 92 checksum

ROM 78 chip vendors

and tools 220–224 CMOS xxii

code coverage 144

density vs speed 95 generation 39 optimization 80, 93 patches 14 placement 82 quality 144

section 84 size

bloat 106 reducing size 80

decision 198

hardware instrumentation 199 ISR 201

logic analyzer 200 measuring 197–201 modified condition 198 software instrumentation 197 tools 198

co-verification 61, 196 critical

sequence 195 cross compiler 38

cross-triggering 177, 180 crt0 78–79

customer interviews 4, 6

D

data section 84 space 71

Dataquest 106

Team-Fly®