The Scratchpad DRAM tests found a problem!

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.

At this point, let's review the operation of a DRAM cell:

To write a DRAM cell:

1. The "Data In" line is driven to the desired state (high or low).
2. The "Row Write" line is asserted. This allows the signal on the "Data In" line to charge or discharge the storage capacitor to the desired state.
   
3. The "Row Write line is de-asserted. This captures the desired state in the cell.
   

To read the DRAM cell:

1. The "Data Out" line is precharged to a high state, then left floating.
   
2. The "Row Read" line is asserted. If the storage capacitor is charged, the "Data Out" line will be pulled low. Conversely, if the storage capacitor is discharged, the "Data Out" line will remain charged.
3. The sense amplifier (not shown) inverts the state of the "Data Out" line.
   

Reading a one from every DRAM cell sounded like a problem in the decoding logic, rather than a failure of an individual cell, row, or column. I fired up my oscilloscope and probed a few key circuits, but everything seemed to be operating properly. One of these I looked at closely was the circuit that activates the column sense ("Data Out") precharge transistors. If this wasn't working the column sense lines would never get charged, and since the column sense amplifiers invert their inputs, all the data would be read as ones.

The precharge circuit seemed to be pulsing at the appropriate times, but when I probed a column sense line I saw that it didn't charge to the level I expected. Then, when the precharge transistor turned off, the column sense line exhibited an RC discharge curve. This was the same for all the column sense lines I checked. This got me looking at my board design.

One of my concerns had been that the intrinsic and stray capacitances that this type of circuit depends on would be too small. For example, the FDV301N transistor I'd chosen as the storage element in the DRAM cells has an input capacitance of only 9.5 pF. Thus I'd made provisions for an 0603 sized capacitor in parallel with each storage element to allow me to add capacitance if it was needed, even though I didn't plan to install these (and haven't).

Another place that charges get stored are the column sense lines. Thus, I'd made provision for the addition of capacitors there as well. When I looked at the board, I found I'd installed 4.7K resistors to ground on all the column sense lines. Oops. That accounted for the RC discharge curves and the constant one outputs.

I disconnected the Scratchpad Register board from the test jig and took it to my soldering bench. The hot air tool made quick work of removing the erroneous resistors. Plugging the board back into my test jig I restarted the test. It's been running the entire time I've been writing this blog entry (over an hour) with nary an error detected.