Chasing down 1130 MRAM memory issues

PARITY ERROR INVESTIGATION HINTS AT 'REGRESSION' CAUSE AS WELL

I whipped up a short program to enter into the 1130 that will fill memory from location 0010 to the end of storage with values that match the address of each word. Then I can see if there is any sort of addressing defect because the value displayed at a location should be identical to its address. 

Using the Storage Display switch I had the machine loop reading memory. I did spot one design weakness that I quickly corrected but continue to see parity stops at very repeatable locations. First, I will discuss the weakness and how I corrected it.

RACE HAZARD IN PARITY GENERATION LOGIC WHEN SETTING PARITY BITS

A chain of exclusive OR gates produce the proper parity bit value so that each halfword has an odd number of 1 bits. The logic to turn on the parity bits in the 1130 uses sense pulses, just like the pulses that turn on the 1 bits in the Storage Buffer Register (SBR) for any bit of the word that is a 1. I was updating SBR bit 15 at the same time as I was setting the P1 and P2 parity bits, which lead to some wobbling of signals in the 1130 logic before it steadied out. 

Because the 1130 exclusive OR chain was changing because of bit 15 being set at the same time as I was latching in P1 and P2, the logic in the 1130 was susceptible to sometimes considering parity for a halfword to be even (an error) although when the halfword plus its parity bit is considered, the result would be odd. I simply separated the setting of SBR bit 15 from the subsequent setting of P1 and P2 to eliminate this timing sensitivity.

What I noticed was that the parity stops always had a word where bits 12, 13 and 14 should have been one bits, but were read as zero. Look at the recorded stops below. The second row of lights is the Storage Address Buffer (SAR) which is the address from which we read the word, and the third row is the SBR showing the memory contents. 

I realized that the supposed memory regression I reported in the last blog post was just another case of the missing bits 12, 13 and 14. That is, it would appear that the loop reverted back to a value that had its last four bits of 0001 when it should have been 1111 when the logic was incrementing the address in the diagnostic program. 

LOOKING FOR SOMETHING COMMON THAT MIGHT CAUSE THIS SYMPTOM

This is always a word fetched from an address where the SAR has bits 8, 12, 13 and 14 set to a 1 bit value. Other bits may be set to 1 as well, but these are common to every captured parity stop. The word being read into the SBR drops only bits 12, 13 and 14. Because an odd number of bits are missing compared to what was coming out of the MRAM chip, the parity bit is incorrect which the 1130 detects and flags as a parity error. 

Bits 12, 13 and 14 must be coming out of memory correctly and flowing through my exclusive OR chain to produce the proper P2 parity bit, which is why P2 is correct for the case where those bits are set to 1. However, I can tell they are not getting into the SBR since the bits are still 0 after the read cycle ends. 

My FPGA logic in the 1130 MRAM board sets bits 12, 13 and 14 in the same state machine step, although it emits separate signals on discrete traces thus this can't be a solder issue. The step that handles these bits is no different than the other steps that handle bits 0-2, 3-5, 6-8, 9-11, 15, or the two parity bits. Nothing should cause the FPGA to sporadically malfunction only on this step and only for a location and data pattern that as bits 8, 12, 13 and 14 set to 1. 

A single logic gate passes pulses from bits 12, 13, 14 and 15 to the 1130 when the discrete signals for each bit are activated by my FPGA. A bad chip should fail to drive all four, not just bits 12, 13 and 14. Further, this only fails when bit 8 is also on (or addressing memory where the SAR has bit 8, 12, 13 and 14 turned on). The chip in question has no connection to bit 8, which is handled by another chip. 

In the 1130, bits 8, 12, 13 and 14 of the SAR and SBR are implemented across multiple Solid Logic Technology cards thus unlikely to have an issue common to the SAR or SBR that might produce these results. 

Yellow circles around parts generating bits 12, 13 and 14

The parts on the PCB don't have common elements that could explain how they would fail, as you can see in the graphic above. More significantly, the logic supporting bit 8 is on the left side of the PCB away from all of these parts. Similarly as seen in the graphic below, the SAR bits for 8, 12, 13 and 14 are separated around the memory chip.

I just don't see anything on the board that would account for issues arising only when bits 8, 12, 13 and 14 are turned on in SAR and the memory word but bits 12, 13 and 14 are not set in the SBR. It is time to go back to the oscilloscope, watching the pulses for SBR bits 12, 13 and 14 while monitoring and triggering on parity stop. Perhaps I can see something suspicious on the signal lines that could explain the results.