When engineers talk about compatibility, they often pose a binary question: Are two things compatible with each other or not? However, in my experience, the question of compatibility is not so cut-and-dried. For hardware-firmware integration, at least, compatibility is a matter of degree.

Early in the development of a new version of a block, engineers should weigh the time and cost of maintaining a certain degree of compatibility between the block and existing device drivers against the time and cost of updating or rewriting those drivers. Often, the extra effort to keep the hardware backwards compatible results in lower cost and faster time to market for the product as a whole. The following scale can be used to measure the degree of compatibility between a new version of a block and its associated driver.

• No Impact: The changes to the block do not affect the way it interacts with its device driver. No change to the device driver is needed, but full regression tests should be performed to verify 100% compatibility, especially in terms of behavior, results, and timing.
• Superset: Different versions of the block supports different subsets from the same superset. The device driver is set up to support the superset and can determine, by reading registers, which subset it is working with. Therefore the device driver does not need updating.
• Legacy Mode: The new block powers up in legacy mode, making it look like the old block, allowing old device drivers to work on it. However, to take advantage of new features, new device drivers will be needed to get it out of legacy mode and enable the new features.
• Version Number: A version number in the block allows device drivers to know which version of the block it is working with. This forces device drivers to be updated for new versions but allows those new drivers to support several versions based on the version number. With a version number, old device drivers will recognize that they do not support that version and will flag an error.
• Other Version Indicators: If there is no version number, device drivers could use clues, such as a bit that is set in one version and not the other, to determine how it should operate. But in this case, there is danger because old drivers will not recognize that they are running a new block, and the resulting behavior is unpredictable.
• Incompatible: The changes are too many and too drastic. It is better to have a separate device driver that does not support the old. Determine this by estimating the percentage of lines that needs to change from the old to the new. If significant, with a threshold somewhere between 10 and 50%, then the device drivers should be separate.

The closer changes in the new version of the block are to the top of this list, the easier firmware is to port and maintain. Analyze each change being considered for the block. Can the change be done differently so as to move it higher on the compatibility scale?

• Best Practice: Maximize the degree of compatibility with firmware when a new version of the block cannot be completely backwards compatible.

Until the next compatibility issue…