Tips for firmware-friendly register design

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?

Operational characteristics

The true purpose of the "Enable_DecMeth_Write" 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.

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 previous article. This is a bit field that modifies the operational parameters of the logic block, and that must be changed only when the logic block is stopped.

The "Enable_DecMeth_Write" bit simply controls access to a configuration bit. Technically, changing this bit during operation has no effect on the operation; it could be toggled every clock cycle with no effect as long as the "DecMeth" bit field is not touched. Based upon the rules outlined in my previous article, this bit would then be considered a Control Register bit.

It could be argued that, despite the fact that modifying the "Enable_DecMeth_Write" bit during operation has no effect on the operation of the logic block, it is only truly meaningful when the logic block is in a stopped state. Thus, this bit could possibly be considered a configuration bit and share the same register as the "DecMeth" bit.

Consider the following example:

Assume that the "Enable_DecMeth_Write" and "DecMeth" bits are in the same configuration register. The specification states that the "Enable_DecMeth_Write" bit must be high to modify the "DecMeth" bit field. It also states that the "Enable_DecMeth_Write" bit field must be reset before the change will affect the operation of the hardware function. Which of the following scenarios is legal?

• The micro sets the "Enable_DecMeth_Write" bit and modifies the "DecMeth" bit field on a single (read-modify-write) access to the register. The micro then resets the "Enable_DecMeth_Write" bit to activate the change to the "DecMeth" bit field.
• The micro sets the "Enable_DecMeth_Write" bit, alone. The micro then modifies the "DecMeth" bit field and resets the "Enable_DecMeth_Write" bit on a single access to the register. This changes the "DecMeth" bit field value and activates the change in a single step.
• The micro sets the "Enable_DecMeth_Write" bit, alone. The micro then modifies the "DecMeth" bit field alone. Finally, the micro resets the "Enable_DecMeth_Write" bit to activate the change to the "DecMeth" bit field.

Locating the write-enable bit in the control register eliminates the confusion regarding simultaneous modifications to the two bit fields. The same is true if the write-enable bit is placed in a separate configuration register from the "DecMeth" bit. The two bit fields may be placed in the same configuration register if the specification explicitly states when simultaneous modification of the two fields is possible.

Several rules for clean, easy to control, hardware design can be extracted from this example:

• When controlling access to a configuration register bit field, the access enable bit should be designed such that it must be reset before the new value takes effect. This also holds true for access control of bit fields in a control register.
• The access control to a configuration register bit field may be considered a control bit or a configuration bit, but all such bits should be treated in the same manner in the embedded system IC.
• Note that the access control to a control register bit field is always a control bit; if the controlled bit can be changed during operation then its enable must also be modifiable during operation.
• An access control bit may be located in the same register as the controlled bit field but this is not recommended. All access control bits in an embedded system IC should possess the same relationship to the controlled bit fields.
• If the access control bit field is located in the same register as the controlled bit field, the specification should detail the results of simultaneous writes to the control bit and the configuration bit field. Both simultaneous enables and simultaneous disables should be covered in the specification. All bit fields of this type in the embedded system IC should possess the same behavior.

Note that, given the scenario above, it may seem a good idea to make the "Go" bit the access control for the "DecMeth" bit. This is not a good idea and leads to the next item for discussion.

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:

• A "Go" bit is reset by hardware to show that the controlled function is no longer active. This design practice is discussed later in this article.
• Clearing an interrupt bit causes a function to resume. Allow firmware to start a function from the "Go" bit of that function.
• A control bit controls one capability when the hardware logic is set to mode A, but has another capability when the hardware logic is set to mode B. Doubling up functions in this manner simply means the firmware engineer must keep track of which function applies when. It would be cleaner and easier if control bits for a specific operational mode were assigned to separate bits; either a different register or a separate section of the current register would work well.

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 about 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.

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 all 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).