power_design.tex

\section{Power Design}
\label{sec:power}
The purpose of \bus is to support very low power operation. As such, it is
expected that systems leveraging \bus may need to support power-gating all or
part of the system. In this section, we discuss the requirements to support
power-gated systems, how such systems integrate with \bus, and how
power-oblivious chips can seamlessly interact with hyper power-conscious
chips, promoting interoperability.

\subsection{A Brief Background on Power-Gating}
In the low-power design space, a simple and important concept is the ability
to power-gate, or selectively disable, portions of a system that would
otherwise be idle. By power-gating---removing power from that section of a
chip---, the power consumption of idle silicon goes to zero.

Several challenges with power-gating include: how to preserve state during
idle windows, how to connect power-gated modules to other powered or
power-gated modules, and how to wake and sleep power-gated modules
deterministically. This document does not seek to address all these issues,
%                                              You can get a PhD for that!
rather to demonstrate how \bus can help system designers and the signals that
are ``safe'' to utilize. For a more detailed reference power-gated design with
\bus, consult the {\em \bus~M3~Implementation~Specification}.

In general, sleeping and waking power-gated modules requires a series of
events to occur. In particular, the following signals define common power
control design:

\begin{quote}
\begin{tabular}{r l l c c}
  Signal Name        & Function  & Power-Up & Power-Down \\
  \hline \hline
  {\tt POWER\_ON}    & Controls Power-Gating           & \nth{1} & \nth{2} \\
  {\tt RELEASE\_CLK} & Supply Clock to Internal Logic  & \nth{2} & \nth{2} \\
  {\tt RELEASE\_ISO} & Electrically Isolate Module I/O & \nth{3} & \nth{1} \\
  {\tt RELEASE\_RST} & (De)Assert Reset                & \nth{4} & \nth{2} \\
\end{tabular}
\end{quote}

For the purposes of this document, each \bus node has two modules: (i) The
block that interfaces with the bus itself---we define this as the {\tt Bus
Controller}---, and (ii) the block that comprises the rest of the node---we
define this as the {\tt Layer}. With \bus, a completely power-gated node can
seamlessly awaken its {\tt Bus~Controller} with no special assistance from the
sending node or the mediator node. A {\tt Bus~Controller} can filter addresses,
only waking the {\tt Layer} for a message destined for that node.

Additionally, a power-gated node with a simple always-on low power
interjection generator can exploit \bus features to generate the required
edges with no specialization or externally synchronized knowledge of chip
status. Finally, devices can reliably detect a shutdown message sent on the
bus and use remaining control edges to shut down both the {\tt Layer} and the
{\tt Bus~Controller}.

\subsection{Waking the \texttt{Bus~Controller}}
\label{sec:power-bus-controller-wakeup}
Referring to edges from \cref{fig:arbitration}, edges 1, 2, 3, and~4
provide the required signals. Mapping power edges to \bus protocol edges:

\begin{quote}
\begin{tabular}{r c l}
  Arbitration    & $\rightarrow$ & {\tt POWER\_ON} \\
  Priority Drive & $\rightarrow$ & {\tt RELEASE\_CLK} \\
  Priority Latch & $\rightarrow$ & {\tt RELEASE\_ISO} \\
  Drive Bit 0    & $\rightarrow$ & {\tt RELEASE\_RST} \\
\end{tabular}
\end{quote}

\noindent
In practice, most {\tt Bus~Controller} implementations will not require the
{\tt RELEASE\_CLK} signal as the \bus clock is (by definition) sufficient for
all bus operations, however it is included in considerations for designs that
may require it. A {\tt Bus~Controller} that is awoken using \bus edges will
find its first rising clock edge to be Latch~Bit~0, the MSB of the address,
and should design state machines appropriately.

\subsubsection{Handling an Interjection During Wakeup}
\label{sec:power-bus-controller-wakeup-int}
By specification, interjection is not permitted during arbitration. If an
interjection occurred, an ignorant {\tt Bus~Controller} would hang, unable to
make forward progress as the remaining edges would have been driven from
clocking the control bits, causing the {\tt Bus~Controller} to interpret
either Latch Control Bit~0 or Latch Control Bit~1 as the MSB of the
destination address. After one or two more cycles, the bus would become idle
while the local {\tt Bus~Controller} waits indefinitely for more bits. This
condition would eventually resolve itself if any other node elected to send a
message but could not be resolved by any other means.\footnote{
  Excepting things such as a local timeout and an external reset, but such
  a design is outside the scope of the discussion for a \bus member node.}

As the {\tt Bus~Controller} was previously powered down, powering it down
again before releasing isolation is by definition a null operation. As
isolation is released on the final falling edge of arbitration and an
interjection may only occur while the clock is high, a wake-up that is not
interjected is safe and canceling (re-power-gating) a wake-up that is
interjected is safe.  The challenge is then that the sleep controller module
that generates the power control edges must also be capable of detecting an
interjection. Whether this level of robustness is required is left as an
implementation decision.

