%%-----------------Chapter 4---------------------------
\chapter{System Development and Testing} \label{chap:Testing}

The design methodology for this thesis involved breaking the system down into small subsystems which could easily be debugged and verified. The primary simulation and debugging tool used for this thesis was \matlabReg version 7. Initially, the design for each of the subcomponents was written using \matlabReg scripts which were then subsequently simulated to verify the desired operation. Once the particular algorithm was well understood, it was implemented in the FPGA using an iterative approach. After the component was developed in Verilog and programmed into the FPGA, the \alteraReg \signaltapReg software was used to record the system variables over a defined peropd of time (number of samples). Then, the recorded real-world signals were exported from \signaltapReg into the \matlabReg workspace. This method allows the developer to examine the recorded variables off-line to try and determine what or where any problems might lie in the design. Furthermore, since the initial design was created in \matlabRegNS, the real-world variables can be compared to the simulated values to help the debugging process.

The author would absolutely recommend the use of \matlabReg for design, simulation, and debugging, coupled with \signaltapRegNS. By first simulating the design, the developer gains a more in-depth understanding of what they are trying to implement in hardware, which cuts down on the number of iterations required to achieve the desired goal. When dealing with FPGA designs, the time required for the software package to synthesize the hardware and generate a programmable bit file is orders of magnitude greater than the time required to compile a design in a software based environment. Thus, by using \matlabRegNS, a demodulator design simulation might take a couple of seconds to run, whereas when implementing the actual hardware on the FPGA, the equivalent design might take one half hour to build. Having already developed the initial design in \matlabRegNS, and therefore gained familiarity with it, the developer will now likely take far fewer compiles of the hardware to achieve the desired results than if they had not first simulated in \matlabRegNS. Since each hardware compile might take thirty minutes, for instance, a few less compiles constitutes a significant reduction in development time. Moreover, once a \matlabReg simulation exists, it acts as an excellent debugging tool for comparing the real-world results with the ideal case.

Aside from \matlabReg and \signaltapRegNS, no other tools were used for debugging. Although the \alteraReg simulator tool is very useful for off-line, static types of verification, it was not suitable for dealing with the majority of the baseband processing design since the real-world signals are difficult to generate and the output difficult to verify within the simulator. That said, the \alteraReg simulator tool was useful for verification and debugging of some components such as the PN generators which do not require external inputs.

\section{Component Testing and Integration}

Before integrating any components into the system, they were first tested independently, starting with the FPGA board. Initially, a simple design was programmed into the FPGA to test some of the various switches and LEDS and verify that the device could be programmed correctly using the JTAG programming cable and the \alteraReg \quartusReg II development software. The next step was to test the ADCs and DACs on the board. This was accomplished by generating a test signal in the FPGA, outputting it via the DAC, and then feeding the output back into the ADC. The resulting signal was then examined using the \signaltapReg software tool as well as an oscilloscope by outputting the sampled data via the second DAC. Both ADC and DAC channels were verified using this process. The use of both the oscilloscope and the \signaltapReg software package demonstrated that these tools were in fact operating as expected. After the onboard ADCs were verified, the external Analog Devices ADCs were added to the design. Again, the ADCs were tested using a DAC to ADC loopback setup. The results were verified using the oscilloscope and \signaltapRegNS.

The next step in the design process was to lock the FPGA internal circuitry to an external frequency standard. As such, the external 10~MHz frequency standard from the Aeroflex signal generator had to be passed into the FPGA external clock input connector. To achieve this task, a PCB board with a TI TLV3501 high-speed comparator chip was designed. This circuit performs level translation on the incoming clock signal, from the signal generator, in order to generate a 0-3.3~V square wave to input to the FPGA. This circuit was debugged and verified using an oscilloscope with the input impedance set to 50~$\Omega$ to match that of the FPGA clock input connector. Once the circuit was found to be operating as required, it was connected to the FPGA board clock input. Then, within the FPGA, a PLL was added to lock onto the external clock signal and generate a sample rate clock signal equal to eight times the input clock rate. The resulting 80~MHz was the used to drive the DAC to ADC loopback circuit, and the output was once again verified using both an oscilloscope and \signaltapRegNS.

