\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.