\subsection{Waking the Layer}
If the {\tt Bus~Controller}'s address matches the destination address, it must
wake whatever it is attached next up the chain, this means the clockless
{\tt Bus~Controller} module must harvest clock edges from \bus to generate the
power control signals.

One design point explicitly required by \bus is the acknowledgment of
zero-length messages. Depending on application, a node may not require
awakening for a zero-length message. Due to the nature of the \bus
interjection procedure, however, as many as two bits may be received that will
be discarded (\cref{fig:int}). A {\tt Bus~Controller} design that attempts to
minimize wakeups should therefore not begin the wakeup process until latching
the {\em \nth{3}} data bit.

\subsubsection{Handling an Interjection During Wakeup}
As the control bits provide ample edges, designers have more options for
handling an interjection during wakeup. In particular, the same argument
regarding wakeup cancellation and arbitration
from~\ref{sec:power-bus-controller-wakeup-int} applies: if isolation has not
been removed, the node may simply be re-power-gated without issue.

A possibly simpler implementation can unconditionally complete the wakeup
sequence while indicating that a transaction was started, but failed.

Ultimately, the important consideration is to draw attention to the fact that
an interjection {\em may} occur during the {\tt Bus~Controller}'s issuing of
wakeup signals (at any point) and a robust {\tt Bus~Controller} implementation
must consider and handle the cases surrounding interjection during {\tt Layer}
wakeup.

\begin{figure}[t]
  \centering
  \includegraphics[width=\linewidth]{timing/power_on_glitch-crop}
  \caption{\textbf{\bus Wakeup.} \textmd{
      Power-gated nodes repurpose the arbitration edges to wake the bus
      controller before data transmission starts. To self-wake, nodes can
      initiate a null transaction (shown here) by pulling down \DAT and then
      resuming forwarding \DAT before the arbitration edge. If no other node
      arbitrates, the mediator will detect no winner, raise a general error,
      and return the bus to idle.
      Arbitration produces enough edges to wake bus controllers before
      addressing. The null transaction produces enough edges to wake all of
      the \bus hierarchical power domains in a manner that is transparent to
      non-power-aware devices.
  }}
  \label{fig:glitch}
\end{figure}

\subsection{Waking via Induced Glitch}
Section~\ref{sec:spec-spurious}~\nameref{sec:spec-spurious} defines mediator
node behavior in response to a glitch on the data line causing a spurious
wakeup. By deliberately inducing such a glitch, a power-gated member node can
generate enough pulses to wake itself up. \autoref{fig:glitch} shows an
example waveform of an induced glitch, annotated with power control signals.

Details on how the {\tt Bus~Controller} disambiguates between an RX-induced
wakeup and an interrupt requested wakeup and other implementation issues are
outside the scope of this document, but persons developing a power-gated
system are highly encouraged to read the {\em \bus M3 Implementation
Specification} as an example of how to design a power-gated system.

\begin{figure}[t]
  \centering
  \includegraphics[width=\linewidth]{timing/shutdown-crop}
  \caption{\textbf{Shutdown Timing.} \textmd{
    The shutdown command is not confirmed until time~5 when the transmitter
    indicates a valid End~of~Message signal. At time~6, the bus controller
    acknowledges shutdown, asserts the {\tt SHTDWN} signal to the sleep
    controller, and isolates the layer controller. At time~7, the sleep
    controller isolates the bus controller, and isolating the bus controller
    by definition power gates the layer controller. At time~8, the sleep
    controller power gates the bus controller, completing shutdown. At time~9
    the bus is idle, and the sleep controller is waiting for the next wakeup.
  }}
  \label{fig:shutdown}
\end{figure}

\subsection{Sleeping the {\tt Bus Controller}, {\tt Layer}}
\bus edges can also be harvested to return both the {\tt Layer} and the
{\tt Bus~Controller} to sleep mode. \autoref{fig:shutdown} demonstrates how
the control edges following the End~of~Message bit may be used to put both the
node and the {\tt Bus~Controller} to sleep.

\autoref{fig:shutdown} delays the shutdown procedure until the transmitter
asserts End~of~Message, indicating the shutdown message was not in error.
In addition, \autoref{fig:shutdown} has the advantage that a node transmitting
a shutdown request can itself shut down with no further intervention or
knowledge by the mediator node.

\subsection{The Mediator Node, In Brief}
Explicitly not discussed in this document is any indication of how a
power-gated mediator node is implemented. The period $t_{long}$ is permitted to
be arbitrary in length with the express intent of allowing sleeping mediator
nodes to wake themselves using the falling edge of {\tt DIN} as a trigger. The
actual means for waking the mediator node are outside the scope of this
document however.

Sleeping a mediator node is also outside the scope of \bus functionality.
A mediator node must sample its {\tt DIN} line upon returning to Idle (time~9
in \autoref{fig:shutdown}) by the rules laid out
in~\ref{sec:bus-return-idle}~\nameref{sec:bus-return-idle}. If the
{\tt DIN} line is high at that time after an implementation-defined shutdown
message, the mediator node may enter sleep.