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 t hat 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.
“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).
