\section{The Slave Hardware of the Interface Board}
   
   The SFSM and PFSM described earlier are used to control the interface
board when it acts as a DVMA master on the SBus.  In order to function
effectively in the CAM-8 input-output system, however, the board must also be able to 
act as an SBus slave.  In
slave mode, the pointer to the next Display List item may be computed by the host
and written to the interface board.  Thus the Wait-for-Host condition can
be satisfied.  When an error acknowledgment occurs, the host needs to be able
to read from the interface board the address of the instruction which caused
the error.  This also requires the board to function as an SBus slave. 
 
     The slave operation of the interface board is completely independent of
its master operation.  Slave response is required once the board is correctly
selected as a slave by the SBus Controller.  This can occur when the
board is no longer an SBus master but is internally processing a transfer to
or from CAM-8.  To prevent any conflicts that may arise due to simultaneous
slave and master processing, the slave controller and datapaths are
designed to be relatively independent of the master hardware.
This
section describes the hardware and finite state machine controller
needed to allow the interface board to function as an SBus slave.

\subsection{The Slave Datapath Hardware}

     The datapath hardware for the slave system is shown in Figure~\ref{svsys}.  An address
decoder selects a Slave Register Bank location for host access based on the SBus physical address
lines {\sf PA(27:0)}.  The SVLD and SVDR signals generated by the slave FSM are used to 
activate the correct register load and drive signals in the register
bank.

\begin{figure*}
\psfig{figure=svsys.ps,width=6in}
\caption{Datapaths for the interface board slave hardware.}
\label{svsys}
\end{figure*}

    The host
needs to write only to the single 32-bit Host Next Pointer register in the
Slave Register Bank.
  This register stores the virtual address of the
Display List instruction to be executed when the next Wait-for-Host condition
is encountered during normal Display List execution.  The loading of the
Host Next Pointer register sets the HOSTFLG, which is the
Wait-for-Host condition flag.  The register may be driven during
slave operation; or by the master when the HOSTFLG is set, there is a
Wait-for-Host condition, and the Next Display List address is being driven
on the bus.\footnote{Under these conditions the DRHNP line becomes active.}  In the latter case, the Control Register at location 011 is
inhibited from driving the SBus. 

 The Slave Register address location zero
is reserved for the hardwired board ID provided by Sun.  Subsequent address
locations may also be used for other required tokens of an SBus slave.
The Slave Register Bank also contains two Status registers, which are loaded by
the board as a master through the activation of the LDPTR signal whenever the 
Next Display List address is driven on the SBus.  Status register \#2 is loaded
from Status Register \#1, and Status Register \#1 is loaded from the SBus at that
time.
 There is no conflict between master and
slave operation in this case since the board is explicitly an SBus master 
in possession of the bus when it drives the Next Display List address.  Thus
it cannot be a slave unless the driven address is in the interface board slave
space.
The Status Registers
keep track of the present Display List instruction that is being executed as
well as the previous instruction.
Their contents may be driven on the SBus when the host attempts
to resolve an error condition.

   The Slave Register Bank contains one other register --- the interrupt polling register.
This register is set by the Interrupt Hardware whenever the board activates
an SBus interrupt.\footnote{The SPOLREG signal sets the polling register.}
It is read by the host when the latter is attempting to determine the source
of the interrupt.  As explained in the section describing the Interrupt 
Hardware, the reading of the polling register resets the interrupt line.

\subsection{The Slave FSM Controller}

     The three state finite state machine shown in Figure~\ref{svfsm}
 is used to control 
the slave operation of the interface board.  Upon reset, the slave FSM enters the SVIDLE state.  When the board is selected as an SBus slave, the ON signal
is activated, and there is a transition to the SV1 state.  Figure~\ref{svlog}
shows that ON is generated if the {\sf Size(2:0)} lines indicate a word transfer
and there is a
high to low transition in the logic OR of {\sf AS*} and
{\sf Sel*}.
 
\begin{figure*}
\psfig{figure=svfsm.ps}
\caption{The Slave FSM of the interface board.}
\label{svfsm}
\end{figure*}

 

     In SV1 the {\sf Ack(2)*} line is asserted to indicate a word acknowledgment.  If the CPU is writing to the
board (/RD), SVLD is asserted to load the data into the selected
register.  There is an unconditional transition from SV1 to the SV2 state. 

\begin{figure*}
\psfig{figure=svlog.ps}
\caption{Generation of the ON input for the Slave FSM.}
\label{svlog}
\end{figure*}


     In state SV2, the {\sf Ack(2)*} line is driven high as required by the
SBus protocol.  Since the interface board as a slave issues only
idle and word acknowledgments, only the {\sf Ack(2)*} line needs to be
driven by the board.  Error acknowledgments are not issued.  In the case of
an error due to invalid transfer size, ON does not become asserted and there is
a bus timeout.  In state SV2, SVDR is asserted if the slave is being read by
the CPU.  There is always a jump back to the IDLE state from SV2.

     The finite state machine of Figure~\ref{svfsm} is implemented in
the following manner.  The SVIDLE, SV1 and SV2 states are assigned 
the state bits 00,
01 and 11  respectively.  This leads to the
following equations for the control signals:
\begin{quote}
  S0      := (/S1*S0 + /S1*ON)*/RST

  S1      := /S1*S0*/RST

  ACKDR    = S0

  ACK(2)*  = S1

  SVDR     = RD*S1

  SVLD     = /RD*S0*/S1
\end{quote}
A hardware implementation based on these equations will be programmed into
an Altera MAX5032 chip to realize the Slave FSM of the interface board.









