For the speed testing of our chip, we chose to use the test sequence with one latent instruction followed by two dependent instructions and then an independent.  This was a logical choice because we know that off-chip memory access time is the limiting factor in our chip’s performance and this test reorders memory, so it is easy to see when memory is not being reordered correctly, even if ARSE is giving the right outputs.

Due to the unavailability of an operational 70ns Dallas Semiconductor SRAM, we chose instead to use their 120ns part (special thanks to Legolab). This limited our predicted maximum frequency for our chip using dual, non-overlapping clocks to 2.08MHZ. Testing of ARSE showed that it runs perfectly at 1.7MHz, but that at 4.25 MHz (the next available step in OmniLab), memory glitching as shown to the right causes the wrong instructions to be fed in to the chip and no reordering takes place.

From this we conclude that the maximum operating frequency for ARSE with this memory chip is right around the predicted value of 2.08MHz.

We also decided to test ARSE using dual, 50 percent duty cycle clocks, just to see if this would increase the maximum frequency at all.  Our predicted highest frequency in this case was 4.17 MHz.  ARSE ran smoothly at 680 Khz. However, at 1.7 MHz we saw mixed results. Sometimes the test would run fine but sometimes there would be memory glitching and no reordering would take place.

Since our chip was not designed to operate with 50 percent duty cycle clocks, we were not overly surprised to see that the running speed was not as high as our maximum prediction.  However, the fact that it worked sometimes but not others suggests unreliability in the off-chip memory.  Were it that we had better SRAM parts, we would probably have found a higher operating frequency for this test.