This is the fourth in a series of newsletters that present seven principles to help guide your own processes and best practices in hardware/firmware interface design. This month’s principle focuses on maintaining compatibility between versions of hardware and versions of firmware.

Designing for compatibility means to design in such a way as to facilitate, where possible, the ability for any version of firmware and any version of hardware to be paired up.

Cell phones are a good example of this. Many, many different models of cell phones exist but some are very alike. Different phones may have a variety of skins and colors but their hardware and firmware can be very similar. Cell phones can be upgraded with newer versions of firmware with new features; meanwhile, different (but similar) models of cell phones may be equipped with the same firmware.

In some cases, for example, firmware can be set up to support many features and then—through the use of configuration files, NVRAM settings, compile-time switches, and so on—only the required features will be enabled. The relevant hardware blocks would be designed with full support for all features, while the firmware would control which features are actually used. This allows the same hardware to be installed in different models of the product while still presenting different features to the outside world.

Designing for compatibility also means that when a new version of hardware is released with new features, it won’t break when paired with older versions of the device driver, thereby allowing reuse of the old device driver. This is accomplished by following rules such as not moving bits and registers around. Compatibility is especially useful when multiple versions of hardware and firmware are deployed during product development and among customers. It reduces development time, saves costs, and gets the product out to customers sooner.

Firmware is becoming more and more expensive; in some cases, developing firmware can cost more than hardware. Also, it can be difficult to change firmware due to its many components, layers, and architecture. This increases the importance of striving for compatibility in hardware so as to minimize changes forced upon firmware.

Pairing any version of firmware with any version of hardware is ideal but not practical all of the time. However, it is a vision to strive for. Bearing compatibility in mind while designing from the beginning will lead to decisions that move toward that goal.

• Principle 4: Design for Compatibility.

Until my next compatible newsletter…