After the main ADC and DAC components were tested and integrated and frequency locked to the external 10 MHz frequency standard, that portion of the design was set aside temporarily. The next step in development was to generate the signals for transmission. This was accomplished by first developing the LRS circuit within the FPGA as a standalone design unit. This unit was then tested using the \alteraReg simulator tool, which is part of the \quartusReg software package, in order to verify that the output of the generator was in fact the correct PN sequence for the generating polynomial being used. Once the LRS circuit was debugged in software, it was then ready to be used to generate real world signals. The output of the eight LRS generators were connected to a GPIO pin, and the resulting digital waveform was observed and subsequently verified using an oscilloscope. To transmit the signals, the PN sequence outputs of the FPGA GPIO pins must be modulated onto the carrier via the Hittite modulator boards. Due to the difference in signal levels between the FPGA GPIO output pins and the expected input to the Hittite modulator board, a custom PCB board was required for this task. The board was first designed on paper, and then subsequently simulated using \pspiceRegNS. The board was then implemented, and tested using a signal generator to simulate the FPGA output along with an oscilloscope to observe the resulting input which would appear at the Hittite modulator input. The circuit board was found to provide the correct levels for the Hittite board, along with sufficient current to drive 300 feet of the coaxial cable used by the system. The signal conditioning PCB also accepted four clock inputs which it buffered in order to improve the current source/sink capabilities of the FPGA outputs. These pins are used for the sample rate clock outputs from the FPGA board to the Analog Devices ADC boards, and are not passed through the voltage translation network that the PN sequences destined for the Hittite modulator board do.

At this point, the development and testing returned to the DAC to ADC design. The signal conditioning board was mounted onto the FPGA board using an available GPIO header. The DAC to ADC design, which was previously verified, was then modified to output the sample rate clock to the external ADC boards via the signal conditioning board. The resulting test data was recorded and analyzed in \signaltapReg and observed on the oscilloscope. This verified that the clock buffer portion of the signal conditioning circuit was meeting the design requirements. The next step was to shift back to the signal generation side, and determine whether or not the signal conditioning circuit was functioning correctly for the PN sequences from the FPGA. At this point, the testing process became more difficult due to the high carrier frequency. That is, the output of the Hittite modulator board was at 2.4 GHz, and there was no equipment available in the lab which is capable of observing a signal at this frequency. Therefore, the output of the modulator board was fed into the AOR radio, tuned to the carrier frequency, and the resulting IF output was observed. To facilitate the debugging process, the sequences transmitted from the FPGA were changed to square waves of known frequency. Then, using the AOR SDU5600 spectrum display unit, the IF output of the radio could be seen, along with frequency components representative of the harmonics of the square wave.

At this point, the IF output of the radio was passed into one of the external ADC boards and recorded using \signaltapRegNS. The recorded IF signal from the radio was imported into \matlabReg and demodulated offline using a \matlabReg script designed to recover the original signal. Based on the output of this test, it was found that the demodulated inphase and quadrature signals were only 45 degrees apart rather than 90 apart. Due to the fact that the radio operation was outside of our control, the Hittite modulator board was suspected of causing the problem. After some time spent examining the literature, and conversing with Hittite technical support, it was determined that the board was not correctly set up. To fix the problem, an additional PCB board was developed which provides the common mode voltage along with input capacitors described in \autoref{chap:Implementation}. The finished board was powered using a power supply, and output was verified using an oscilloscope. Using the newly developed PCB board, driving the negative terminals of the Hittite modulator board, the test was repeated and the resulting sampled IF data was processed in \matlabRegNS. From the data collected, it was found that the PCB board driving the negative terminals of the Hittite board had solved the problem, and that the inphase and quadrature signals were now 90 degress apart as expected. This test verified the operation of both the Hittite modulator board, and the AOR radios.

