Experiments with the world's first microprocessor
and other electronic explorations
In my previous post I mentioned an anomaly I'd noticed in the data bus state during a period I believed it should be floating but stable.
Klaus Scheffler mentioned in his comments that he'd seen the same thing on his board. This got me wondering if I could use the simulator to help me understand this behavior. Sure enough, the sim also shows an indeterminate state on the data bus under similar conditions.
I "discovered" an interesting feature in the i4004 internal data bus management this weekend. Maybe the rest of you already discovered this, but it's new to me.
With the Scrachpad Register board working with my test program, I decided to mate it with the Instruction Pointer board I built in 2012. One of my goals was to see if the CLK1 and CLK2 circuits would ring, or if the rise and fall times are slow enough to avoid problems. To my great relief, I see no significant undershoot or overshoot on these circuits, and no ringing at all. Whew!
However, my logic analyzer showed some suspicious timing on the internal data bus. At first it wasn't clear to me what was happening, so I probed around a bit with my oscilloscope. As I was making notes of my observations I realized what was happening, and this also explained a bit of circuitry in the original chip I didn't previously understand.
My DRAM test found an actual problem on the Scratchpad Register board!
Should I be excited that my test performed its function, or sad that there was a problem with the board?
The test is designed to work in concert with my logic analyzer. A PicoBlaze program implements the March C DRAM test, reading and writing the scratchpad registers repeatedly. If it detects that the data returned from a register isn't the expected value, it pulses an output. This pulse triggers the logic analyzer to log and display the signals it's been recording, which shows me what's been going into and out of the board for the last 25 i4004 instruction cycles. I'd tested this test setup in simulation, using the Verilog Scratchpad board emulation in
place of the actual board, so I had some confidence that the test itself
wasn't broken. But this was the first time I'd connected it to the real board.
What I saw was the error pulse indicating an error for essentially every attempt to read a scratchpad register. Looking more closely, I saw that the signalling going into the Scratchpad board looked correct, but the data being read was always 1111.
In my search for useful algorithms I came across this series of videos by Professor James CM Li of the National Taiwan University:
These are part of a much longer online course (94 videos) on VLSI Testing, but these three address testing RAM. The total run time for all three is only 1 hour 21 minutes. Professor Li speaks English with a pronounced accent, but his pace and careful enunciation make him easy to understand (unlike several videos by others I tried to watch).
I think I caught one small error in his explanation of the answer to one of his "quizes", but otherwise the content seems solid and is explained well.
One of the prerequisites for testing my Scratchpad Register Array board is to get a clear picture of the signalling necessary to make it function outside of the rest of the i4004 CPU's circuitry.
Years ago I split the i4004 CPU into functional chunks, each of which would become a separate PC board. In doing so I tried to keep related circuitry together to minimize the inter-board signalling. Thus the Scratchpad Register board includes many subcircuits:
The inclusion of these subcircuits means the interface to the board is somewhat more complicated than it would be with direct access to the DRAM address and data signals.
To read and write the Scratchpad DRAM array, I need to emulate the execution of one of the i4004's
instructions. The only instruction which allows a single Scratchpad
register to be written is "XCH", which exchanges the contents of the
accumulator and the specified register.
