
\section{Description}
The job of the processor kit is to alter and rearrange the frequency domain
signals passed to it by the conversion kit, before passing on the
result to the video kit and back to the conversion kit.  When the kits
are started up the RESET button is pressed to tell the kit to wait for
the conversion kit to begin passing the first set of time domain data.
At the same time RESET is pressed, the mode of operation specified by
the three Settings switches is entered, though this will have no
effect until this kit begins to output its processed data.  When
FFTSENDING goes high, the processor kit begins to accept data from the
conversion kit and to store it into RAM locations starting at 0 and
going to 2047.  The kit will only exit recieving mode if FFTSENDING
goes low, and if more than 2048 pieces of data are sent the last RAM
location will be overwritten as many times as it takes.  Once
FFTSENDING goes low, the kit goes to its data sending phase.

During the sending phase the processor kit sends out each of the 2048
new pieces of data, altered according to the mode of the kit.  The
values of each data piece are calculated immediatly before they are sent,
but because each piece is independant of the others and because the
time constraints are relativly low compared to the clock speed, this
doesn't represent a problem.  Before each piece of data is sent out,
the RAM is accessed either once or twice and the data loaded into the
Arithmetic component.  There it is manipulated, before being output on
the DataBus shared with the the RAM as the ACKPROC is set high.

A diagram of the processor kit is presented in
Figure~\ref{processordiagram} The five main components of the kit, as
well as the various datalines, are shown.  The dotted line represents
the boundary of the FPGA, with everything inside being implemented in
VHDL, and everything outside being in hardware.

%**page for kit wiring diagram

\begin{landscape}
\begin{figure}
\Huge{KIT WIRING DIAGRAM GOES HERE}
\caption{Processing Module Wiring Diagram}
\label{processordiagram}
\end{figure}
\end{landscape}

\begin{landscape}
\begin{figure}
\Huge{MODES DIAGRAM GOES HERE}
\caption{Modes Diagram}
\label{modesdiagram}
\end{figure}
\end{landscape}
%**page for modes diagram

\subsection{Arithmetic}
The Arithmetic section is where the inputs from the RAM are
manipulated and output.  Its operation is controlled by the inputs
Add, Go, and Stop, as well as its connection with the multiplier.
Each time Add goes high, Arithmetic takes a value from the DataBus, on
which the RAM ought to be outputting.  When Go goes high, the value
stored in RAM is output onto the DataBus for the other kits.  Finally,
when Stop goes high the current value is erased.

There are three modes of operation.  In the first, the
input Sharpen is low, and Add only pulses once before Go and then Stop
are activated.  In this case Arithmetic simply graps the value being
output by the RAM and returns it to the DataBus without altering it.
If Add is pulsed twice, Arithmetic will first grab the value on the
DataBus, then use Mult to multiply it by the Scale before adding it to
the second value it gets from the DataBus, before outputing this sum.
If the result is larger than the 8-bit output, it is simply rounded
down to 11111111.  In the first of the two following timing diagram
Arithemtic activates first in the first mode, inputting 40 and
outputting 40.  Second it activates in the other mode, inputting 20,
multiplying that by the Scale (01000000 or $\frac{1}{2}$), inputting and adding
40, and returning 50.

If Sharpen is high, then Arithmetic simply takes the most recent
value, checks to see if its magnitude in two's complement is greater
than the scale, and if it is returns the value.  If it is less than
then scale, a magnitude of zero is returned.  In the second of the two
following timing diagrams, you can see two positive and two negative
numbers checked against the scale.

\begin{landscape}
\begin{figure}
\Huge{TIMING DIAGRAM DIAGRAM GOES HERE}
\caption{Arithmetic Timing Diagram}
\end{figure}
\end{landscape}

\begin{landscape}
\begin{figure}
\Huge{KIT WIRING DIAGRAM GOES HERE}
\caption{Arithmetic Timing Diagram}
\end{figure}
\end{landscape}


%**A timing diagram
%**A second timing diagram

\subsection{Control}
The job of the control seciton of the kit is to translate the input
Settings into numeric values that can be used to actually control the
rest of the kit in such a way that the right result occurs.  The
AFactor and the BFactor are what the addresses of a given output are
multiplied by in order to find the RAM addresses that the inputs will
be taken from.  For instance, if the kit is in the harmonic mode, the
address of the first value to be given to Arithmetic will be
multiplied by the BFactor, 01010110, and the address of the second
value fed to Arithmetic will be multiplied by the AFactor, 10000000.
The scale factor is also determined here, and in this case it would be
10000000.  If only one number is to be used by Arithmetic, then
BFactor is left as 00000000.

\subsection{MassiveFSM}
This is the most complicated part of the processor kit.  This FSM has
three functions: it synchronizes with the other kits on the parallel
interface, it controls the activation and addressing of the RAM, and
it controls the actions of the Arithmetic module.  In naming the
modes, those that begin with an R are entered when the FSM is
recieving data, and those that begin with an S are entered when the
FSM is sending data.

