Unexpected results

I've been doing a lot of work with the 4004 schematics (a topic for another post) and am getting eager to begin layout of the first of the five PCBs that will make up my 4004 re-creation.

As I've worked with the schematics I've recognized some common sub-circuits. One is the inverting push-pull driver, like the example on the left. Here, the input is fed directly to the low-side driver, and through an inverter to the high-side driver. This circuit provides a very fast rise time compared to the resistive pull-up, especially when driving a large number of gates. This circuit is able to drive a large number of gates, with a rise-time that mirrors that of the high-side driver's gate. One of the negatives I'd noted was the output doesn't drive to the upper rail, due to the turn-on threshold  voltage [Vgs(th)] of the upper driver.

I've noted that the FDV301N has a lower turn-on threshold than the BSS83, which got me wondering whether I could use them for all three transistors, rather than using a BSS83 for the high-side driver as my rule-of-thumb would indicate. I still don't trust the simulation results yet, so I breadboarded the circuit. Testing shows the FDV301N works better than the BSS83 as the high-side driver, and I made the change in 58 places in the schematic.

I can't use it in all cases, though. The example on the right looks, at first glance, like a reasonable place to make a change, but it's not. This is a tri-state output: when the two middle transistors are "on" both driver transistors should be off, presenting a high-impedance at the output. But the source-to-gate protection diode in the FDV301N would pull the output to ground, which would be bad. Once I recognized this, I made a second pass through the schematic to make sure I hadn't changed any like this.

Flush with this success, I began to wonder about the DRAM circuit. Of the three transistors in each cell, the write-enable FET clearly operates as a transmission gate and a BSS83 must be used for that. The storage element has its source grounded, meeting my rule-of-thumb for replacement with an FDV301N. But how about the read-enable FET? I've already tested stacking FDV301Ns to form a NAND gate with good results, and that doesn't look much different.

Here's that DRAM cell circuit again on the left. Notice the two stacked FETs in the middle. Looks like a NAND gate to me.

I came oh-so-close to changing all 112 of these in the schematic, but in the end I decided to spend a couple of hours in the lab re-testing the DRAM test circuit on the breadboard first. And I'm glad I did. Because it doesn't work.

It took me a long time staring at various scope traces to figure it out, and I'm still not sure I understand what's going on. The symptom is that it will hold the state where the input is high (and the output low) all day long, but it will not hold an input-low state.

What I see is the precharge FET drives the output line high just fine, and the output stays high while the read-enable line is high, but as the read-enable line goes low so does the output line. Since the storage element is turned off this should NOT happen, but it does. I looked for transients that might be turning on the storage element but found none, and wiring its gate hard to ground doesn't change the results. Tests with a DMN26D0UT as the read-enable FET show similar effects though not as bad. The DMN26 has an output capacitance of 2.9pF rather than the 6pF of the FDV301N, so perhaps it's the discharge of the output capacitance that's drawing the charge off the output line, but I tried putting a 56pF capacitor between the output line and ground and that had very little effect. A 330pF capacitor moderates the effect enough that the circuit works, but clearly there's something pulling the output line to ground pretty strongly. I'm wondering if there isn't a path through the drain-source channel and then through the protection diode to ground while the FET is changing state?

Later this week I'll try to duplicate this test in simulation. I'm just really glad that I didn't assume it'd work.