Tips for firmware-friendly register design

Tips for firmware-friendly register design
By David A. Fechser, EEdesign
August 14, 2003 (3:02 p.m. EST)
URL: http://www.eetimes.com/story/OEG20030814S0023

In my previous EEdesign feature, "Making hardware modules firmware friendly," I discussed some simple rules for organizing hardware modules in an embedded system to improve the ease with which those modules can be understood by firmware designers. This article also deals with the design of hardware modules. This article, however, delves deeper into the actual design of the registers and other storage elements.

Design using these techniques further improves the firmware engineer's ability to spend less time trying to understand specification documents, and more time designing control code. This means tighter schedules, earlier working firmware, and faster time to market for the target system.

Controlling accessibility to register bit fields

It is sometimes desirable to restrict access to some register bit fields. This is often done with a write-enable bit . For example:

Logic block XYZZY is designed to decode an incoming bit stream to extract data from the encoded bits that are received. The configuration register contains a bit field called “DecMeth” which determines the method used to decode the incoming bits and extract the meaningful data. It is already established that this method cannot change midstream; otherwise, important data will be lost.

In order to prevent the modification of the XYZZY decode method midstream, the “Enable_DecMeth_Write” control bit is created. This bit controls the ability to change the “DecMeth” bit field.

Two questions must be answered at this point:

Where should the “Enable_DecMeth_Write” control bit reside?
What are the operational characteristics of the “Enable_DecMeth_Write” bit?

The key to these questions is to “Keep It Simple” and think in terms of the user. Let's address the second question first.

Operational characteristics

The true purpose of the “Enable_DecMeth_Wri te” bit is to avoid erroneous changes to the configuration bit. When the write-enable bit is inactive, any accesses to the configuration register will have no effect on the “DecMeth” bit field. To keep it simple, we will specify that the write-enable bit must be set to high in order for write accesses to the “DecMeth” bit field to be effective.

To further protect the access, we will specify that the write-enable bit must be reset before the new “DecMeth” bit field value will take affect. This forces the micro to restrict access to the bit field for actual operation. In other words, in order to write the DecMeth bit, the following multi-step process must be used:

Set the “Enable_DecMeth_Write” bit to enable access to the “DecMeth” bit.
Modify the “DecMeth” bit along with any other bits in the register.
Reset the “Enable_DecMeth_Write” bit to activate the new value of the “DecMeth” bit.

If this process seems long and convoluted, it is intentionally that way in order to avoid erron eous modification of the “DecMeth” bit.

Location

Notice that “DecMeth” is a bit field in the configuration register. The choice of the configuration register for this bit field is described in my
Figure 1 — Bit field access control example

Multi-function register bit fields

When designing the microprocessor interface of an embedded system, simple is good. Every bit of complexity in the interface means wasted time for the programmer to determine what is required to control the system. Note that this does not mean the hardware should be simple; only the interface need be simple.

A “multi-function” bit-field does more than one task. Individually, each combination of functions on a single register bit are simple. However, in today's embedded ICs, with 1000+ thirty-two bit registers, this technique results in hundreds of “special” bit fields which cannot be changed unless the user is fully aware of all the consequences. Most programmers cannot keep every special case in their head and so must refer to the specification on nearly every register access if special cases exist in the design. This translates into slow firmware design and debug.

Some common practices that fall under this category (and should be avoided) are:

“Go” bits should be in a register that does not contain configuration or status bits.

After addressing multi-function register bits, “Go” bits need to be mentioned simply because they can be so easily abused. One reason for this is the difficulty in determining the characteristics of a “Go” bit. Is the bit a configuration bit or a control bit? Can it be used as a status bit as well?

A properly designed “Go” bit will also be a “Stop” bit when disabled. In other words, if the processor sets the bit to cause a hardware function to begin operation, clearing the bit should cause the function to stop. Whether this is a graceful stop or a catastrophic stop is up to the hardware engineer, but it is hoped that a graceful stop can be provided by this control.

The ability to stop a current operation with the “Go” bit means that this bit must be considered a control bit and treated as such in a design. The firmware can change this bit at any time to affect the operation of the function. This also means the firmware engineer can feel comfortable modifying any other bit in the register at the same time that the “Go” bit is modified.

If the “Go” bit were treated as a configuration bit, then a concern develops about every other bit in that register. The firmware engineer must worry abo ut the affects of changing the configuration at the same time as the function is started or stopped.

A common practice in embedded IC design is to treat the “Go” bit as both a control bit and as a status bit. For example, the microprocessor can set the bit to start the operation, but when an exception occurs that requires the operation to be halted, the hardware resets this bit. There are definite issues with firmware when this is done:

The processor can no longer tell whether firmware or hardware stopped the hardware process.
In order to read the status of the hardware operation, the processor must now read both the status register and the control register.

A better practice is to assign a status register bit (sometimes called “Busy”) to indicate whether the hardware is active or not. When in an ISR, the firmware can monitor only this single register to determine the run status of the hardware. The “Go” bit is simply a control bit where a '1' written to the bit will start the hard ware function.

The ideal design of a “Go” bit would not require the firmware to clear the bit before restarting. In other words, if the hardware has stopped an operation then the “Go” bit (as a control bit) will still be set high. Restarting the operation should only require that a “1” be written to that register bit. The writing of a “1” to the “Go” bit, regardless of the previous value of the bit, should be taking as a hardware start signal.

Figure 2 — Separating a Go bit from the Busy status

“Go” bits may be grouped into a single register from multiple hardware blocks.

“Go” bit registers, top level reset registers, and top level interrupt registers are the only cases where strict encapsulation of hardware block registers may be violated. This allows the firmware to kick off hardware functionality with a minimum amount of processor time.

This situation should be clearly delineated in the specification. Every logic block description should contain text that indicates where the “Go” bit for that logic block resides. The Go register should be located with other general IC-level registers such as the global interrupt and reset registers.

Purists may say that this violates the whole principle of hardware encapsulation. While this is true, the same can also be said about reset and interrupt registers. The fact remains that the purpose of the microprocessor interface is to facilitate efficient use of firmware, and each of these generalized registers does just that.

If the “Go” bits are each located within the register map of their own logic block, the firmware must start each logic block separately. This means the firmware must be certain that, for example, starting block A before block B is acceptable behavior. If hardware functions are started in the wrong order, a hardware block may hang due to unexpected inputs or timeout before everything is running.

Once al l the hardware logical blocks have been configured, and it is time to begin the operations, collected “Go” bits allow all to be started at once. The firmware doesn't need to worry about any start order (for instance, whether block A requires block B to start first).

This situation should be clearly delineated in the specification. This is recommended simply because it decreases the code size and greatly increases the operational efficiency of the code.

David Fechser is a senior staff engineer working for the Systems Verification group of the Storage Products Division at LSI Logic Corp. David lives in Fort Collins, Colorado and can be contacted at 970-206-5678 (dave.fechser@lsil.com).