Hardware Testing
1. Testing Setup
We performed two sets of testing on our chip:
OMNILAB
Noise Cancellator Prototype
The first tests using OMNILAB were intended to determine whether or not our chip was working as we had designed it last semester using the same set of test vectors to test the chip functionality. We converted our IRSIM test vectors from last semester into the OMNILAB test vector format using the convert utility. This utility performs the conversion and generates mappings for the stimulus and analysis pins. The stimulus port pins are connected to the input pins on the chip and provide the testing inputs. the rate at which the stimulus output occurs can be set in the control panel in the OMNILAB program. The analysis port pins are connected to read in all data that you wish to view in the OMNILAB program.
The second tests required wiring up a prototype circuit for our chip that could take some sound input signals and output the filtered signal so that we could actually listen to it. For this circuit, we connected the left and right stereo output channels from a tape player to A/D converters and then to the corresponding input pins of our chip. The output was then sent through a D/A converter and then to a set of speakers to listen to the final result. On one channel a noise signal was input and the other channel some music with that same noise was input to the circuit for our test.
2. Test Vectors
We used a set of four test vector inputs that test the chip for four iterations on varying inputs for X and the desired signal. Since our chip is adaptive, each test depends on the previous test because the Weight values are updated and a new X input value is loaded on each iteration. The inputs we used were the same test case that we used last semester in IRSIM to validate the functionality of the chip. In addition to viewing the final signal output, we also are able to view some intermediate signals through our debugging pins.
We wanted to run for a larger number of iterations than four in order to test the chip for a larger period of time, but we found that we were only able to debug a maximum of 5 iterations because OMNILAB has a 4096 bit buffer per stimulation, and our chip requires 175 clock cycles x 4 (2-phase clock), so 4096 / 700 = approximately 5. We were informed by Cavallaro later that two of the OMNILAB test equipment stations have a 16K bit buffer, but we did not get the chance to try running with those.
3. Functionality
The four parts that we actually tested without destroying are fully functional. They gave us the expected outputs in OMNILAB for the tests that we ran last semester in IRSIM. Unfortunately we connected the fifth chip upside down and destroyed the input pins for some of the signals and as a result this chip does not work, and we are not able to determine if the chip was fully functional without fabrication defects before our mishap.
4. Comparison of IRSIM and OmniLab Results
We first verified that our chip is traversing through the states of our state machine correctly. Below the OMNILAB result for the state machines bits (DBG3 - DBG0) and the IRSIM state machine bits (StBit3 - StBit0) are shown. As can be seen, both phases of the state machine states (error calculation and weight update) are the same.
In running through our test sequence of 4 inputs, we first make note that the DBG outputs are inverted from the output of our chip as compared to the IRSIM DBG outputs, becuase we didn't use an inverter to show the same output when we gathered these results. As mentioned earlier, our chip is an adaptive filter so the weights are updated in their stack after each iteration and a new X input is also loaded its stack.
Our chip gave the proper outputs for the final filtered output as well as the intermediate debug outputs (4 bits from the input of the multiplier, 4 bits from the output of the multiplier, and 4 bits from the input to the adder). Here are the links to each input case and the results from OMNILAB and from IRSIM for the first phase (ERROR CALCULATION) and the second phase (WEIGHT UPDATE)
6. Speed Test
We ran the same test vector inputs as the aforementioned tests in order to determine the maximum speed at which the chip functions. Using the non-overlapping clocking scheme, our chip still functions correctly (goes through all the correct states and obtains the intermediate and final outputs we expect) at the maximum rate possible with OMNILAB, 8.5 MHz (34MHz sampling rate).
7. Noise Cancellator Prototype Circuit
Last semester when we tested our chip using IRSIM, we wrote a C program that automated running of IRSIM and generated the inputs and checked the outputs from IRSIM for correctness. This allowed us to run longer simulations in testing our design. This semester, we changed this C program to convert the inputs into the necessary OMNILAB format, but as mentioned in Section 2 (Test Vectors) we found a limitation in the number of inputs we could run at once. Thu, we tried an alternative which was to use an EXTERNAL clock for our chip, while using OMNILAB to provide the stimulus inputs and to analyze the outputs. In this manner, we are able to read in only the final error output using less buffer space and as a result able to go through more iterations at once. The problem we found with this, however, is that it is very difficult to match the outputs that we see in OMNILAB with the corresponding input stimuli because our chip is running at a different frequency. This made verifying the chip correctness using this experimental setup almost impossible.
Finally, we decided to put together an independent system consisting of our chip, A/D and D/A converters, a two-phase clock generation circuit, a stereo tape player, and a set of speakers. In testing this circuit we used a number of different sound input signals. One of the inputs we used was some music with some random noise introduced on one channel, and just that same noise on the second channel. So the Desired Input was the Music + NOISE and the X Input was the NOISE.
In this experiment, we initially found bad results in that our chip did not seem to be reducing the noise significantly, although it was passing the music signal through without destroying it. After checking the entire circuit for errors, we found that we have a compatibility error with the D/A converter in our circuit. First of all, the voltage ranges that the D/A converter was expecting were different than what we were outputting, so we fixed that. This still did not completely solve the problem, however, and what we find at the output of the D/A converter is that it is always a SQUARE WAVE. In our chip, we generate a READY signal which is just a short pulse that we use to inform the D/A converter that our output is ready. We suspect that this READY signal connected to the 'WR' pin of the D/A converter is not triggering the D/A converter to write correctly. In addition, another problem area in our circuit is the function generator that we use to create our clock. The signal from the function generator appears to be introducing some noise into our final output, actually overwhelming the chip's output after it converges.
Our conclusions are two-fold.
The READY signal in our circuit may not be correct for our purposes and if we had time we would look into changing it and re-fabricating. Also, another concern is we may not be using the D/A converter correctly because it is quite complicated and has a lot of different functions that it provides. Yet another option is to look into getting a different D/A converter that expects exactly the type of signal we are currently generating for READY.
The function generator seems to be introducing massive noise into the system, as we mentioned, and thus if we had time we could use an alternate source of equipment for generating a clock that does not introduce noise into our system, such as using a PC and I/O board for testing and controlling the entire system.
8. MOSIS Report