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

Issue #17 – January, 2008
<prev    Home    Index    next>

If you’re attending the Embedded Systems Conference (www.cmp-egevents.com/web/esv/home), April 14-18, 2008, in San Jose, California, mark your calendar now to attend either or both of these sessions that I will be presenting:

ESC-106 Best Practices in Hardware/Firmware Interface Design
Full-day tutorial: 8:30am - 4:30pm, Monday, April 14
Room: J1

ESC-346 Twenty-five Lessons Learned in Hardware/Firmware Interface Design
90-minute class: 2:00pm - 3:30pm, Wednesday, April 16
Room: J1

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

A client recently asked me to write down some suggestions of best practices and process improvements for his company. I noted several suggestions, sorted them into four categories, and started writing them up. Partway through this process, I noticed that two of my recommendations seemed to contradict each other. On one hand, I said not to force the whole company to use the same software toolset. On the other hand, I also said that everybody on the same project should use the same software toolset. So, what was I advocating? Should everybody use the same toolset or not?

As I pondered this apparent contradiction, I stepped back to consider the value of all my suggestions, when an abstract thought came to my engineering brain: “Intangible Benefits.” Engineers love to measure things and assign a number. But how do you measure something intangible? You can’t, but there are times when you must take it into consideration.

For example, buying software X over software Y because X is cheaper than Y is based on a tangible benefit of measurable cost savings. However, if engineers using software X take 50% longer to do their job than engineers using software Y, that’s bad. There is an intangible benefit to buying software Y in terms of engineering productivity. Measuring productivity is imprecise and takes a long time. Was it really 50% better? Maybe it was 25% better or 75% better. Unfortunately, companies typically do not have the luxury of buying and installing both X and Y, then letting the engineers work for a year while collecting data so that tangible results can be measured. Instead, we make our best guess. Software X may be cheaper, but software Y might make a team of several engineers more productive, an intangible benefit.

In the hardware/firmware realm, here are three best practices that have intangible benefits.

Best Practice: Firmware engineers should read the chip’s external specification during the chip’s design phase and provide feedback in a timely manner on the chip’s design, functionality, and documentation.

This practice can help catch hardware problems early on, when they are still easily correctible, providing the intangible benefit of saving time, cost, and headaches in the future.

Best Practice: Provide an abort for each task in the block.

I have seen a few cases where not following this second practice required extensive engineering effort down the line to work around this lack of functionality. When such a problem occurs, we can measure how much effort we had to spend to work around it. But, how do we measure the intangible benefit of effort not spent to solve a problem that did not occur because we followed good engineering practices?

Best Practice: Add a register showing the level of key signals internal to the block.

What is the intangible benefit of adding nine debug hooks that are never used? Probably not much. But what is the benefit of adding a tenth debug hook used to solve a difficult problem? I have used several debug hooks over the years. Some helped to quickly diagnose a problem, saving a few days of effort. Others were used to work around defects that, had the hook not been in the chip, would have required a chip respin costing at least a three-month delay and $500,000.

Finally, back to my question in the opening paragraph: Should everybody be forced to use the same toolset or not? The answer is “yes” for those on the same team, but “no” for the whole company. All car mechanics on the BMW team should have the BMW special tools, but the BMW special tools will not help those on the Honda team.

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.

Until the next intangibly beneficial newsletter,

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. You may view our privacy statement here.

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

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