Making Way For Register Specification Software

No one gives much thought to the heating, ventilation and air conditioning registers in the house –– typically, two in each room, one for supply, the other for return. That is, until the lever in each needs to be manually adjusted to modulate the temperature to be hotter or colder, or the seasons change and the filters with them.

Alas, registers in hardware design seem to have gotten the same indifferent treatment, though they are an important communications conduit and the primary interface between the hardware and the software (or firmware) that talks to it.

All of the hardware’s functionality is programmed into the often-overlooked registers. The functionality of the hardware is determined by the software, which reads from and writes to those registers. The hardware, then, communicates information to the software through the registers for the software to read. Registers act as a continuous two-way communications conduit.

In many ways, registers are gate keepers, in addition to being regulators, and share storage between the hardware and software. A register ensures a chip’s configurability as well. A configurable chip is more versatile and generates a greater return on investment, obviously.

Changing the configuration of the hardware design is done by changing the register, just like adjusting the heating and air conditioning register settings. And because hardware designs include blocks of IP, each with a set of registers, there could be loads of them that control and maintain the status of the chip. All of them need to work together seamlessly, something system architects and design engineers care about.

System architects and design engineers are focused also on the increasing number of registers. While more registers means more functionality and configurability, more is not always better: it can mean too much data. Any changes with the data can wreak havoc on the delicate two-way communications with the registers. Perhaps most distressing is how often a register is the source of a bug due to mismatched specification or implementation information, the wrong register address, or the wrong description. An annoyance that has become an onerous bug or bugs. Worse yet, a bug or malfunction can cause failure in the whole system.

The need for a verification methodology to address register verification challenges to automate the tedious, manual effort had become acute. Software to test and validate the registers was needed. Luckily, commercially available products have become available and are useful, cost-effective tools that increase the quality of the design and enhance productivity. They offer a simple and intuitive way to create an executable specification that generates design, verification and software models, and supports the verification standard Universal Verification Methodology (UVM) as well as IP-XACT and SystemRDL.

This software has reversed the traditional engineering process in a way that lets a system architect or design engineer easily change the register’s design specification. Those changes are made automatically in the application software and firmware, hardware design and verification, device drivers to lab debug and diagnostics through tech docs.

Summer’s coming to the US and homeowners are changing the filters on their heating, ventilation and air conditioning systems and dusting the registers. Engineering teams could change their filters and dust off their verification flows to make way for register specification software.

Coincidentally, as I was working on this blog post, it occurred to me that a system architect “borrowed” the term register from the HVAC market to apply it to SoC design. If so, he or she picked a good analogy.

A typical HVAC register in the ceiling or floor of a residence looks like this. Typically, a room will have two registers, one for air supply, the other for air return.