In order to test our chip, we wired the chip to an external SRAM module, and then used OMNIlab for stimulus and reading values from various pins. We converted our old IRSIM test vectors and made some slight modifications in order to fully test our chips.
Tests were written to write into and then read out of all possible (16) register locations. This tested the IN and OUT instructions, as well as our basic instruction decode mechanism and the register file. These tests all worked correctly at the maximum possible speed.
Several (4) different test cases were constructed with different endpoints to draw between. These different cases were selected to test the line draw algorithm in all of its different cases with differently sloped lines ( > 1, < 1, > -1, < -1). The draw command did not operate correctly. The fault was traced to a simple miswire in the metal lines that carry the ALU opcode from the controller to the ALU. This is purely a design flaw. This simple fault was not caught at design time due to some difficulty with the simulation software that prevented a full simulation of the bresenheim state sequence. Also, we noticed a small fault in one of our states which could have resulted in an error in one case of the line draw algorithm.
This test consisted of entering 2 points, then translating them to some other location using our translation functions. We found that these methods did not work, and would just move the appropriate coordinate to a bit shifted version of the amount we told it to translate by. For instance, if we translated the point (x,y) up 21, we would end up with (x,42) no matter what the original y was. After close investigation, we noticed the wiring for the ALU opcodes was reversed, so that the ALU was shifting instead of adding. Unfortunately, this functionality was added too late for testing before fabrication, or else this error could have been fixed earlier.
The registers worked at every speed we were able to test.
Aside from one slight design bug, the state machine seemed to work as designed. However, due to the ALU errors, we were not able to test every state.
The ALU itself worked perfectly on all of the tests we performed. It correctly gave the result of whatever operation it was given. However, problems were caused with the routing of the wires going to the ALU, which caused incorrect OP codes to be given to the ALU.
All of the other logic in the chip seemed to work fine. This logic was tested while testing the major functionality of the chip. All results came back as designed.
The basic functions (IN and OUT) operated successfully at an external clock rate of up to 34 MHz. Once divided across our 4-state 2-phase non-overlapping clock, this means that our logic was operating at 8.5 MHz, which compares well with our simulation results. All other testing we performed worked at 17 MHz(4.25 MHz).
The chips all seemed to work correctly with the design errors noted above. Each chip gave the same results for all the test vectors we gave them. Therefore, the yield was 100%.
Obviously, it would have been better if we could have noticed the design errors before fabricating this chip. Although one minor error was just overlooked, the major error, which prevented our drawing function from working correctly, was caused by problems with the simulation software. If this software had worked correctly, the error could have easily been fixed by merely changing the locations of two small wires.
The fabrication of the chips seemed to work very well and all chips work as designed.