Tuesday, October 14, 2025

Continued testing 1130 MRAM board - dealing with the signal bounce and retriggering

HAD LARGE TRACES FOR 3.3V, GROUND, PLUS GROUND PLANE

I over-engineered the size of the traces to deliver 3.3V around the board as well as deploying a ground power plane. Decoupling capacitors very close to each chip are also a feature of the design. However, if the regulator can't instantaneously deliver enough power when many gates switch, particularly the 8ma sink required for each of sixteen sense bits and two check bits, then it could cause the sags and anomalies I was observing. I had what I believed was adequate buffering already, but I tried to bump it up.

BUFFER CAPACITOR ADDED

I tacked on a 470uF capacitor across the 3.3V and ground rails to give the board a bigger buffer for energy delivery. The final design would have an SMD version placed neatly on the board, but this is a rework of my current PCB thus I added a through hole part. 

No change when I tested. The +Storage Read signal had a glitch in the middle just when the first read timer ended and the second timer started its pulse. The first timer immediately retriggered. When the word being read had many bits that were one, the retriggering would continue for many more cycles, but when the data word was all zeros I only saw one retrigger. 

BYPASSING THE LOW SIDE MOSFET

The next theory was that my decision to use a MOSFET to isolate the 1130 ground from my board when not powered was introducing a problem. I jumpered around the MOSFET so that the ground was direct, yet the issues remained. The signal was slightly less bouncy but still enough to retrigger. 

ADDED TERMINATION FOR THE SIGNAL

The signal looked relatively clean except for the glitch at the time the second timer was emitting its pulse. With 74HC series chips there is generally no need to do impedance matching, particularly with relatively slow signals as in the IBM 1130. However, the cables that IBM uses with Solid Logic Technology (SLT) machines such as the 1130 are designed with 95 ohm impedance. 

I matched the impedance of the signal to see if that would clean up the signal, but it made no difference. So far I have been trying everything I can think of to stop the bad behavior.  Reading out a word of 0xFFFF will fire off eighteen sense bits (the word plus two check bits) thus sinking about 150ma over 100 nanoseconds. 

WATCHED THE +STORAGE READ SIGNAL AT ITS SOURCE

I put a scope trace on the source gate that generates the +Storage Read signal, before it ran across one backplane and over a cable to a different card compartment and then over cable T3 to my board. The signal looked the same at the source. I find that suspicious. Next time I am in the workshop I will remove the PCB entirely and watch the signal at the source again. If the glitch is coming from the 1130, I would have to address the problem differently than if it is a weakness on my board. 



2 comments:

  1. This may be totally irrelevant, but I can't help but wonder what the oscilloscope traces of + Memory Read and the two timer outputs look like with the direct ground connection. All the ringing on the signals in that image suggest some sort of a common ground issue to me. Also, could it be that + Memory Read is trying to drive a lot more cable than it previously would have? That negative going glitch on the yellow trace has to be real to retrigger the first timer, but all the other ringing on leading edges almost makes me wonder if the scope has a low impedance ground connection to the circuitry...

    ReplyDelete
    Replies
    1. I had the same thoughts - I bridged over the MOSFET to tie ground to the machine at all times. No change.

      I tacked leads onto the VCC and ground pins of the timer chip and watched them with the scope to see if any bounce happened - the traces were absolutely flat.

      The signals to my board come from the source gate over backplane wirewrap, a cable, more backplane wirewrap, then another cable. The cables for SLT have a 95 ohm characteristic impedance. Once experiment I did was to add termination where the signal arrives on my board, but that had no effect.

      I will keep at this until I sort out the cause or at least work out a solid workaround.

      Delete