|
|
The equipment used to test this chip was OmniLab equipment. It included a
stimulus, which produced the inputs for the chip, and a logic analyzer.
The chip was wired into these two units on a breadboard. The results of
the tests are inputed to the OmniLab equipment through the analyzer and
viewed on screen.
Six different test vectors were used to test this chip, one for each
function. Results of these tests follow, with certain areas highlighted
for discussion. All five of our chips were fully functional and the test
results were identical to the IRSIM results obtained last semester.
Notice at the yellow line the values of IN and OUT. At the yellow line, a
write occurs (WE goes low and then high while OE and RW are high). At
this time, IN=128 and OUT=127. This is an 8 bit inversion (10000000 =>
01111111). The memory then increments (AD0 goes from 0 to 1) to operate on
the next pixel.
Notice the area highlighted in the blue box. This area shows the vertical
flipping. The chip has read in a pixel value from address 00000001, which
is the first row, second pixel. When the write occurs (described above),
it writes to address 11110001, which is the last row, second pixel.
Again, notice the area highlighted in the blue box. This area displays the
horizontal flipping. The chip reads in a value from address 00000000; the
first pixel of the first row. It then writes the pixel value to 00001111,
which is the last pixel in the first row.
In this picture, there are a number of things to notice. The blue box
highlights the pixels that are being compared. OE goes high 5 times, which
occurs as the chip reads in five pixels. The chip is trying to create a
new value for the first pixel. To do this, it reads in a value from the
first row, second pixel (address = 00000001), last row, first pixel
(11110000), first row, last pixel (00001111), and second row, first pixel
(00010000). It then reads in the current pixel (00000000), finds the
minimum of the five, and writes the value (which occurs at the yellow line).
This picture is very similar to the previous one (smoothing by minimum).
It checks five pixels (highlighted in the blue box) and sets the current
pixel value to the maximum of these five values. The same five pixels are
operated on in this picture, just like above.
This picture shows how similar that smoothing by average is to minimum or
maximum. Highlighted in blue are the accesses to memory for the five
pixels that it averages. It takes in four pixels (the four surrounding
ones) and averages them. Then it uses that average and averages it with
the center pixel. The red box shows how the address changes as the chip
pulls different pixels from memory.
The pictures that correspond to the above functional tests were all done
with four bit, non-overlapping clocks. The maximum sampling rate of the
OmniLab hardware was 34 MHz. That would make the frequency that these
tests ran at was 8.5 MHz. To check a higher frequency, the chip was tested
with two bit, overlapping clocks. Using these clocks, a fequency of 17 MHz
could be reached. The picture directly above corresponds to this test
(using the invert function). The blue block highlights errors on the
output pins. These errors come from the inability of the ALU to operate at
17 MHz. It was the longest path, and therefore, the limiting factor of
this design.
Highest frequency with correct functionality = 8.5 MHz
Predicted maximum operating frequency = 10 MHz
To improve this design, more space on the chip would be needed. The
limiting factor of the design (the ALU), could only be improved if it were
made into a carry look-ahead ALU, which require a lot more space (or more
metal layers). It also would have been nice to put the memory on chip,
instead of relying on external memory. Again, this was a space decision.
Finally, there are a number of other functions that could be realized on
this chip. For example, image thresholding, which was originally in the
plans for this chip. Finally, had this chip not worked properly, debugging
would have been difficult, as none of the state bits were mapped to I/O
pads, which would have made it very difficult to debug the main PLA
controller.
|
