Testing... testing?

In a comment on my last post, Klaus Scheffler asked: 

How do you plan to test the register board? I first populated only all the DRAM cells without column and row selection logic, connected an Arduino to all column and row lines, and tested the DRAM bit by bit.

That's an excellent question.

When I started this project a decade ago, I recognized that just building it and hoping it worked would be a bad idea. This is why I spent a month or so experimenting with the pieces I expected to have the most trouble with, using individual BSS83 transistors mounted on Surfboard Model 33143 SMT prototyping adapters, a Microchip PIC16LF876 microprocessor, and a solderless breadboard. Only once I was reasonably sure the system would work did I consider building an entire CPU.

Once I did decide to build it, the CAD tools I had available forced me to partition it into multiple boards. I also recognized it was quite probable that something wouldn't work initially, and if I had to respin a board I didn't want it to be a single, large, and expensive board.

But how would I test the boards individually?

This project started out as a means to experiment with FPGAs, and I owned a Spartan-3E reference board. When I started laying out the Instruction Pointer board, I designed it so that it could plug into an expansion board that mated with my S3E reference board. All the inter-board circuits pass through stacking connectors, and the FPGA has access to all these required for the IP and SP boards. This way, the logic not implemented in hardware could be emulated by the FPGA.

So, how am I going to test the Scratchpad Register board?  I've come up with several possibilities:

Option 1: Just try it and see if it works

This is pretty much what I did with the Instruction Pointer board. I also hooked my logic analyzer to the inter-board circuits and recorded a snapshot. I could do the same, triggering the logic analyzer on one of the six Scratchpad control lines changes state, and a 4004 assembly program exercising the registers.

The downside of this is that it's not a rigorous test by any means, and it might be hard to capture intermittent failures.

Option 2: Bit-bang with a PicoBlaze soft microprocessor

This is roughly equivalent to what Klaus did, only using a PicoBlaze in the FPGA instead of an Arduino. The difference is that I can't directly drive the row and column select lines directly, as there is decode logic in the way. Instead, I'd have to emulate the internal workings of the i4004 CPU when it accesses the Scratchpad registers.

To speed things up I'd probably implement the i4004 instruction cycle in FPGA logic, leaving the PicoBlaze to control the data and the type of access to the Scratchpad.

Option 3: Create a microprogrammed testing scaffold

One of my current interests is in how microprogrammed CPUs operate. Rather than using a PicoBlaze, I thought it might be interesting to implement a microprogrammed test scaffold to exercise the Scratchpad Register board.

This would run the fastest, but would also involve the most coding. Probably not worth the effort, though.

Option 4: Parallel execution and comparison

Since I have the entire i4004 CPU implemented in the FPGA, one attractive option is to run the hardware and the FPGA implementations in parallel with a 4004 assembly program exercising the Scratchpad registers. Writes to the Scratchpad would go to both implementations, while reads would compare the data returned from the hardware with that returned by the FPGA.. The results should be identical, and any differences would indicate a failure in one or the other.

This technique has the added benefit of being extensible to test other boards singly or together without having to implement something completely custom for each test configuration.

I haven't decided what I'm going to do yet. Option 2 sounds like fun, as I haven't experimented with the PicoBlaze yet, but it may not get beyond a high-level design phase. In the end I'll probably go for Option 4.