When the FSM starts up or RESET is high, the FSM goes into the
RWaiting state.  Here the count is initialized and it waits until
FFTSENDING goes high so it can enter the RListen stage.  In RListen
the address is made the same as the count, and the FSM waits for
ACKCON to go high so it can go to RPull and load the value on the
DataBus.  Alternativly, if FFTSENDING goes to 0 when the FSM is in
this state, it assumes that the transmission of data has stopped, and
goes to SWaiting.

In RPull Pull dips low, causing the RAM to load the value on the
DataBus into its current memory address.  After RPull the FSM goes to
RAck where it sets ACKPROC high to signal that it has recieved the
data.  Now hopefully ACKCON will go down, in which case the FSM will
enter the state RIncrementing where it will incriment the count by 1
before returning to RListen.

When the conversion kit finishes and FFTSENDING goes low, the FSM
switches to SWaiting.  Here, as in all states starting with S,
PROCSENDING is set high to let the other kits know that the process
kit is sending processed data.  After doublechecking that FFTSENDING
is 0 and reinitializing the count the FSM shifts to SStarting.  From
here the kit will go on to SBAddressing if there is a BFactor, and
otherwise skip to SAAddressing if BFactor is 0.

In SBAddressing the count is multiplied by the BFactor, then in
SBSettling this value is loaded into the address of the RAM.  In order
to keep parity between the imaginary and real components of the
signal, the lowest order bit of the address is just taken straight
from the count.  In SBSettling the FSM pauses for a short while, and
lets RAMOut low to tell the RAM to output the value in the address
onto the DataBus.  When the time is up, the FSM Switches to SBAdding,
where Add is set high for a cycle, before the FSM goes on to
SAAddressing.

The SA cycle is just like the SB cycle, but after it ends the FSM goes
to SSetuping, where Go is set high to tell Arithmetic to start
outputting onto the DataBus.  Next, SBroadcasting sets ACKPROC to 1 to
tell the other kits that there is valid data on the DataBus, and
waits for them to acknowledge.  When they do, it goes to SIncrementing
where the count in incremented and the FSM decides whether it has sent
enough data to say that it has finished sending and ought to go to
RWaiting, or whether it has more to go and should go back to
SStarting.

\begin{landscape}
\begin{figure}
\Huge{FSM DIAGRAM GOES HERE}
\caption{FSM Diagram}
\end{figure}
\end{landscape}
%**Diagram of the FSM

The following are three timing diagrams of the FSM in action.  The
first one takes place while the processor kit is receiving data, and
it responds to ACKCON, telling the RAM to load data and incrementing
the address.  In the second diagram the FSM is in sending mode.  In
this case BFactor is 00000000, so it only pulses Add once for each
cycle, and increasing the address one by one.  In the third diagram
the BFactor is 11111111, twice as high as the AFactor.  In this
diagram, the way the FSM uses a different address for each Add pulse is
clearly visible.

\begin{landscape}
\begin{figure}
\Huge{FSM TIMING DIAGRAM GOES HERE}
\caption{FSM Timing Diagram}
\end{figure}
\end{landscape}

\begin{landscape}
\begin{figure}
\Huge{FSM TIMING DIAGRAM GOES HERE}
\caption{FSM Diagram}
\end{figure}
\end{landscape}

\begin{landscape}
\begin{figure}
\Huge{FSM TIMING DIAGRAM GOES HERE}
\caption{FSM Timing Diagram}
\end{figure}
\end{landscape}

%**Timing Diagram
%**Timing Diagram
%**Timing Diagram

\section{Testing and Debugging}
Certainly the largest problem with debugging the process kit was
discovering that only a small fraction of the kits NuBus worked.
Because some of the NuBus pins were stuck high, some stuck low, and
some indeterminate, it was difficult to isolate which were working and
which were not.  Originally this kit was to have a knob which could be
used to specify the exact degree of frequency shift or strength of the
harmonic or such.  Due to a tightly limited number of pins, though,
this and a few other features had to be cut out of the design.

The fact that the state transitions were time-insensitive meant that I
could hook up ACKCON and ACKVID to a switch and manually simulate the
other kits.  This greatly aided debugging, and allowed me to verify
the correct opperation of my kit without needing to interface with the
other kits.  Since it could transition from sending to receiving
by setting FFTSENDING to 0 and from recieving to sending by hitting
RESET, any state can be easily reached.

The other problem during debugging was a glitch that caused the FSM to
switch states inappropriatly during a small percentage of a certain
type of state transition.  Eventually it turned out that by going into
a state where the next state was governed by an if statement, and then
suffering from a transient which brought it through the wrong state on
its way to the right state, it could sometimes get stuck in the wrong
state.  Fixing this problem turned out to be a case of rearranging the
state listing so that the states were associated with different
numbers and the problematic transitions wouldn't occur.  Unfortunatly,
the most recent rearrangement has caused another problem, making the
count reset to 0 in roughly one out of every 200
transitions.  Since this problem does not seem to occur when the kits
are connected as opposed to the states being transitioned manually, it
might be that this is an interaction between the switches and the
nubus, which has RESET on it.  A transitory triggering of RESET by
shaking in the NuBus would be enough to account for the problem.

Though kit communication remains elusive, I have verified that values
can be stored into sequential addresses in the RAM and retrieved; and
that the correspondance between input and output can be altered by
using the Settings switches.






 
