The constant drive to announce improved products with new features can force frequent changes in both hardware and firmware. New chips and firmware may be produced that are mostly the same as their predecessors but with a few new features or tweaks. Ideally, any version of firmware will work with any version of hardware (version independence), but there will always be differences that must be handled. Firmware can often accommodate differences but only if it can correctly identify the chip it is using.

Chips often have a read-only register that contains an ID code that identifies the chip. A common method is to have a vendor code and a device code. This gives a general view of what the chip is. From that ID code, firmware can know many things about the chip, such as the blocks it contains and their respective base addresses.

• Best Practice: Provide an ID register that uniquely identifies the chip.

It is not uncommon for the same ID code to be assigned to different versions of the same chip with differences due to bug fixes or other minor changes. Some of those changes can impact firmware, which may need to be redesigned to avoid or work around defects in the chip. Consequently, when a corrected version of the chip is produced with the same ID, firmware needs additional information about which chip version it is using. This additional version information should be provided through a separate version register that always gets updated when a chip changes. The combination of ID register and version register allows firmware to uniquely identify the chip revision and determine what adjustments are necessary for the minor changes.

It’s important to update the version register with every hardware revision, even if no functional differences in the revision require changes in the firmware. I worked on one printer that had an ASIC manufactured with the wrong pads, causing an excessive draw of current, heating up the part. In this case, we caught it before shipping it in products. Had those parts been distributed, we could have easily modified firmware to use the version number to track down those high-current parts.

• Best Practice: Provide a version register in the chip and update the version number with every hardware revision.

Having ID and version registers at the chip level helps firmware know which chip it is accessing. However, most chips consist of several different blocks, such as I/O or video processing, each serviced by its own driver. The same version of a block may exist across several different families and generations of chips. Building a database in each driver of all chip IDs it can operate on can be cumbersome.

Providing ID and version registers at the block level would solve this problem. The version number would stay the same for that block (as long as the block is identical) no matter the chip; if a driver recognizes the block ID and version, then it can operate on that block, no matter what the chip ID and version are.

• Best Practice: Provide block-level ID and version registers for each block on a chip. Update the block’s version number only when that block changes, not when other components on the chip change.

If it is not possible to dedicate a register to track the hardware version, look for other ways to distinguish one hardware revision from the next. If adding a new register, reading some ones from that register would indicate the newer version, whereas reading only zeros from that location would indicate the older version since it was a non-existent register. Or perhaps you could use an existing register that had a previously-unused bit (which always returned 0 when read) that now always returns 1.

• Best Practice: If no dedicated version register can be provided, identify the hardware revision using new registers or bits from existing registers.

Not only are ID and version registers useful in ASICs, they can be very useful in FPGAs, which are designed to be changed frequently. In FPGA-based platforms deployed across research and design organizations or among customers in the field, there will likely be different versions of the FPGA code in use due to the reality that not all platforms will be consistently updated. ID and version numbers helps firmware know which hardware version it is running on.

Until the next version…