Embedded Systems Design - August 2008 - (Page 9)

0808esd.p09, 43 7/17/08 11:30 AM Page 9 parity bit Code reuse is common sense I this inefﬁciency, and FPGAs, ASIC, and on a piece of silicon. That forced sysread with interest Jack Ganssle’s IP have become increasingly a part of “Faster!” and the feedback it generat- tems to be made from a collection of the landscape. Even with IP, though, ed. (Breakpoints, June 2008, p.53; Par- components, which in turn had to have there are standardized interfaces bora standardized interface. Even today ity Bit, July 2008, p., all availrowed from our history, just simpler, able at www.embedded.com/ less power-greedy ones. They still 208400913) For most of my add to the size of the die and its pow30-year software-developer consumption, and the designer ment career, I’ve heard the must decide to what extent to work constant message that there at a lower level and eliminate some of aren’t enough programmers, them in the interest of size and powsoftware is too expensive, we er budgets or leave them alone in the need reuse, more abstraction; interest of schedule deadlines and and seen various attempts at costs. making it happen. When I Software has taken exactly the started, programs had hunopposite approach. It started without dreds or thousands of lines of interface standards. Software reuse code and memory was in KB. has suggested the need for such Now programs contain milstandards, but like hardware, lions of lines of code and ocNeither the 65-hour work week there is a price to be paid for that cupy GB of memory. Little else has changed. Doomsday never nor the “mythical man month” are standardization. Likewise higherarrived, nor did a solution. programming or computer issues. level languages, while offering a more abstraction, also extract First, neither the 65-hour Both are management issues . . . price in efﬁciency. With clock workweek nor the “mythical speeds in the GHz and memory man month” are programming in the MB and GB region, the tendency you can buy just about any 8- or 16-bit or computer issues. Both are manageCPU and some SRAM and with the ad- is to move in that direction with abanment issues and can be solved and have don. I was interviewing some consultdition of 8 or 16 data lines, a dozen or been solved in organizations willing to ants recently for a project I needed to two address lines, and three control address them. I really don’t need a new outsource. One recommended doing it lines have them communicate. The cell phone every year or two with yet in Java. I asked him about efﬁciency, physical package boundary reinforced more features I can’t use unless I spend and he assured me it was so close to C this. two days reading the manual. The time and C++ as to be down in the noise and Of course, if you were to build a 3crunch for most of this stuff exists only GHz Pentium desktop out of such com- sent me some links to studies giving into beneﬁt the market position of the ponents, it wouldn’t run anywhere close formation. While I had to admit the company peddling the product, which numbers looked better than I expected, to 3 GHz and would consume thouin theory is supposed to beneﬁt the the general consensus of the papers was sands of watts of power. The inefﬁcienprosperity of society, but in practice only has a positive impact on those well cies of converting every signal to a stan- that the performance hit was no more than 2:1. Well, on an otherwise idle, dard interface on that scale, with above median income. state-of-the-art desktop computer that enough drive to reach all destinations Regarding Jim Ford’s question, may not seem signiﬁcant, but as I read quickly enough would consume far “Why is there so much difference bethe concerns about the large percentage more power than any useful work tween hardware and software?” Hardof our electrical power being consumed would. We consider such totally unacware got off to a fundamentally differby major server farms (which happen ceptable, and hence—especially in the ent start, thanks to packaging. Early embedded world—ICs have increased devices had to be task speciﬁc because CONTINUED ON PAGE 43 in density and integration, eliminating of the limitations of what could be put www.embedded.com | embedded systems design | AUGUST 2008 9 http://www.embedded.com/208400913 http://www.embedded.com/208400913 http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - August 2008

Embedded Systems Design - August 2008 Contents Number Include Parity Bit Programmer's Toolbox Cover Feature: Virtualization for Embedded X86 Multiprocessor Applications Wanted: Industry Standards for Benchmarking Embedded VMM Hypervisors Achieving Cache Coherence in a MIPS32 Multicore Design Memory Allocation in C Advertising Index Break Points Marketplace

Embedded Systems Design - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.