The Embedded Bridge
Providing Best Practices to
Bridge the Hardware/Firmware Divide

Issue #5 – January, 2007
<prev    Home    Index    next>

In this issue: designing for version independence.

If you’re attending the Embedded Systems Conference (www.embedded.com/esc/sv/), April 1-5, 2007, in San Jose, Calif., mark your calendar now to attend the following session:

ESC-262 Twenty-five Lessons Learned in Hardware/Firmware Interface Design
Speaker: Gary Stringham
4:30-6:00 p.m. Tuesday, April 3.

Drawing upon real-world experiences of engineers, this class discusses twenty-five examples of how to address chip design issues discovered after the chip had been fabricated. Some workarounds are clever, some are basic, but all yield insights about firmware workarounds and chip designs that can address common problems in embedded systems development.

If you cannot attend the session but would like to meet during the conference, let me know. www.garystringham.com/contact.

Late in the development of a new printer, a third-party print engine that interfaced with a block on the ASIC changed its interface behavior. The print engine would quit sending pulses before the block was done with its job, causing the block to hang waiting for more pulses. This behavior existed in other printer models; their associated blocks had support to detect early pulse termination. Because this new printer’s block did not have that support, I had to create a firmware workaround for it.

I tried three different algorithms over a three-week period and finally settled on one, even though under rare circumstances, it had a severe performance penalty. Unfortunately, one particular customer bought several of these printers for a specific application and experienced this rare circumstance that cut print speed in half for every page. Obviously the customer was dissatisfied and threatened to return the printers and cancel the large order, which included other printer models. I spent another two weeks to come up with a fourth algorithm that avoided the penalty. We upgraded the customer’s printers and they were happy.

Had this particular block had the early termination support (at a low cost of a few hundred gates), we could have accommodated this late product change with a one-hour firmware change. Instead, beyond nearly costing us a major contract, it also cost five weeks of engineering effort, thousands of warranty dollars and some damage to our reputation.

In contrast, we had an ASIC that was designed for portrait-format printers that was being investigated for use in landscape-format printers. The ASIC was based off previous ASICs that did support landscape-format printers. The engineers did not remove the landscape-format support even though the ASIC was not targeted for landscape-format printers. ASICs for landscape-format printers require more onboard memory in several places in the pipeline to accommodate longer scan lines. Reducing the memory requirement would have reduced their gate count, but they decided not to do that when they made this ASIC.

After verifying that landscape-format support was still in the ASIC, we used them in landscape-format printers. This saved us millions of dollars and several months from having to develop and produce a new ASIC.

Ideally, every ASIC will support any product, whether old or new, high-end or low-end. Since that is not realistic, choices have to be made. Old functionality can be removed once you are sure that it will never be needed again, even for mid-life kicker products. Functionality with large gate-count requirements that is only needed for specific family lines of products could be removed. But where possible, leave as much functionality in an ASIC, even if not all of it is needed for the targeted products.

Best Practice: Implement and retain all known low-overhead functionality in a block, even if the current requirements do not call for it.

If you have comments, pro or con, about this month’s topic, please send them to newsletter@garystringham.com. For training and consulting on this and many other bridge-building topics, visit www.garystringham.com/contact.

Next month: designing for contingencies.

Until the next shipment,

Gary

The Embedded Bridge
<prev    Home    Index    next>

The Embedded Bridge is a monthly newsletter containing best practices on improving the interface between hardware and firmware. Comments on the topic or suggestions for future topics are welcomed. Send them to newsletter@garystringham.com. The newsletter is a free service of Gary Stringham & Associates, LLC, www.garystringham.com, a firm providing consulting and training services to embedded systems engineers.

Visit http://www.garystringham.com/newsletter to subscribe or unsubscribe. You may view our privacy statement here.

Feel free to pass this newsletter along to your colleagues. To use this newsletter for commercial purposes, write to info@garystringham.com for information.

Copyright © 2007 by Gary Stringham & Associates, LLC. All Rights Reserved.