Testing fully assembled new 1130 MRAM board - read retriggering solved!

TESTING FULLY ASSEMBLED BOARD ON TEST BENCH

I put the finished board on the bench and tested it by triggering a read (rising edge of +Storage Read signal) and watching the sense output lines. I wanted to see multiple 1 bits being emitted for a given read, with the output lines pulled down to ground for 80-100ns for all the bit positions that have a 1 value. There should be one pulse for those bit positions and no retriggering causing subsequent pulses every 800 ns after the first one. 

Everything looked good with this testing, so I moved on to the 1130. I frankly didn't do a lot of detailed testing on the testbench because it was cumbersome to move the probes around. For example, I didn't try writes nor changing the address bits to verify that different locations preserved their contents independently. 

TESTING FULLY ASSEMBLED BOARD ON 1130

The PCB was connected to the 1130 system and everything was powered up. I used the rotary mode control to set the machine to Display mode, where each push of the Prog Start button will drive a storage cycle - a read followed by a write. That will raise the +Storage Read line at first which is what will allow me to watch the sense output pulses. 

Having first set the mode switch to Load mode, I loaded memory with various values then turned to Display mode. I want to watch the output pulses on selected bit positions, seeing only a single pulse not spuriously retriggered pulses. I also wanted the value latched into the Storage Buffer Register (SBR) to match what I had stored. 

Instead I saw somewhat random bits showing up in the SBR and the scope pattern for the sense output pulses didn't make sense. I was seeing two 80-100 ns pulses, one shortly after +Storage Read went high and then another at the proper time. I didn't see that occurring on the testbench.

FOUND BAD CONNECTION ON WRITE TIMER CHIP

I realized that in most cases, the same data patterns came out for various addresses as I did Display operations. I was not able to store any different data patterns into RAM, but it was returning deterministically (to at least a superficial level of testing). I then discovered a pin on the write timer chain (first of two timer chips) that was not soldered reliably to the pad. After correction, I could write patterns into RAM. 

ORIGINAL RETRIGGERING ISSUE FIXED

I was not seeing any spurious retriggering beyond the duration of the read portion (1.8 uS) of a storage access, which means that the original bedeviling problem has been mastered. It was kind of a stab in the dark to add in the separate transistors to drive the sense output pulses instead of using the open collector logic gate that produced the pulse. 

I then had a eureka moment when seeing the pulses occurring very soon after the start of the +Storage Read high signal. I noticed that a second pulse at the correct time was happening whenever the board was returning  a 1 bit in that position, while the first pulse seemed unrelated. 

EUREKA MOMENT

Realization rolled over me at that moment. I realized that my sense output pulse, which is a transistor pulling a line down to ground for 80=100 nanoseconds, wasn't connected only to the flipflop that would turn on for the falling edge. There were multiple gates connected together in what IBM calls a wired-OR. That is all the output wires from the various gates are just shorted together - with each of them acting as an open collector driver - so that any of them could activate the flipflop. It was not only a sense output from core memory that turns on the flipflop.

What I was seeing was other gates hooked to the flipflop creating a setting pulse for some other reason. The various gates that produce pulses to set the Storage Buffer Register bit position to 1 are:

• IO bit is gated to B register (SBR) - peripheral  controller drives this
• I (Instruction Address Register) is gated to B 
• A (Accumulator Register) is gated to B
• Core sense output pulses sets B

I don't know what would produce one of those pulses during the T0 clock phase of the read cycle, where I was seeing the pulse on the 1130 side. The gates above should only operate if the machine is trying to store something in a memory location - the IAR, Accumulator or an IO controller word - which should not be happening here.

My next round of testing will focus on what is causing this T0 gating to the SBR. I don't understand why this would happen during a Display mode storage cycle. Either this is a defect somewhere in the 1130 that needs correction or it is a normal behavior that does not cause problems when IBM core memory is used. 

These pulses are pulling the input of the flipflop called the "AC trigger" down to ground, discharging a capacitor that was charged up by the enabling line to the AC trigger. If the capacitor is discharged fast enough and for long enough, the flipflop changes state. It requires about 8ma of current sinking to achieve the setting of the flipflop, times each bit position that has it flipflop set. That is up to 18 flipflops (for a word of all 1 bits).

It appears that something occurring during the discharge was being injected back into the 1130 MRAM board through the supposedly open drain NAND chips. Probably a negative excursion of the line which pulled down the VCC of my board enough to cause the ringing and spurious retriggering. The replacement of the NAND chips with an AND followed by a discrete transistor seemed to resolve this as the transistor could handle the short reverse voltages without any interaction with my VCC and ground planes. 

SOME MANUAL OPERATIONS TESTING THE BOARD

Using the LOAD and DISPLAY modes of the 1130, I was able to put in contents to specific locations and read them back. This is a mode where you take a single storage cycle, pushing the Prog Start button to display or load at the current address. These seemed to be working properly.

I then used the STORAGE LOAD and STORAGE DISPLAY switches on the CE (Customer Engineer) panel to load patterns to all memory locations in a loop or to loop through reading all memory locations. Storing a value of x0000 worked correctly, always returning zeroes. However, when I set the pattern to something else, such as xFFFF, the load appeared to be working but when displaying I got back variable random data and parity errors. 

Since parity is generated on my board based on what is read back from the RAM chip, the only way to see a parity error on the 1130 is if the data being latched into the SBR is not what was read from the chip. This suggests a timing issue or another problem that may be happening during continuous successive storage cycles such as the looping of STORAGE LOAD. 

During my next round of testing, I will examine what is happening during continuous storage cycles and look for defects either in my design, the current board or the 1130.