Since the last issue, I had an interesting email discussion regarding resets with one of my readers, Jay Dowling. Jay comes from a background of designing safety-critical devices for use in harsh environments and has a different perspective on resets.

During our discussion, Jay brought up a useful distinction between a power-on reset and a hard reset. In my experience, a power-on reset (which happens only at power on) performs the same actions as a hard reset (which can happen at any time.) In both cases, all values in a block get reset to some default value. In Jay’s experience, some things are done only at power on, such as configure an FPGA and dump accumulated charge from a CCD.

One thing that helped me in the discussion was to distinguish between an event that causes a reset to occur vs. an action that performs the reset. In some cases, the terms were being used with different definitions. For example, in my mind, a power on (event) invokes a hard reset (action.) But to Jay, power on and hard reset are two different types of resets (both actions.)

An event is something that occurs to which the system needs to respond, such as the following:

• Power on.
• Power sag or brown out.
• Watchdog.
• Sensor senses a critical condition.
• The user pushes a button.
• Firmware-generated event.

An action is a reset which resets all or part of the system depending on the reset level. My previous article describes three levels of reset.

• Hard reset: reset the whole block to a known state.
• Abort or soft reset: stop operation and reset just portions of the block.
• Halt or soft stop: stop operation but do not change anything in the block.

The system designer maps each event to an action (level of reset.) A power-on event might invoke a hard reset. A condition detected by firmware might invoke an abort.

Individual blocks or subsystems will each need to implement only one to four levels of reset. However, when the system is taken as a whole, each subsystem might be reset at a different level for a given event, leading to several variations of system resets. In a system-wide reset while powered up, FPGAs might not need to be re-configured but a block in an ASIC might need to have a hard reset.

For instance, in the LaserJet printers that I worked on, firmware has to invoke a hard reset on a data compressor block after every compression job. It is the only reset implemented in that block. The hard reset assures that no residual data is left in its buffers when the new compression job is invoked. In a more extensive example, after the LaserJet firmware downloads new firmware and writes it to Flash, it writes to a register that invokes the system-wide power-on reset signal, causing all hardware and firmware subsystems to reboot, as if it had just been powered on.

Thus, the hardware/firmware interface should give firmware access to the various reset levels of each block and should document what each reset level does to the block.

• Best Practice: Provide firmware-accessible hard reset, abort, and halt controls for each block.
• Best Practice: Document how each register responds to a hard reset, abort, and halt.

(Note that the first best practice is an enhancement to one from the previous newsletter. Keep in mind that best practices are “living” guidelines that we should continue to refine to reflect our current notions of “best.”)

Jay also pointed out another distinction in types of resets, asynchronous vs. synchronous. Synchronous resets are synchronized to the system clock and may be controlled by an enable input. Asynchronous resets are necessary in case the clock is hung or if some flip-flops are disabled. Asynchronous resets reset everything at the hard-reset level. Some systems may have synchronous and asynchronous hard resets, or they may simply have an asynchronous hard reset. It is also necessary to give firmware the ability to invoke asynchronous resets as necessary.

• Best Practice: Provide access to firmware to invoke asynchronous resets in addition to the synchronous resets.

Until the next reset…