Embedded Systems November 2000 Vol13_12

Issue link:

Contents of this Issue


Page 8 of 189

Parity Bit Memories H avi ng spent several decades work- ing in the silicon side of the memory business, I've seen more returned components and dissatis- fied customers due to wiring and cir- cuit board issues than any other sin- gle issue. Nearly all of the problems would have been detected and resolved by testing software such as Michael Barr outlined in his article "Software Based Memory Testing." (July 2000, p. 28). In general, I'd say that the time spent on blaming the component was as much as the time to develop testing code. However, I do have to take excep- tion to Mr. Barr's statement that issues are rarely a chip problem and if so, it's reasonable to assume the problem will be catastrophic. While this is generally true in production environments, I've found that it is not the case during product development. Board and component handling in the design and prototyping stage is rarely as rig- orous as the production environment and about 10 times as many defects are introduced through electrostatic discharge and mechanical issues in the lab than in production. These defects are rarely catastrophic and in memories are generally single bit fail- ures and frequently are timing related. I'd strongly encourage developers to at least hack out a comprehensive device test for preproduction. Mark Markham B uc KHOR N SoFT WA RE S ER V I C E S exists, I haven't been able to find any- thing on how to actually code tl1em. The framework for coding HSMs that Mr. Samek and Mr. Montgomery pre- sent is well thought out and makes a lot of sense (although after re-reading the article for the tenth time I had to chuckle at the title on the cover, "Nested State Machines Made Simple"). It is fairly simple, once you get your mind around it. I down- loaded tl1e accompanying code from and had it compiled and running in a few min- utes. That's a lot more than I can say for some commercial software I have used. Peter Wiktor EN G I NE ERIN G ARTS Because of the pain and agony involved! When I design a chip into a hard- ware system, the chip is supplied to me essentially as a black box with a fu lly specified interface to the out- side world provided by the vendor. The vendor knows that unless I know exactly how the chip works, I can 't design it into the system. Input A results in output X, input B results in output Y, and so on. Chips vary in complexity from devices that can be adequately described in a few pages to multi-million-transistor CPUs that require books to fully document. Producing this documentation i not necessarily easy, but it is done Component cost/benefit J ack Can sle's article "Faster!" in the 2001 Buyer's Guide issue holds much wisdom. We've been hearing the manu·a of software reuse for over a decade now. In the early '90s you couldn't pick up a trade rag that did not espouse d1e virtues and necessity of software reuse, "component" soft- ware, and so on. It was obvious then, that with the increasing complexity and sophisti- cation of products con!:l icting directly with demands for reduced time to market, the road out would not be to reinvent the wheel with each new project. Since then, we've seen compo- State-oriented praise I 've been looking for an article like "State-Oriented Programming" (August 2000, p. 22) for over a year now. Although a lot of literature on hierarchial state machines (HSMs) nent software become commonplace on the desktop. Purpose-built soft- ware packages and tools available for purchase off the shelf have multi- plied. My experiences in using such off-the-shelf components stand out in my memory high above other development experiences. Why? because it is necessary. Without it, the vendor won' t be able to sell its product. When I design a software compo- nent into a system, the scenario is typ- ically quite different. The purported "productivity gain" to be obtained is partially, if not entirely, burned up in debugging problems associated with use of the component. Inevitably, it seems, peculiariti. my application lead into comers of me docwnentation where the needed infor- mation is sparse or non-existent. Then I find myself doing multiple passes of oial- and-error testing to find out what combi- nation of inputs will produce tl1e desired output. The time saved in using an off- the-shelf component is lost in reverse enginee•;ng it to obtain me needed information! All too often I find it isn 't possible to do exactly what is desired, forcing me to accept some compromise or contrive some workarmmd. All mis extra effort cancels, to some degree, me time saved by not "rolling my own." And all this is in addition to plain old bugs, where me software product simply does not function as advertised. The fre- Embedded Systems Programming NOVEMBER 2000 7 es of

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12