Honing the FPGA logic for the 1130 MRAM board and testing results

FINE TUNING THE STATE MACHINE

There are points where I examine the external signals coming from the IBM 1130 in order to start the read or write portion of a memory cycle, as well as whether to bail out if I find that the +Storage Use signal is not asserted. 

These signals are passed through four clocked flipflops in order to handle the possibility of metastable states since the 1130 could change the signal right at the same time as the clock edge of the FPGA since they are not in a synchronized clock domain together. I had been simply examining the output of the last flipflop for the +Storage Read, +Storage Write and +Storage Use signals but if the signals are glitchy, looking at a single 5 nanosecond point in time might give me a false positive. 

To protect against this, I added four more clocked flipflops to each signal chain and then verify that the last four are all set to 1 in order to treat the signal as an actual positive. If there is a temporary glitch to 0, we just wait another few cycles until all four flipflops are filled with 1 in order to proceed. Similarly, the +Storage Use chain must have the last four flipflops at 0 in order to act as if storage use is not requested for this memory cycle. 

The state machine, once started in a read or write portion of a cycle, will finish its activity and then wait until the 1.8 microsecond cycle portion is almost complete before it begins to look for the 1130 signal to proceed into the other half of the memory cycle. If I find that storage use is not requested, even if the state machine began the read cycle, it will wait long enough to have passed almost fully through the entire 3.6 microsecond memory cycle before it starts looking for +Storage Read again. 

When I look at the logic diagrams for the IA cycle, it shows that the Storage Buffer Register (SBR) is cleared for the entire duration of clock step T0 - from 0 to about 450 ns - and then released so that the sense pulses from my board can set the relevant bits. My previous logic was emitting the set pulses prior to 450 ns so that had to be changed.

I also see that the logic will take the results from the SBR and move them to the ACC register during clock step T2 which occurs from about 900 to about 1350 nanoseconds. Thus my results from the sense pulses must be transferred before 1350 ns. The spec for the sense pulses from the IBM core memory is for them to occur as early as 700 ns and as late as 950 ns which puts my real upper bound at 950 ns. 

I adjusted the timing of the FPGA state machine to fit with those constraints. 

RESULT OF TESTING SHOWED THE SAME PARITY STOP ERRORS

The core memory diagnostic fails at the exact same spot every time. It is in a routine that fills memory with a given pattern and at an address that begins with 0x000011111xxxxxxx and not when it first executes the code. It makes it more than 1500 loops before it encounters the error. 

It fails consistently at certain address values while in full speed RUN mode. However, if I step the 1130 with single instructions it does NOT fail. It is a timing issue that is marginal enough that it is dependent on specific values to run into trouble. In most cases the data shows up exactly as expected in the SBR, even when I view the display panel 

The code is storing the pattern into memory words using a STO I ADDRS instruction, a store of the ACC register into the address that is contained in the memory location ADDRS. It first fetches the value in ADDRS, then performs another memory cycle for indirect addressing (IA cycle) which will set up the Storage Address Register with the new location into which the value in the ACC register will be placed during the next memory cycle E1 (execute cycle 1). 

It does allow me to speculate about how the parity stop is being triggered, however I need to set up the scope to try to trap the situation and trace it back to be certain. 

Parity stop occurs when the exclusive OR of the eight data bits in a halfword plus the parity bit associated with that halfword result in an even count of 1 bits, at the start of the T6 or X6 clock step. T6 is in the middle of the write portion of the memory cycle, whereas I believe the fault that causes the stop is happening earlier. 

Since the parity bits are generated by the contents of the MRAM memory but the bits in the SBR are injected by the sense pulses from my board, if the high order bits are somehow not getting set into the SBR due to the timing issue, but the parity is generated based on the retrieved bits, then we could trigger the parity stop. 

What I don't understand is why the high bits of the SBR are almost always stored correctly, and even in the case that failed it has executed the IA step for the instruction more than 1500 times successfully before. Why is the timing not only marginal but failing specifically at this one time predictably.