The microcomputer revolution began two decades ago, but for most of that time it was required only that the system being designed comply with rather unforgiving requirements of size (on the order of a desktop) and power consumption (several dozens or hundreds of watts). The early personal computers used large numbers of discrete components, but thereafter it became commonplace to use "chip sets" which reduce the computer system to half a dozen integrated circuits each with dozens or hundreds of pins, or preassembled "mother boards", either of which leaves little or no room for optimization by the individual system designer. Thus the individual designer cannot do much in the way of reducing power consumption or changing physical size or form factor.
In more recent years, however, the marketplace has come to demand computer systems, such as personal computer systems, which run independently of AC (mains) power and which are meant to be carried from place to place and used in portable fashion. In such systems there is a renewed attention to issues of power consumption, weight, and size. One consequence of the greater attention to power consumption is the development of communications channels and protocols according to which system elements which provide and consume power are in communication with each other to permit sophisticated power management. It is desirable that the power management communications channel and protocol satisfy several requirements, for example, small pin count (so that batteries need not have too many connector pins) and undemanding protocols (so that devices can be slow if necessary). One approach is to employ a synchronous bus, that is, a bus in which data is passed with reference to a clock line. The clock line is "high" in a quiescent state, and is pulled low if a device on the bus (the "bus master") wishes to pass a bit of data on the line for reading by any or all of the devices on the bus. At a later time, the bus master raises the clock line and again pulls the line low to indicate that a subsequent bit of data is readable by any or all of the devices on the bus. In this way a message composed of many data bits is communicated across the bus.
To accommodate a range of types of bus devices with varying response times and latencies, it is desirable to define a "clock stretching" element of the protocol. According to this aspect of the protocol, any bus device, having noted that the clock line has been pulled low, can itself pull the clock line low. Indeed in the general case it is assumed that any number of bus devices may have done so. During the time that the clock line remains low, the defined behavior of the bus master is to maintain the data level on the data line. In this way, a bus device can take as long as desired to read the data value (and to prepare for the reading of subsequent data values). In colloquial terms, it can be said that the clock line remains low until the slowest of the bus devices has managed to get up to speed and to process data on the data line.
Those skilled in the art will appreciate that power consumption in a microprocessor or microcontroller is monotonically (and generally linearly) related to the clock speed thereof. Thus the system designer who is attempting to maximize battery life (or to minimize power consumption) will consider a variety of measures including switching a microcontroller to a very slow clock speed, or indeed powering down the microcontroller, during times of low or zero workload. (This may be termed "putting the controller to sleep".) For example the designer of a microcontroller for a computer keyboard may actually power down the microcontroller except when a key has been pressed. If the user makes a thousand keystrokes, the microcontroller is powered up and down a thousand times.
Returning now to the above-mentioned synchronous bus with clock stretching, it may happen that the system designer chooses to have a bus device go to sleep, only to be awakened when there is activity on the bus. But a block of data transmitted on the bus may be intended for the very device that is asleep, and yet it is desired that no data be lost. The "clock stretching" aspect of the protocol may be employed to prevent such data loss. The circuitry that accomplishes the "clock stretching" cannot itself be put to sleep, of course, but must be kept functioning at all times in case data is transmitted on the bus. The clock stretching circuit cannot have any clocks running continuously. In at least one known prior art design, it is necessary that the clock stretching circuitry be served by a clock that runs continuously, at a megahertz or so. This leads to non-negligible power consumption.
A further concern is that there be minimal power leakage into any particular bus device while it is asleep.
FIG. 10 shows a typical prior art circuit that permits microcontroller 8051SL to go to sleep if desired and includes a clock stretching function. Four flip-flops ("start det", "clk hold", "busy", and "stop") are required along with several logic gates and comparators. There are many components to be assembled during manufacture and they take up space and consume power.
It would be extremely desirable to provide a "clock stretching" circuit that would permit putting a microcontroller to sleep so as to save power, such a circuit having substantially smaller component count, power consumption, and assembly cost. It would be additionally desirable to provide a level shifting circuit that isolates the bus device from the bus when the bus device is in a power saving mode, has its power removed, or is operating at a power supply voltage lower than that of the bus itself.