Firmware-friendly reset design

Firmware-friendly reset design
By Dave Fechser, EEdesign
February 28, 2003 (4:53 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020712S0073

When hardware is developed, the first state considered by the designer is the reset or power-up state. This usually results in every element of the IC coming out of the power-up sequence in a default state. This "default" state could just as well be called the "useless" state. The first thing done by the controlling firmware is to program all the storage elements to useful values.

The problem with this design practice is that program memory space is often at a premium in embedded systems. The initialization software can become a major contributor to the size of the code, and yet is only used once in the actual operation. Fortunately, there's a better way. This paper will discuss design practices and guidelines that will maximize the effectiveness of the reset state in an embedded system IC.

IC level reset considerations

Traditionally, the global hardware reset signal brings every storage element on the chip to a low value unles s a high value is needed to avoid a conflict. While this is clean and easy for hardware design, it is not necessarily good. This "all-off" reset state means that, in order to do anything with the IC, the processor must first spend a significant amount of time simply setting up registers to useful values.

System reset code is usually "use once" code, but it takes up code space just like all the rest of the firmware. In other words, this is the most inefficient code in the firmware design. A useless reset state means that not only is considerable time lost at power-up before the IC can actually begin functioning, but a significant amount of code space must be spent on "use once" code.

The ideal reset would allow the chip to begin functioning with only a limited number of register accesses by the firmware. This means the firmware engineer need only change those registers necessary to achieve the operating parameters he desires before beginning operation.

An intelligent reset state allows the pa rt to be operationally tested in the system with only very limited code. IC testing and debugging can be performed in a much more efficient manner if the Reset state is properly planned and utilized. Initial power-up in a lab environment can be much simpler. If, as often seems to happen, the utility used to download the firmware into the system is faulty, a work-around that loads only a limited amount of code may be possible and useful.

As mentioned in What this means is that the reset state, rather than being the first state developed in the hardware, will be one of the last. The IC architect must understand his/her entire specification in order to completely specify the reset state. If the hardware design team is working in parallel with a simulation and verification team, the reset state may come from the verification effort.

All output signals should power up to a benign or inactive state. Note that the high impedance state may be benign if the specification tells the firmware engineer that a pull-up or pull-down is required on the pin.

All target processors should be able to access the chip at power-up. This may require the use of some input pins to hardwire the CPU type information into the chip. Never assume that the CPU can access an internal register to tell t he IC which CPU is controlling the chip!

Interrupts should be masked in reset state. This avoids the possibility of an erroneous interrupt caused by power-up occurring before hardware and software setup is complete. A properly designed interrupt circuit would require only the top level interrupt mask bits be set, because all interrupt source masking was set up for basic operation by the reset logic.

The global hardware reset pin, while considered an interrupt, should not be maskable. Any IC that has the capability to mask the hardware reset pin also has the capability to enter an unrecoverable state. The only way to recover from a chip-level, unrecoverable state is to power-down the system.

General Purpose I/O (GPIO) signals provide the firmware with off-chip access independent of any hardware modules. These can provide the processor with a lot of initial control and information about the system external to the IC. At least one of the GPIO signals should come out of reset configured as an i nput. The system designer can then hard-wire this to a predetermined value to provide added system information to the processor. This will allow the processor to act on this input during the initial setup of the circuit.

Low level reset considerations

Every register in the system should be set to a known state. A "don't care" situation simply means that the hardware designer doesn't care what the initial state of a storage element should be. The IC controller, however, always cares about the state of all storage elements. Any storage element that is not set by the hardware reset signal must be set by the firmware. "Don't care" should never be equated with "unknown." It should simply mean that the hardware designer has more freedom to choose the known reset state.

The hardware always comes up to a high or low value (unless there are metastability issues, which are beyond the scope of this paper). The firmware engineer knows and expects this; the hardware doesn't really come up un known, it comes up to a '0' or a '1'. The firmware engineer will want to know which is correct. Any unset or unspecified register in the reset state will force the use of precious code space and system initialization time to be set by the firmware

Even when performing verification through simulation on an HDL model of the hardware, the software cannot understand an unknown ('x') value, so it will be interpreted as a '1', a '0', or may simply crash the simulation, depending upon the simulation tool used. Unknown states will hurt both the OEM engineer and the in-house verification people responsible for proving the IC before customer prototype shipments occur.

Reset when not at power-up

In addition to the traditional hardware reset signal, the firmware should be given the capability to reset any part, or all parts of the system when needed. There are several levels of firmware-controlled reset capabilities, each of which should be provided at the major functional block level. (The de termination of what constitutes a major functional block can be left up to the hardware designer, but it is often a good idea to consider a major functional block as a block that possesses its own control, configuration, and status registers, and can generate its own interrupts.)

Figure 1 - Reset types, effects and uses

A "Hard" reset capability provides the firmware with the capability to bring a functional block to the same state that existed after the hardware reset signal was asserted. This is the ultimate reset for recovery from unknown or unexpected exceptions. This is one capability that will, hopefully, not be needed in actual operation but which may be invaluable during system development in the lab.

A "Soft" reset halts operation and leaves the functional block ready to restart. A soft reset does not clear CPU-writeable control registers. However, data storage and status registers will be reset. This provides for efficie nt restarts in error handling situations; the firmware can halt the erroneous operation and immediately bring the functional block to a state where it is ready to begin the same operation again.

A "Soft Stop" simply halts operation. Except for "Go" bits, this does not clear any storage elements. The firmware can use this capability to determine the cause of an exception. The firmware can examine the state of the system and determine the next step in the operation. This may mean resorting to a soft or hard block level reset, or it may simply mean modifying some registers to remove the problem or back up the operation for a retry. This capability increases the efficiency of debug efforts during development of the product in the OEM system.

Note that in some form the "Soft Stop" reset state may be entered when the hardware detects an exception condition. In other words, in addition to setting an interrupt to alert the firmware to the exception condition, the hardware may also halt operation, allowi ng the firmware to examine the state of the hardware block at the time of the exception. This is especially useful in cases where the state of the block may change while awaiting a response from the CPU to the exception interrupt.

The firmware should be able to load or reset every register, counter, and state machine in the IC. This capability, along with the soft reset and soft stop capability, provides for efficient exception handling and recovery by the firmware. This also greatly improves the capability of the firmware to provide efficient workarounds to hardware bugs that are not discovered until the hardware prototypes are available. Given that a re-spin of a prototype can take months, this can save a lot of development effort for the OEM engineer.

Note that this access need not be direct - directly mapping every register in the IC can result in unreasonably large memory maps. Registers not needed for normal operation can be designed to allow only qualified access - that is, the IC must be placed into a "test" mode or "debug" mode before the register becomes accessible. This special access mode will map these registers over an existing block of the memory map. This capability should be provided for test, debug, and work-around capabilities. At a minimum, reset capabilities should be provided; certainly write capabilities are preferred. The reset capability should not necessarily be to a 'zero' state but should be to a reasonable start-of-operation state, such as the "power-up" state.

FIFOs, queues, and other data channels should be reset to a flushed or empty state. A "Flush" function resets all counters and pointers to the "power-up" state and pretends that the channel has done nothing and is ready to start from scratch. If the flush function actually destroys the data in the memory blocks of the channel, this should be highlighted in the spec. The "empty" state clears all data in the channel but maintains the control, and maybe the status, as a soft reset or soft stop operation. < P> David Fechser is a 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). A source for this article is the Hardware Design Guidelines of the Fort Collins Product Development department of LSI Logic.