I made use of the rotary mode switch Load and Display settings to place bit patterns into chosen memory locations. I set the address in the Console Entry Switches (CES), push the Load IAR button to cause the 1130 to use that as a memory address, then set a bit pattern in memory and push Prog Start while in Load mode to put the bit pattern into the location I previously set. Setting the IAR and pushing Prog Start while in Display mode will show what was in that memory spot.
I decided to put the address in the CES, push Load IAR, then push Prog Start so that the content of the memory location is the same as its address. I did this for all 13 bits of an address - 0x0001, 0x0002, 0x0004, 0x0008 etc -so that I could confirm that addressing is working properly. I also set some complex addresses (more than a single 1 bit on) and stored the value there, just for completeness. Everything worked right with this type of testing.
THINKING ABOUT HOW THE ERROR MIGHT ARISE
I am having a hard time imagining an error mode in my board that would create the observed symptoms. Every once in a while (in the Storage Display mode where the 1130 system loops rapidly through all memory addresses) a word will be read having the first three bits as zero in site of having stored it as a word with all bits 1. The 1130 recognizes this by stopping with the Parity Error lamp illuminated.
The 1130 stores two parity bits with each word of 16 bits. One parity bit (P1) covers the first 8 bits of data and the other parity bit (P2) covers the second 8 bits. The machine requires odd parity, meaning that the number of bits that have a 1 value must be an odd number. For example, if a set of 8 bits have the value 00010100 which has an even number of 1 bits, then the associated parity bit is set to 1 so that the collection of nine bits have an odd number of 1 bits. If the set of 8 bits is 00000001 then the parity bit is set to 0 since we already have an odd number.
Because bits 0, 1 and 2 are retrieved as 0 instead of 1 (0x1FFF instead of 0xFFFF) there is now an odd number of bits that are 1 in the first 8 bits of the word. Parity bit P1 should be off for this value but it is read as having a 1 value. That caused a parity error.
My board does not actually store the parity bits in memory. Instead, it generates the value of P1 and P2 from the data bits that came out of memory. Thus, if memory had indeed returned 0x1FFF then my board would have made P1 be a 0. Since the 1130 saw P1 as a 1 value, it means I read the correct value 0xFFFF but what made it into the 1130 Storage Buffer Register (SBR) as 0x1FFF and 1 for both bits P1 and P2.
This means what is failing is the process of setting the SBR to what was retrieved. In the 1130 system, IBM designed it so that the core memory will produce a pulse which pulls a signal line down to 0 if the core memory bit had a 1 value stored, but does nothing if the value in the core memory bit was a 0. Those Sense Bit x lines have a pull up resistor in the 1130 that keeps them up at 3V (logic 1) and the core memory logic acts like an open collector gate, pulling it down to ground level (logic 0) for a short interval to indicate that the memory bit was a 1 value.
The SBR register is cleared to zero before the read and then any of the Sense Bit x lines that have a negative going pulse will turn on the flipflop for that bit position in the SBR. My board uses transistors to pull the Sense Bit x line down to ground when I am attempting to set a 1 value into the SBR bit position.
The circuitry inside the SBR that deals with the Sense Bit x signal has charged up a capacitor which is discharged through the negative going pulse from the core memory - the discharge current causes the IBM flipflop to turn on. It takes about 8ma of current flow to cause enough current in the IBM circuitry to turn on the flipflop.
Previous versions of my board would fail if too many bits had a 1 value - too many of the Sense Bit x lines were sinking 8ma at the same time. Some kind of analog issue that I never did track down. My new design tries to handle this by skewing the pulses on the Sense Bit x lines over multiple FPGA clock cycles (a clock cycle is 83.33 nanoseconds).
The current implementation sets three bits at a time in an FPGA clock cycle, so that the SBR is set across six clock cycles to turn on all 18 possible 1 bits. I do this in sequence, with the first cycle covering bits 0, 1 and 2, the second cycle covering 3, 4 and 5, and the last cycle covering bits 15, P1 and P2. My hardware on the board allows me to cover each of the 18 Sense Bit x signals independently, but I decided to group them into sets of three in order to minimize the time it takes to set all the bits.
Seeing that the failure was always that bits 0, 1 and 2 did not set, indicates that the problem is likely in my board since that is what happens in one clock cycle of the state machine in the FPGA. All the subsequent cycles work properly, so that all the other bits are turned on in the SBR.
I can't think of a way that the state machine, which should invariably advance sequentially through the cycles, would skip over one of the states much always fail by skipping the same state. That means I have to assume that it is emitting the control lines for bits 0, 1 and 2 as it should.
The chip that triggers the Sense Bit x pulse (when the control line is asserted and the memory bit returned is a 1) handles four bits at a time, 0, 1 2 and 3, so that can't be the common cause.
This feels like a timing issue, where something is marginal in the timing I have set up so that the first cycle of Sense Bit x pulses are failing. This could be timing relative to the 1130 logic circuits or timing relative to the MRAM chip or tristate buffer chips on my board.
This could be because the SBR is still in the process of being reset because I am too early, or it could be because that the data bus on the MRAM memory chip has not emitted the values yet but it completes driving those bits before the last cycle where the P1 and P2 bits are set. In fact, those two are not stored in the SBR like the 16 data bits, instead it sets two flipflops in the parity checking logic but is completely analogous to the SBR setting process.
The MRAM data bus is bidirectional. When the notG control line is asserted low, the chip will drive the current word's values on the bus. My tristate buffer chips should be set to high impedance so that they don't interfere with the data driven from the MRAM. When writing into MRAM, the tristate buffer chips
are set to drive values onto the MRAM data bus, while the notG control line is left high or unasserted.
I can image three cases that might cause problems for a short period - having the tristate buffer driving data at the same time as the notG is asserted, or if the MRAM has not yet fully activated the data bus after notG is asserted low, or if the process of reading the contents of a location in MRAM has not yet completed so that the data bus values are not yet settled.
I switch on the notE control in one state machine cycle and assert notG control line in the next cycle. The issue with the first three bits is occurring in the cycle right after I have asserted notG. Per the timing chart above, the read is complete during the first cycle (35 ns into the 83.33 ns cycle), and the outputs should be on the data bus a mere 15ns into the second 83.33 ns cycle. The data should be present almost 70 nanoseconds before the cycle begins that emits the Sense Bit 0, 1 and 2 pulses.
The only thing that could result in the data not being present for the cycle that emits the first three sense bits is if the data address from the 1130 system were to be changing somewhere between the cycles that assert notG and emit the first three bits, which would trigger another 35 ns memory access as below:
The 1130 system should hold the address lines from the Storage Address Buffer (SAR) steady before it asserts the +Storage Read signal that starts my FPGA state machine. It takes three cycles for that signal to make it through a serialization chain of flipflops that protect against metastability problems, then another two cycle before we start the one that might be sensitive to changing SAR values. This should not happen unless it is a hardware defect in the 1130.
The time from disabling the tristate buffer until it reaches high impedance state is less than 15 ns. This control signal was changed a couple of FPGA cycles before the read activity takes place, thus this shouldn't be a timing factor either.
RECODING FPGA FOR OTHER REASONS SO NEED TO OBSERVE AGAIN
I will be recoding the FPGA to improve some behaviors so I will need to retest to see if the anomalies went away or continued or changed. One thing I changed was to use a clock generator module in order to improve the FPGA cycle time down to 5ns allowing much finer grained timing.
With this newly coded FPGA logic, I could use the Storage Load and Storage Display CE switches to cause the machine to loop repeatedly through memory storing the pattern on the Console Entry Switches (CES) or displaying the content of memory. It now correctly reads back a word with all bits 1 (0xFFFF) which is a great improvement. In fact, it stored the pattern I set on the CES and read it back in all cases I tried.
I then turned off those CE switches and used the machine's rotary mode switch in the Load and Display modes. Pushing Prog Start while in Load mode will take one memory cycle and write the contents of the CES into the next word location in memory. Pushing Prog Start while in Display mode just reads back the word but doesn't change it. While in Load mode, pushing the Load IAR button will set the next word address to what is in the CES, thus I can arbitrarily pick memory locations for reading and writing.
In this mode, I had mixed results. I could use Load to set values in locations but in Display mode, sometimes the word still had many bits set to 1 that had been the previous contents of the address. In other words, since I had looped setting all addresses to 0xFFFF previously, if I tried to load a different pattern into the location from the CES, I might find my bits merged with some of the prior bits.
This looks to be a timing issue with the write part of the memory cycle. That is, when the CES value is gated into the Storage Buffer Register (SBR) it should have first been cleared to zeroes before the CES bits are merged in via an OR. It appears that I may be writing too early in the 1.6 uS portion of the memory cycle, before the clear of the SBR has completed.
To attempt to correct this, I again modified the FPGA code to delay when I started processing the write until about 525 ns into the cycle and perform the write over 65 nanoseconds. This still completes well within the write cycle but doesn't try to store the SBR into my MRAM chip until partway through clock cycle T5.
If this isn't enough, I could advance even further into the write half of the memory cycle. This is the big advantage of using an FPGA for my board, where I can tweak the timing without having to change any hardware at all nor the printed circuit board itself.
No comments:
Post a Comment