Now that the system was able to generate, transmit, and receive signals, the next stage in development was to process the received IF signal. The development of the demodulation hardware was performed in stages, as described in \autoref{chap:Implementation}. First, an NCO was implemented in the FPGA which generated a sine and cosine wave with frequency equal to the IF output of the radio. Then new design was tested independently using \signaltapReg and the recorded sinusoids were observed in \matlabRegNS. Based on the FFT of the collected sinusoid data, it was clear that the signals were situated exactly at 10.7~MHz as desired. The NCO was then added to the overall system design, and an pair of multipliers were added to mix the incoming IF data with the sine and the cosine wave from the NCO. The output of the mixing operations was recorded using \signaltapReg and analyzed using \matlabRegNS. The analysis found that the mixed signals were in fact situated at baseband and 21.4~MHz as predicted. The remaining task was to filter the double frequency component from the signal. To meet this need, a filter was designed using the \quartusReg software, and added to the design after the mixers. Once again, the output was recorded using \signaltapReg and analyzed using \matlabRegNS. The final analysis found that the double frequency component had indeed been removed and that the desired signal was situated at baseband. From this point onward, the analysis of the demodulated data was performed in \matlabRegNS.

\section{Interfacing \texorpdfstring{\signaltapRegX}{SignalTap\textregistered} and \texorpdfstring{\matlabRegX}{MATLAB\textregistered}}

Unfortunately, at the present time, there does not exist a clean method through which data recorded using \alteraRegPL \signaltapReg hardware-in-the-loop tool can be exported into \matlabRegNS. As a workaround to the problem, a set of steps was used in order to transfer the recorded data from \signaltapReg into the \matlabReg workspace. The first step is to record the data in \signaltapRegNS, and export it as a comma separated value (.csv) file. Then, the .csv file should be opened using \microsoftReg Excel, and the lines of header information from the top of the file must be deleted, and the file saved as an Excel spreadsheet .xls file. In \matlabRegNS, the data can be imported from the .xls file using the 'xlsread' command. Once the data has been loaded into \matlabRegNS, it now exists as one large table variable where each column corresponds to a single bit of data. As such, the imported data must be broken down into the individual variables which it contains. This operation was performed using a script which acts as an import file. By examining the sequence and size of the variables recorded in \signaltapRegNS, or by examining the header portion of the .csv file, the column number for each bit of each variable can be determined. Using simple matrix manipulation commands, the group of bits which constitute each variable can be extracted from the imported data and converted from binary into signed and/or unsigned decimal using a converter function which was developed. The sequence of \matlabReg commands required, along with the converter functions and a sample import file are provided in \autoref{appendix:SimCode}. Note that \matlabReg has a built in 'csvread' function for reading in .csv files, but it does not appear to be compatible with the .csv files created by \signaltapRegNS.

\section{Implementation Issues}

This section very briefly mentions several issues which were encountered during development of the baseband system which could be of help to future developers using the testbed.

Firstly, it was discovered early on that the use of unsigned binary numbers leads to large DC components in the data. This is due to the inherent nature of the number system, and thus signed binary numbers which are naturally entered about zero are much better suited for working with signals within the FPGA -- e.g. an 8-bit signed binary value ranges from -128 to 127, whereas an unsigned 8-bit binary value ranges from 0 to 255. The second issue, relates to the FPGA hardware itself. \alteraReg recommends that all unused pins be configured as tri-stated inputs~\cite{s2GettingStarted}. However, the \quartusReg~II design software defaults to grounded outputs, which the author found to cause erratic programming behaviour. When programming the device, it often took three or four attempts before the programming file would be successfully written to the FPGA. This issue was resolved by ensuring that the unused pins in each new design were set to inputs tri-stated. Another issue encountered was related to the maximum clock speed for the \alteraReg multiplier megacore function. Although the author was unable to find a maximum frequency in the megacore documentation, it was discovered that if the clock speed is increased to more than 80 MHz, there is a substantial increase in noise at the output, which corresponds to a decrease in SNR. It is not clear whether this issue was due to an incorrect design implementation, either on my part or within the megacore itself, or an actual hardware limitation; \quartusReg offered no warnings or errors to this effect. This issue was resolved by setting the multiplier clock rate to 80~MHz. The final issue occurs when creating a design with multiple processing stages. When implementing DSP designs in FPGAs, there is a strong tendency for the number of bits representing the data to rapidly, and potentially unnecessarily, increase. In order to reduce the required processing in the FPGA, it is important to try and minimize the number of unnecessary bits which are carried through the design. It can be tedious to determine which bits are relevant, and which are not. In any case, \matlabReg was found to be a good tool for determining the range of the signal of interest and thus determining which bits can be eliminated.
