Finding remaining issues on my MRAM board

ENHANCED MY FPGA CODE AND RETESTED

I added some logic that aborts read and write operations if it discovers that the +Storage Use signal is not active. This protects against possible race hazards that might start my state machine although the 1130 does not intend to access core memory. Just before it sets bits in the Storage Buffer Register (SBR) for a read and before it writes new data into the MRAM chip, I check +Storage Use and skip over those actions. It does this by waiting long enough for the entire 3.6 microsecond storage cycle to be complete. 

I also added a step in the state machine that turns off the tristate buffer. The changes were simulated and then a configuration file was generated to load into the FPGA which I did when I returned to the workshop. 

Most importantly, since I saw some signs of retriggering two read cycles within one 1130 read cycle, I added delay logic to the state machine so that it let enough time expire after finishing the read or write that it was almost at the time when the complementary cycle (write after read or read after write) would start, thus not allowing the state machine to be tricked into a double cycle. 

Storage Load and Storage Display functions were tested again and behave correctly. The 1130 mode switch was set to Load and Display to manually access storage, which also behaved properly as it did before. 

I then loaded the core memory diagnostic program using my Console Loader enhancement to the 1130 and ran it. Previously it failed with a Parity Check consistently at one point in the code. It still fails the same way. This is only happening with certain instruction sequences, otherwise the machine runs reasonably large blocks of code correctly. 

If it were an issue where the data contents, the Storage Buffer Register bits, were changing midcycle then whatever was written to MRAM would always have correct parity generated on its later retrieval in a read cycle. The SBR should not be changed during the portion of the read cycle where I am emitting the pulses to update the SBR. If a read were to complete but is repeated due to changing SAR bits in between when the data bits begin storing in 85 ns clusters and when the computed parity is stored in the last 85ns cluster, it could cause the symptoms.

Furthermore, looking at the three parity stop cases above, I see that in every case, it is the right halfword that does not agree with its parity bit P2 and it is likely that bit 8 is being spuriously stored in those cases. Thus I may have an error in my printed circuit board where there is a short between pins 8 and 9 on the FPGA (CMOD S7) board connector or between pins C1A11 and C1B11 on the T1 connector socket. I will check this in addition to looking more closely at the code being executed when the parity failures were caught. 

It is possible that there is an issue with some timing related to when the 1130 changes the Storage Address Register and when I begin a read or write, such that the contents are a blend of the old and new address. The fact that bit 8 is always on in this parity stops is suggestive that this is closer to the root cause than mistiming and SAR changes, but I will have to investigate all of it.