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

Issue #21 – June, 2008
<prev    Home    Index    next>

I will be presenting “Best Practices in Hardware/Firmware Interface Design” at the Embedded Systems Conference in Boston in October (www.embedded.com/esc/boston). I gave this same class at the San Jose conference and it was a success. One attendee wrote to me afterwards:

“I just wanted to tell you that your one-day class was incredibly valuable!” Keith Huster, Senior Electrical Engineer, Hill-Rom

We offer an expanded version of that one-day class as a three- or four-day best practices workshop. This workshop could help you avoid costly chip respins, speed up your hardware/firmware integration and produce higher-quality products. Sign up for a workshop today.

We have all dealt with the pain of inaccurate and out-of-date register information. Registers and bits are modified in hardware but the documents are not updated. Documents are updated but firmware is not changed. Or typos are introduced along the way. Failure to catch these problems typically results in hours wasted on debugging that could and should have been avoided.

Design teams have attempted to solve this problem by using scripts to extract register information from hardware Verilog and VHDL files and converting them into firmware C header files. One that I saw only extracted register names and addresses but not bit information. It also did not produce documentation. Maintaining these in-house tools add an additional burden to the team.

At the Design Automation Conference (DAC) (www.dac.com) last week, I saw four products that claim to address this issue:

The key feature of each product is the ability to keep all pertinent files in sync. Each requires the user to maintain register and bit information, including addresses and descriptions, in an input file (or files.) The user must then use the provided tools to process the input file(s) to generate a variety of hardware, firmware, and documentation files. Lastly, the user can re-synthesize the generated hardware files and re-compile the generated firmware files to update their respective components. To change the hardware design, the user presumably needs only update the input file(s) and rerun these steps, rather than undertake the arduous and error-prone task of manually updating the various hardware, firmware, and documentation files.

These tools have the potential added benefit in that they encourage interdisciplinary interactions between hardware and firmware engineers by improving communication between them, and allowing firmware engineers a chance to review the designs sooner in document format. This collaboration leads to better product development.

Best Practice: Use automated tools to generate hardware documentation and firmware header files from chip design files.

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 compile,

Gary

*Full disclosure: Gary Stringham & Associates is a business partner with Semifore, Inc.

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.