Still working on write errors in the Virtual 2315 Cartridge Facility

RESTRUCTURED WRITE TEST PLAN SLIGHTLY

In the previous tests, I read in cylinder 0, head 0, sector 0, modified just a few words manually, and then wrote it back to C0 H0 S0. That left the remaining data from the original 2315 cartridge image intact, but it was not optimal for my testing. 

My new plan uses my core memory loading tool on the IBM 1130 to load the buffer with a known pattern, then I just do the write to cylinder 0, head 0 and sector 1. A second use of the memory loading tool will zero out the buffer location before I do a read of C0 H0 S1 to see what comes back. 

As usual, I will be capturing the signals with the logic analyzer while the write takes place. I will store that as an Excel file and analyze it with my Python programs. Lastly, I will unload the mini cartridge at the end of the test, move the microSD card to the offline tool, mount it on my PC and look at C0 H0 S1 with the Showsector.exe Python program I wrote. 

MY TESTING EXAMINED THREE THEORIES FOR ISSUES DURING PRIOR WRITES

I changed the logic to eliminate any chance that the cartridge ready condition is being glitched by errors over the SPI link between the Raspberry Pi PICO and the FPGA inside the main unit of the Virtual 2315 Cartridge Facility (V2315CF). It appeared that the write state machine erroneously reset to idle a few times in the midst of handling the writing of a sector from the IBM 1130 to the virtual 2315 disk cartridge. 

Another theory was that the power to the main V2315CF unit was having issues triggering incorrect behavior. The final theory is that the clock signal as it is received by the IBM 1130 electronics is ringing or malformed, inducing sporadic errors in the IBM disk controller logic rather than in my logic. 

5V POWER SUPPLY EXAMINATION

I set up the scope to trigger on the 5V input go the main unit just in case it wasn't able to support the instantaneous demands of the V2315CF. I could also monitor two internal voltage levels in the V2315CF produced by voltage regulators for 3.3V and 1.2V used with components such as the PICO and the FPGA. The 5V is used for terminator and driver circuits producing signals across the ribbon cables to the IBM 1130 and the internal disk drive, while the other voltage rails depend on 5V for their inputs. 

Watching the 5V input from the power supply module into the V2315CF main board showed me significant ringing on the line. It was a periodic ring, occurring roughly every 30 microseconds. That corresponds to a frequency of 33.3 KHz and is likely the result of the DC to DC converter saving power by turning its higher frequence switching action on and off because the load from the V2315CF main unit is not high enough for the module to run continuously. 

It is a module rated for 10A output at 5V and thus just loafing along in this role. The terminator resistors for the RK-05 disk drive application are 178 ohms from the signal line up to 5V and 383 ohms from the signal line down to ground, hooked to about 55 signal lines from the main unit. 

If all signals are outputs and set to high, the resistor pairs would draw about 100ma in total. If all signals were outputs and all were pulled to low, the draw would be 1.5A. If it were all inputs and they are all pulled low by the source, it could demand the same 1.5A from the supply. The actual requirement is going to be somewhere in the middle and dynamic, varying as signals are wiggled by the source and the main unit. 

The DC to DC converter on the power supply was chosen to support up to three of the RK-05 emulators at a time, The load from the electronics on the main unit itself are probably in the range of 600 to 700ma. Thus with three units, max load from terminators of 1.5A and 1.8 to 2.1A for the combined main unit draw, the converter is driving 5-6A which is right in its design range. 

In my application, most signals do NOT have termination resistor pairs on them. This sharply reduces the current demand of the terminator board, so that even with most signals asserted low the draw is down around 500-600ma. Add in my main unit electronics demand of 600 to 700ma, and the load on the converter is just a bit over 1 amp. I suspect this relatively light load is why the converter is dropping in and out of economy mode, producing the ringing as it switches back on at the 33.3KHz rate. 

PLAN TO RESOLVE THE POWER SUPPLY NOISE

I plan to add load so that the DC to DC converter in the V2315CF power supply module (TOBSON EA50 dropping the 1130's 12V down to 5V) will remain out of the economy mode that is producing the bursts every 30 microseconds. I will add 2.5 ohms of resistance able to dissipate the 10W of power this will consume. 

I will also look to quence the ringing by adding filtering capacitors at the input to the V2315CF main unit. A 100 uF low ESR electrolytic in parallel with a .1 uF ceramic should minimize ringing even if the converter does drop into economy mode. 

LOOKING AT WRITE CLOCK SIGNAL AS IT ENTERS THE IBM 1130 CIRCUITRY

Finally I monitored the clocking signal produced by the V2315CF that is sent to the IBM 1130 disk controller logic and causes it to output the serial bit stream that is written to a 2315 disk cartridge by the internal 2310 disk drive in the 1130 computer. It looked perfect when monitored on the source end at the V2315CF but I set the scope and logic analyzer to watch the destination in the 1130 for any signal abnormalities. 

The signal looks terrible! It pulls up to a max of 2V, has a very slow rise time indicative of the substantial capacitance of the signal path between the 1130 logic gate and the V2315CF main unit, and there is a plenty of ringing at the falling edge. 

It has a 1V undershoot and a max level of under 2V for logic high. Nominal voltage levels for IBM Solid Logic Technology (SLT) are 0 and 3V. Fortunately SLT quite tolerant of negative voltages on the inputs, but the SLT transition voltages (max logic low voltage and minimum logic high voltage) are 0.3 and 1.8V respectively. 

The ringing of the falling edge goes just above 0.3V although its duration is under 10 nanoseconds, which is too short for most SLT gates to switch. The max level is very near the minimum acceptable level for logic high. Most SLT input gates are diode-transistor logic (DTL) and look like this:

The diodes and transistors in SLT are germanium with voltage drops close to 0.3V each, which I have indicated on the diagram. If all the AND inputs are at the nominal 3V level. the voltage at the thick black vertical line would be 3V due to the voltage divider of the 2K resistor to +6V, the 5K resistor to -3V and the two diode voltage gaps. The voltage at the base of the transistor would be 2.4V, thus the transistor conducts to pull the output low. Since this is a NAND circuit, that is the correct behavior.

When any of the inputs is sinking to ground (logic low), if the actual voltage of the input is 0.3, the effect of the diode drop is to make the thick black junction drop to 0.6V and the transistor base sees 0V, so it is cut off. The transistor must see at least 0.3V for its base-emitter junction to conduct, thus the thick black junction needs a bare minimum of 0.9V. 

After many runs capturing the same writen data, but with slightly different results, it seems possible that the 1130 was seeing an extra clock transition, relatively rarely. The 1130 stays in sync for more than 12 data words, sometimes more sometimes less, but then sends an extra bit or drops a bit. That could be due to glitches on the line.

ODD OBSERVATIONS DURING THE TESTS

I did see a few things that don't make sense to me when looking at the logic analyzer traces and the results of what was captured and written to the RAM of the V2315CF and thus to disk. I will cover them here because achieving reliable write functionality requires that I understand what is going wrong so that I can develop a solution to each cause. 

Apparently missing instances of catch when word correctly captured

Below is the capture of the sync word - at the end of the preamble of a long string of zero bit cells, the pattern 1 1 1 1 0 indicates that we found the sync word. The bit cell just to the right of the vertical red line is the start of the first bit of the first word of the sector. 

The bottom trace is the diagnostic output catch which is should be 1 only when my logic detected that the bit cell was for a data value of 1. The trace above it is the -Write Clock Phase B signal that is the clock we generate and send to the 1130. Atop the clock line is the output from the 1130, the signal -Write Clock and Data which is inverted logic so high on the trace is a 0 and low is a 1 value. 

When the clock signal -Write Clock Phase B is low, it defines the half of the bit cell that represents a clocking pulse. The value of the -Write Clock and Data for the first half, the clocking pulse, will be a logical 1 which is low since that signal line is inverted. When the -Write Clock Phase B signal is high, this is the data half of the bit cell and we look at the predominant state of the -Write Clock and Data signal to pick up the data value. A low output indicates the data bit value is 1. 

Thus in this trace, we see that during the data half of the bit cells, we have low on the output line for four bit cells, giving us four bits of 1, followed by a bit cell where the data half has a high on the output meaning a bit value of 0. That represents the sync word pattern 1 1 1 1 0 and we have properly detected sync. Note that my catch output is high for the four bit cells that are a 1 and low for the last, showing that my logic picked up the pattern properly.

However, in the next section of the trace, the first data word being captured, we seen some places where catch should emit a 1 but did not. The word being transmitted is x8080, which when reversed to write on disk would be the pattern 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 and its four check bits will be 1 1 0 0 to pass the error checking algorithm. The data received was stored in RAM and the disk as 8080, so we know that it did read properly. 

We see the data extracted from that first word and the check bits. The values of the -Write Clock and Data signal are correct and represent the value 8080 plus a correct check bit pattern of 1 1 0 0 but the catch line seems to have missed the check bits that were 1. It turns out that this is a self inflicted error, see my Verilog logic producing the signal catch below. 

At the falling edge of -Write Clock Phase B when we are in the stage of the state machine that is collecting data words, I capture the inverted value of the signal -Write Clock and Data to emit catch. Foolishly, however, I only do this for the first 16 bits of the word being detected. I zero it out for the four error checking bits. 

My python program that interprets the excel spreadsheet stored from the logic analyzer run uses catch to detect the value of every bit, including the error checking bits, therefore it does not correctly check the ECC value. Look at the results of the program below and you will see that it flags the first word, 8080, as having an ECC error when it is only because my diagnostic output catch failed to emit them. 

By the time we get to word 5, however, we have a true issue with the logic which I will cover in the next section. Meanwhile I will correct the verilog code to include the ECC bits in the catch signal. 

Bits emitted by 1130 are out of sync with the detected values

The sequence that I wrote from the buffer in the 1130 was 8080, 6969, 0000, 0000, 0002, 2000 and other data - the V2315 gets it right for quite a while, judging by what was written to RAM. It only goes off when it is capturing data I wrote as F000 that it recorded as 01E0. This is a run I did after I completed the logic analyzer capture, so the results are a bit different than what I see in the spreadsheet and logic analyzer trace. 

Going by the data captured in RAM, it captured 0002 and 2000 properly, as shown below. The 1130 has correctly produced the pattern for 0002 (inverted 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 with ECC bits 1 1 1 0 and we saw that.  

Similarly, the next word (x2000) is correctly captured and the logic analyzer trace looks good. 

It is only when we get down to around word 50 that we see the capture go off the rails during the final test run. At least through word 10 everything was recognized properly. There are a bit less than 800 bit cells between the last known good word and the first known bad word. Sometime in the 116 microseconds that span took, a bit was shifted off. 

I turned to the run where I have the logic analyzer capture and produced a spreadsheet from it. When I look at the trace I see that the 1130 and V2315CF got out of sync by the time of word 5. It should have been reorded as 0002 just as we see in the picture above, but it came out as 0004 with malformed ECC bits. 

Somewhere from the correctly placed bit 15 (next to last bit) of word 2, which was decoded as x6969, up to word 5 bit 2 (second bit) which should have been a 1 but the 1 is shifted to the right one bit. All the 1 bits we expect are shifted to the right one bitcell from this point forward. 

The timestamps in the spreadsheet and the logic analyzer trace shows that the bit cells are in the correct place, it is the bit value sent by the 1130 that has shfited to the right. On this run, we saw another shift of a bit to the right somewhere from the end of word 9, which should have been 1236, and the first few bits of word 10 which should have been captured as 1237. What was captured for word 9 was 246C and word 10 was grabbed as 48DC. This is the second shift to the right during this run.

Thinking about how this could happen, it suggests that the IBM 1130 is how we are getting out of sync. The logic that transmits the data is driven by the -Write Clock Phase B that is generated by the V2315CF. That signal enters the logic of the 1130 disk controller in two places. The first generates the shifting operations that move the bits of an 1130 data word out serially bit by bit. The second controls the multiplexing of the -Write Clock and Data output signal between the 1 that is sent for the clock half of the bit cell and the data bit sent in the second half of the bit cell. 

Above we see that when a write is underway (+Write Select is high), the -Write Clock Phase B drives the -Counter Sample signal low while the clock is high. This means during the data half of the bit cell. Also, during a write (+Write Select high) whenever +Bit Counter Gate is high and -Bit Counter E is high, the signal -Shift Gate is asserted low. 

Each word from the buffer in memory is fetched into the disk controller and then the bits are shifted out one by one to write serially on the disk drive. Hardware in the controller counts out the bits, so that the data word, which consists of 16 bits, is shifted out and then four error checking bit are emitted. The counter counts out the 20 outgoing bits.

Bit counter E is on during the four error checking bits, otherwise it is off. Since it is inverted logic, when -Bit Counter E is high, we are outputing the 16 data bits of the word then low during the rror check bits. This means that the signal -Shift Gate is low when the +Bit Counter Gate is high and we are handling the data bits.  

During a write, when we are in the data half of a bit cell, the signal -Counter Sample is low. 

The actual pulse that causes the data to shift is triggered by a pulse called -Shift SP if the signal -Shift Gate is low and a pulse arrives because -Counter Sample goes low.  From above, -Counter Sample goes low when -Write Clock Phase B goes high which is when we are entering the data portion of the bit cell. The single shot timer delays this then activates the shift pulses and also increments the two bit counter for the ECC value if the data bit being transmitted is a 1. 

The output from the 1130 on -Write Clock and Data is a line that emits a 1 or 0 value (inverted) and the value emitted depends on whether we are in the clock half of the bit cell or the data half. The bit cell is defined by the -Write Clock Phase B signal coming from the V2315CF - when that signal is low, it defines the clock half of the bit cell and when it is high we are in the data half. 

It is only active when +Write Select is high, e.g. when we are in a write. The output is low when -Write Clock Phase B is low, meaning we send a 1 bit during the clock half of the bit cell. The output is also low during the data half of the bit cell if the bit at the end of the shift register is high and -Bit Counter E is high (we are processing the 16 data bits of the word) - this means that if the end of the shift register is a 1, we assert -Write Clock and Data low during the data half of the cycle.

Finally, if we are handling the four error checking bits after we shifted out and transmitted all 16 data values, then +Bit Counter E is high and as long as the two bit counter for the ECC value is not zero, we assert -Write Clock and Data low to output a 1 as an error checking bit. The two bit ECC counter is incremented by this output. As the bit counter counts out bits 17 to 20, we send out a bit value of 1 when the ECC counter is non-zero and then send out a bit value of 0 once it becomes zero. 

This is how we calculate the correct number of 1 bits to send in the ECC bits so that the total of all 1 bits transmitted becomes an even multiple of four - the two bit counter rolls over to zero if it reachs 3 and is incremented. This produces the only valid ECC patterns 0000, 1000, 1100, and 1100 as these occur when the initial value of the ECC counter was 0, 3, 2 or 1 respectively when we finished counting the 1 bits in the 16 bits of the data word. 

The failure we are seeing is that we are missing a shift of the data and not incrementing the bit timer even though we have a bit cell (a complete cycle of the -Write Clock Phase B signal). The bit cell comes in, generated by the V2315CF, and we emit the 1 value during the clock half of the bit cell, but since we didn't see the high value of -Write Clock Phase B during one of these glitches, it didn't drive -Counter Sample and we didn't produce the shifting and counting pulses. Whatever bit value was in the end of the shift register is just transmitted another time when this situation occurs. 

This has to be caused by the poor signal quality observed where the -Write Clock Phase B signal enters the 1130 at gate A, compartment C1, slot K6, pin B03. Once I correct the signal quality, I expect the slipped bit problem will disappear. 

PLAN TO FIX THE QUALITY OF THE CLOCK SIGNAL ENTERING THE 1130

I had installed some weak terminator resistors for this output, which don't seem to have the oomph to pull the signal line up even to 2V because of the voltage divider formed in the path from the terminator to the input of the gate at pin B03 of slot K6. I will restore the 169 and 249 ohm resistors at R33/R34 of the terminator board. That should also help with the ringing observed on the scope. 

I will observe the signal using the scope after making the change to the terminator resistor pair. Assuming I see the signal rise up closer to 3V, the rise time improve and the ringing ameliorate, I will run new tests to check the functionality of the write to the V2315CF. 

Testing Virtual 2315 Cartridge Facility capturing data written from the IBM 1130 to the virtual disk

RAN WITH THE NEW LOGIC, TESTING WRITE IN VIRTUAL MODE

Armed with the logic analyzer trace of the exact timing that the Virtual 2315 Cartridge Facility (V2315CF) would see of the two related signals, -Write Clock Phase B and -Write Clock and Data that are used during a write to the disk, I arranged the logic in the FPGA to capture the correct bit values so that they could update the sector data in the RAM, just as the sector would be updated on a 2315 cartridge in the internal disk drive of the IBM 1130 if we had not installed the V2315CF to intercept the signals. 

The method used to store data on the internal disk drive (2310) uses two 690 nanosecond long intervals, back to back, to record each bit. The first of the two intervals always has a pulse, which is a clock. The second of the two intervals only contains a pulse if the bit value is 1, otherwise the interval passes without a pulse. 

A sector begins with a long string of 0 bits, allowing the drive to synchronize in order to assign each pulse it sees to either a clock or a data signal line. The first 1 bit defines the start of an 1130 data word begins as the next pair of intervals. The 1130 has words of 16 bits, but on the disk an additional four bits are recorded for error checking. Thus there are twenty pairs of intervals per word, with up to 321 of these fitting on a sector of the disk. 

When a write begins, triggered by the 1130 activating the signal -Write Gate, the disk drive starts generating a clock signal of 1.44 MHz while which is assigned to be the clock, then on the other half of the cycle it will only emit a pulse if the data bit value is a 1. Both the clock and the data interval are s nt on the same signal line -Write Data and Clock, which the V2315CF has to evaluate to determine which bits are a 1 and which are a 0. 

When the -Write Clock Phase B signal drops from high to low, which marks the data interval, my logic will grab the value of -Write Data and Clock and if it is low, the bit value is a 1 otherwise if high the bit is a 0. It had previously waited through the initial sequence of 0 bit values until the first 1 bit is seen. We then collect the next 20 bits and save the first 16 as the word. 

The last four are a special pattern that matches the number of 1 bits in the first 16. This error checking code allows the disk drive to detect errors when reading back the data later; if the error checking bits aren't write, the 1130 flags the data has invalid. 

RESULTS OF WRITING A SECTOR TO THE V2315CF WITH THE NEW LOGIC

I started up the 1130 with the V2315CF in the virtual mode. A mini 2315 cartridge was inserted into the V2315CF and loaded, so that the File Ready light illuminated on the 1130 console. I executed an XIO Start Read instruction which brought the data from the sector into memory. I altered a couple of words of the data and then issued an XIO Start Write to put back the modified data in the sector. 

I zeroed out the area of memory then repeated an XIO Start Read to bring back the value from the V2315CF into memory. If it matches the modified version and as long as the V2315CF validates that each word had the correct error checking code when it was written, then we know that the write is working properly. 

However, initially I was getting garbage in the buffer and back on the mini cartridge after I unloaded it. I traced it down to an error that regressed into the code as I was adding in some diagnostic output. The memory controller was not properly advancing the address after writing each word to RAM. It took a while to find it, some simulation to prove it however the fix was quick. I just returned the proper logic statement to the code and that issue was gone.

However, I was back to the problem that the logic was not capturing the bit stream coming from the 1130 system. I put the logic analyzer on to the V2315CF and captured four signals: 

• -Write Gate (which turns on a write to a sector)

• -Write Clock Phase B (the clock signal I send to the 1130 to cause it to emit both clock and data bits depending on whether this signal is high or low)

• -Write Clock and Data (a value of 1 that is either a clock bit or a 1 in the data. A 0 data value is sent as a zero during the data portion of the prior signal)

• Bit value (a diagnostic output set to 1 when the data bit value of 1 is detected). 

I saw that the logic did NOT identify the start of the data on the sector, which would be a specific bit pattern that is the sync word. The capture during the time when the 1130 is sending the sync word is below. The four signals above are shown in order as horizontal traces. 

The sector begins with a long string of 0 data bits which is terminated by the bit sequence 1 1 1 1 0 causing the logic to begin sending 1130 data words as streams of 16 data bits plus four error checking code digits. The sync word is a word of value 1000000000000000 plus an ECC sequence of 1110 that validates the word as properly formatted. At the end of the sync word, the next bit is the start of the first data word of the sector. 

The -Write Clock Phase B signal alternates strictly at a 720 KHz rate, with the high level denoting the data portion of a bit cell and the low level of this signal signifying the clock portion. During the clock portion of every bit cell, the value of -Write Clock.  and Data is a logic low which means a 1 bit for the clock. There is always a clock bit in every bit cell but during the data portion of the bit cell we either have a logic low on -Write Clock and Data which means the data bit is 1, or a logic high that means the data bit value is 0. It can be confusing to interpret because of the inverted logic - a logic low means a value of 1.

The failure to detect the sync word is visible because the fourth signal in the trace should emit a 1 for each bit position that is transmitted as a 1, but it is a while later before the logic begins emitting that signal. This means it did NOT detect the sync word properly. 

At least I now have a view of the data coming in from the 1130 which should help me devise a strategy for reliably detecting the bit values. A bit of design work, some extensive simulation and then I resume testing in the workshop. 

Identifying issue capturing data on write to Virtual 2315 Cartridge Facility

THE ISSUE I WAS INVESTIGATING

The Virtual 2315 Cartridge Facility (V2315CF) attaches to an IBM 1130 computer and works in conjunction with the internal 2310 disk drive of that computer. The disk uses swappable 2315 disk cartridges to record 512K words of data stored as 1,600 sectors of 321 words each. A word on the IBM 1130 is 16 bits long. 

The V2315CF allows mini cartridges to be used instead of actually reading and writing to a physical 2315 cartridge. The IBM 1130 sees the V2315CF system exactly as it sees the real 2310 drive, other than diverting data to stream on and off of the mini 2315 cartridge instead of the disk surface of the 2310 drive. 

When the 1130 writes a sector of data to the disk drive, the V2315CF should capture the stream of data and use it to update the sector in the RAM inside V2315CF, which will be used to update the mini 2315 cartridge (containing a microSD card to hold the data) when the virtual 2315 cartridge is unloaded at the end of a session. 

Currently the data is not recorded correctly in the RAM and thus the mini 2315 cartridge contents are corrupted for any sector where the 1130 wrote. In addition, the V2315CF checks the data that is coming from the 1130 to be written on the sector. At the end of each 16 bit data word, the 1130 sends four additional bits of error checking code that allow the 1130 to detect if a word is corrupted when being read from disk. Any time the 1130 reads a sector from a mini 2315 cartridge, the V2315CF generates valid ECC bits at the end of each word during transfer into the 1130. The 1130 will see the incoming data as valid. 

The V2315CF verifies that the data word and its ECC bits are valid during the write to a sector - data transfer from the 1130. If we see an error, we turn on a disk fault condition, make the disk drive appear to be not ready as far as the 1130 is concerned, and cease operation until the mini cartridge is unloaded. This should not happen. Somehow I am detecting an error, in addition to not producing a sector whose contents matches the data sent from the IBM 1130 during the write operation. 

REDESIGNED BASED ON CAPTURED LOGIC ANALYZER SIGNALS

I had spotted some reasons that my earlier approach wasn't working. Based on that, I redesigned the logic to be more reliable. Simulation suggested it would work, but of course the proof is in the pudding - I have to test with actual hardware to be sure it works as intended. 

At the same time, I implemented the 90 second wait when the disk powers up in the Raspberry Pi Pico code, rather than in the FPGA where it had been previously implemented. Once the mini cartridge image has been read and loaded into RAM, if the drive is in virtual mode, then the system loops for 90 seconds before it continues to consider the cartridge loaded and make the disk drive ready. 

Having this in the FPGA meant that I had to count to 90 seconds, making use of a pulse I emit once each microsecond for timing purposes. That means I had to count to 90 million, requiring 28 D flipflops and an adder with carries wide enough for a 28 bit integer. This is what pushed the count of required logic elements over the capacity of the Lattice FPGA chip I was using. By moving this to the PICO software I freed up those logic elements and had room left for all the functionality I needed in the FPGA. 

OBSERVATIONS WITH THE LOGIC ANALYZER AND OTHER TOOLS

The logic analyzer captured the signals used by the IBM 1130 to write the sector to the disk drive - -Write Clock Phase B and -Write Clock and Data. It also is triggered by the activation signal to the disk drive -Write Gate and records the output of the V2315CF where I emit the bit value detected when I am capturing each bit. Finally I output a diagnostic signal I can use to track how well my logic is accomplishing the goal of grabbing the data sent by the 1130. 

In addition to the logic analyzer, I have other tools. I can read the sector from the mini 2315 cartridge using a utility tool and programs I provide along with V2315CF. When I write from the 1130 to a sector and then unload the mini cartridge, that new data is inside the mini cartridge. Reading it with my utility programs gives some evidence of what was placed into RAM. 

I had read in sector 0 of the mini cartridge then changed the first few words of the sector in 1130 memory before doing a write of the memory back to sector 0. This should cause the mini cartridge, after being unloaded, to have the original data except for the few words I modified which should capture the values I entered.

It is not working correctly. What I see from the logic analyzer trace is that it is not detecting the sync word, so it starts decoding the words much too late. Below is the entire sector, where the last horizontal line is the 1 bit detection output I created for diagnosis purposes. It should start about 435 microseconds into the 10 millisecond sector, but as you can see it waits until almost halfway through the sector before it begins detecting. 

Here is the sync word coming in from the 1130 but not being detected by my logic. With inverted logic, the third signal line has the clock interval when it is low and the data interval when it is high. The second line is the combined clock and data signal from the 1130, where a low means the bit is 1. There is always a 1 bit in the clock interval (the second line is low at that time), but during the data interval we have a 1 bit for data only if the second line is low. 

The circled area is where the sync word is generated by the 1130. The data bit values are listed in yellow below the data intervals. We see data bit values of 1 1 1 1 and 0, which is the pattern that is the sync word. There was no capture of the 1 bit values in the fourth line, but it should be emitting them. 

A CLUE COMES FROM WHEN THE 1 BIT DETECTOR PULSES START

The diagnostic output signal I captured in the fourth row should be produced as soon as the logic considers the sector to have started. It watches the data stream until it sees the sync word pattern, which will show up in the fourth line as well. That triggers the collection of the 321 words of data for the sector. 

I now suspect that the defect is related to the sector marker pulses. The disk drive generates eight such pulses in a rotation of the disk platter, but the disk hardware hides every other pulse so that the 1130 only sees four sector marker pulses, corresponding to four sectors of data held on a rotation of the disk. 

My state machine that handles a disk write waits to see a sector marker pulse to end before it begins the writing logic. The 1130 asserts the -Write Gate signal low, which begins writing the sector. I suspect that when I see that signal asserted, I have missed the edge of the -Sector Mark pulse and therefore my logic waits until the next pulse halfway through the sector before it starts looking for the sync word. 

I will look at this, simulate it and change the logic so that it is not skipping the first half of the sector. I am hopeful that this will resolve the issue, but will have to wait for a couple of days because I am tied up all day tomorrow at Disneyworld and then guiding friends through the Kennedy Space Center Visitor Center on Friday. 

Another write test of Virtual 2315 Cartridge Facility after correcting FPGA logic

BASED ON DISCOVERY OF THE ROOT CAUSE, I CORRECTED THE DESIGN

The state machine I developed to capture the data from a write command issued by the IBM 1130 to the disk drive started out of the idle condition based on a couple of conditions. One of them was unnecessary since the other condition already encompassed that event. Much earlier, testing had not failed, only due to good luck, but a small change I made a while back to debounce the incoming signal added a few cycles delay which was enough to cause the failure.

The Virtual 2315 Cartridge Facility (V2315CF) sits in between the IBM 1130 computer and the internal 2310 disk drive, substituting data held in RAM in the V2315CF for what would have been read or written by the disk heads. The 2310 disk drive uses interchangeable 2315 disk cartridges, hosting a 14" diameter magnetic platter, to store 512K words of data. 

A rotation of the platter is divided into four equal sized segments, called sectors. A pulse, called a sector mark, is generated by the disk drive although physically the 2315 cartridge has eight slots around its ring thus produces eight sector markers per rotation. The IBM 1130 disk controller logic blocks every other sector marker pulse so that it indicates the start of each of the four logical sectors. The disk arm can move in and out between 203 cylindrical tracks that the head traces as the platter rotates. 

When the IBM 1130 executes an instruction to write to a sector, the programmer specifies which of the four sectors will be replaced. The 1130 is keeping track of which sector is currently passing under the disk head and when the sector mark arrives for the sector being requested, the 1130 asserts the -Write Gate signal to begin the writing. 

My state machine looked for the -Write Gate signal to go low but also waited for the falling edge of the -Sector Mark signal. If the sector mark pulse occurred coincidentally or after the falling edge of -Write Gate, my state machine would begin the write process. I did this based on some timing diagrams from IBM maintenance documentation, however the diagram implied that -Write Gate changed prior to the sector mark pulse. This was incorrect but the assumption drove my logic design. 

The V2315CF generates a clock signal, -Write Clock Phase B, which it sends to the 1130. The 1130 uses a 1.44MHz oscillator in the disk drive to read and write data. Each 'bit cell' is divided into two halves, each 720 ns long. Because the FPGA clock is 25 nanoseconds, I am actually generating 725 ns intervals rather than 720. In the first half we are transmitting a clock bit of 1 and in the second half we send the data bit value, either 0 or 1. 

The 1130 outputs a combined signal -Write Clock and Data which always goes low for one half of the clock signal, but is either low or high depending in the other half based on whether the data bit value is a 1 or 0 respectively. The logic is inverted: a low level is a value of 1. Thus, -Write Clock and Data alternates a constant 1 bit with a data bit that is either 1 or 0. My logic extracts the data bits from that stream and writes them into RAM in the location assigned to the sector.

The state machine watches the data bits being extracted, waiting during an initial long stream of 0 data bits for a specific sync word pattern 1 1 1 1 0 that tells us the very next data bit will be the low order bit of a 16 bit 1130 data word that has a four bit error correcting code appended (thus 20 data bits per 1130 word). We grab the 16 bits of data, validate that the error checking code is correct, then store the word and evaluate the next sequential data bit as the beginning of word 2 of the sector. This continues for up to 321 words, the max capacity of a sector on the 2315. 

When I added a debouncer to the -Write Gate signal in order to ensure that a glitch wouldn't spuriously trigger the state machine, it added a bit of delay to that signal. The undelayed -Sector Mark signal therefore had its falling edge before my state machine saw -Write Gate and that meant the state machine did not receive the conditions needed to begin. 

Since the 2315 cartridge actually generates 8 sector pulses per rotation - the 1130 ignores every other pulse so that it can create four larger sectors instead of 8 small ones. However, the -Sector Mark pulse I see with the V2315CF is the undivided signal with 8 pulses per rotation. Thus, the second sector mark pulse does arrive in the middle of a sector during the write - it is normallyignored . My state machine, having failed to leave the idle state when -Write Gate first was asserted, started at the midway point of the sector. 

It is too late at that point to see the sync word - that comes about 10% of the way into the first half of the sector. My logic does come across a data bit sequence that is 1 1 1 1 0 at some point and begins interpreting what follows as the low order bit of word 1 of the sector. This produces gibberish, which is what I saw stored in RAM after a write was issued by the 1130. 

Examining the logic diagrams for the 1130, I can see that the -Write Gate signal is generated from the issued request for a write when the correct sector number is arriving but also when the falling edge of -Sector Mark takes place. Thus, that condition is already implicit in -Write Gate going low. I erroneously enforced it in my state machine but the relative timing of the two signals were unfavorable for correct operation.

The change was very simple. I didn't monitor the falling edge of -Sector Mark as a start condition, only -Write Gate, which fixed the problem. I generated a new bitstream to load into the FPGA chip in the V2315CF.

RESULTS OF TESTING WITH THE CHANGED LOGIC

The test I use is to first read in a sector into a buffer in 1130 memory, then manually change a few words before issuing a write of the same sector. This should replace the contents of the sector with the changed data. I can validate that by reading it back with another read command, but also examined the mini 2315 cartridge that was loaded into the V2315CF during the testing. 

When I unload the cartridge at the end of the test, the V2315CF writes back RAM to the microSD card inside the mini cartridge. This can be examined on my PC using a utility reader and a program to display the contents of any sector. It proved that the modified data was what was placed on the cartridge. 

I also will see the bit pattern extracted by my state machine using a logic analyzer to capture the -Write Gate, -Write Clock Phase B, -Write Clock and Data, and a diagnostic output signal that showed whether each data bit was captured as a 1 or a 0. The results were much better, with the write occuring immediately as the -Write Gate signal was asserted low. It did detect the sync word and begin collecting data. 

However, I wasn't happy with the quality of its operation. I noticed a few places where it skipped over a data bit value of 1. These seemed to take place soon after a glitch on the -Write Gate signal. I had debounced that signal, thus a glitch would need to stay on for 400 nanoseconds or longer in order for my state machine to see the signal as reset. The glitches were all 10 to 20 nanoseconds long, much too short to pass through my debouncer. 

Instead, it appears that another logical condition that I combined with the -Write Gate, indicating that a cartridge is ready for use, may have glitched. This condition is detected by the Raspberry Pi PICO processor based on having loaded a virtual 2315 cartridge and the drive becoming ready to access. It should not be reset unless we turn off the drive or it becomes not ready due to a fault. 

However, this is just a bit sent over the SPI (serial peripheral interface) link between the PICO and the FPGA logic. A message type of x00 will set the cartridge status based on bit 4 of the data byte in that message. If the SPI link is spuriously processing a message of that type it might be resetting the bit temporarily, however whatever condition is causing my state machine to believe that the write should end is quickly restored. Thus, I have my suspicions that the SPI link is not at fault in this error. 

However, since it is the only condition besides -Write Gate that is used to abort the state machine, I don't see an alternative explanation at this time. What does appear to be happening is that my write state machine is aborting back to idle soon after a glitch on -Write Gate that shouldn't pass through the debouncer. 

If the signal is seen as deasserted or the cartridge ready condition is withdrawn, the state machine goes back to idle. Because -Write Gate is intentionally asserted, once the glitch conditions expire the state machine will start over, scanning for another sync word. If it sees a 1 bit it will treat that like a sync and begin extracting data again. From the time when it went to idle until the time it sees the first data bit of 1, it is skipping over data. 

I removed the cartridge ready condition from all the aborts. It is now only required to start the write state machine out of idle, otherwise we will only abort on deassertion of -Write Gate through the debouncer logic. 

I suppose another possibility to consider is if the power to the V2315CF unit is drooping or noisy, it might be both the reason I see the glitch on the -Write Gate signal and the cause for the state machine to abort back to idle. I will put an oscilloscope on the 5V power rail going into the V2315CF main unit and set it to trigger if the voltage dips below about 4.8V. I can add some smoothing with a big filter capacitor if this is the cause. 

DEVELOPED TOOLS TO HELP ME BETTER WATCH THE WRITE PROCESS

My main data capture is a logic analyzer that is monitoring four signals, triggered when -Write Gate has a falling edge and recording for long enough to cover multiple sectors. I use the program DSView that comes with the analyzer to look at the signals and evaluate my FPGA logic strategy based on the actual signals being used. 

The program has an option to produce a CSV (comma separated values - file format used with Excel spreadsheets) of the data during the period when the signals are actively changing. The logic analyzer takes a sample of the signals every 10 nanoseconds and records the time when at least one of those signals changes along with the four signal states. 

A write to a sector is transferring 321 words of data from the 1130 to the disk. It begins with a preamble of about 250 microseconds where the data bit value is always 0. This helps the disk drive determine which pulse on the disk was recorded as a clock bit (always 1 so always a pulse) so that it can know where the first half of the bit cell begins. It then watches the secodn half of the bit cell, the second 725ns of the bit cell, for a pulse to indicate a bit value of 1 otherwise the absence of a pulse during this half is taken as a zero. 

Data is serial on the disk surface - a stream of over 6,420 bit cells. to record 321 words of data. Each word on an 1130 is 16 bits long, but when written on disk, an additional four bits is appended to each word that forms an error checking code (ECC). Thus a word requires 20 bit cells in total. The value of the ECC bits are checked against the 16 bit data word such that the sum of all data bits in the word plus the ECC must add up to a number which is an even multiple of four. 

A data word of x1000 for example has only one data bit set to 1 so it needs the ECC bits to contain three 1 bits in order to arrive at an even multiple of four at the end of the word. A word of xFFFF already has 16 bits set to 1, thus already an even multiple of four so the ECC bits must all be 0. 

Because this is a serial stream, the disk drive has to determine which bit cell is the start of a new word. This is assisted by a sync word beiing written. The sector begins with that preamble of all zero bit values, followed by the sync word. The pattern of the sync word is 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 and ECC bits of 1 1 1 0. The preamble is a long string of zero bits, so the first data bit of 1 is considered the end of the sync word (plus its four ECC bits of 1 1 1 0). This defines the very next data cell after the last ECC bit as the first bit of the first word of the sector. 

Words are streamed out twenty bit cells at a time until the count of words to be written is completed. Normally, the 1130 uses 321 words for a sector so that is the reason we will see 6,420 bit cells from this point to near the end of the sector. Recording the state of those signals from the time that -Write Gate is first asserted until it is turned off produces 28,900 rows of spreadsheet data. I save this as an Excel spreadsheet file. 

I wrote a Python program that reads in the spreadsheet file, locates all the points where the -Write Clock Phase B signal has a falling edge and captures the value of the -Write Clock and Data aignal at that time. Because the signals are inverted, I flip it so that a -Write Clock and Data value of 0 is recorded as  a bit value of 1 and vice versa. 

The program watches for the first data bit that is a 1 (the sync word) and begins interpreting bit cells after the ECC bits of the sync word are processed. I collect the 16 data bits, which are recorded in reverse order to how they are stored in IBM 1130 memory, convert them to the correct hexadecimal value in the order they exist in memory and print them. I print the word number and the timestamp of the start of the word. 

I then collect the ECC bits and perform the validation, printing an error flag and the ECC bits if they word is not valid. This should match the data I wrote from the 1130 that the FPGA is capturing from the data stream. It should also match the data that is recorded on the virtual 2315 cartridge by the V2315CF when I display the sector after the testing. I can use the timestamp from the Python program to find the spot in the logic analyzer trace where the word starts, if anything is wrong with how it is captured. 

The trace is about 7,130 bit cells long, which is why I needed to pointer into the timestamp to help me look closer at any point where I don't like the results. 

I took the existing data at the first sector of the virtual 2315 cartridge, overwrote the first few words with x6969, x0000, x0F00, x0000 and x0000 leaving the remainder as it was. Word 9 of the existing sector had a value of x0002 and then the next non-zero word was numbrer 32 which should have been x00EF but is incorrect in the output above. The bit pattern on the disk should have been 1 1 1 1  0 1 1 1  0 0 0 0  0 0 0 0 with ECC bits 1 0 0 0 yet the data captured had shifted by one bit cell. x00EF became x01DE because of this shift. 

The machine was capturing successfully when it saw the word 9 (x0002) but got out of sync somewhere between there and where word 32 began. Each bit cell is 29 microseconds long, and the times seem to line up consistent with that for the start of each of the 32 words shown above, but somehow the -Write Clock and Data value slipped. 

Looking at the trace at the start of word 32, we can see that the 1130 did indeed send us the first three bits as 0 1 1 instead of 1 1 1. The top trace is -Write Gate, the bottom trace is -Write Clock Phase B and the middle trace is -Write Clock and Data, all of them inverted logic. 

When the -Write Clock Phase B is high, this is the second half of a bit cell where the data bit value is transmitted. The first bit has -Write Clock and Data high, e.g a data bit value of 0. The next two bit cells have data bit values in -Write Clock and Datathat are mostly low, thus denoting a bit value of 1. This is what my FPGA logic captured, what the logic analyzer and Python program captured, but not what I wrote. 

This suggests to me that the 1130 is seeing glitches on the -Write Clock Phase B signal causing it to think it missed a bit cell somewhere between words 9 and 32. The logic analyzer is capturing the source of the signal -Write Clock Phase B which is the V2315CF unit, coming out of my FPGA logic. On the logic analyzer the signal looks completely clean with no glitches that might suggest a reason the 1130 got out of sync.

I will need to observe the other end, where the signal arrives into the IBM 1130, to see if glitching is occurring over the signal path. I will capture another trace with the logic analyzer, hooked to pin B03 of slot K6 of compartment C1 of logic gate A in the 1130. It is also tied to pin D12 of slot L7 in the same gate and compartment. The first pin is used to cause the 1130 to shift bits out one by one, serializing each word, while the second pin is used to switch -Write Clock and Data between a constant 1 value for the clock half and the data bit value for the data half of the bit cell. 

I will hang a scope probe on one of the two pins above and the logic analyzer on the other, since they are both connected to the same signal coming from the V2315CF. 

There are several theories to be tested, if you have made it down to here in this blog post. First, I will be validating that the power is not dipping on the V2315CF causing glitching. Second, I will have bypassed the role of the SPI link so that it can't cause the resetting of the write state machine that I observed. Third, I will look at the -Write Clock Phase B signal as it is connected into the IBM 1130 disk controller logic circuitry. 

Installed prototype enclosure and attempted testing of Virtual 2315 Cartridge Facility

INSTALLED THE POWER COMPONENTS IN THE PROTOTYPE ENCLOSURE

The enclosure has an incorrect opening size for the Virtual 2315 Cartridge Facility (V2315CF) main unit, but I used it to work out the mounting locations for the various power components that fit inside. These are the power distribution pcb, the power supply, and the timer. I routed all the wiring through the side holes and the two ribbon cables through the rear hole of the enclosure.

This is the view that the operator sees when they tilt the top right cover of the IBM 1130 up (you can just see the hinge on the right of the picture), with the tabletop in front and the enclosure sitting atop the internal disk drive of the IBM 1130. The 3 3/4" diameter mini versions of the 2315 disk cartridge that are used with the 1130's internal disk drive (2310) are inserted into the opening on the right, which is a scaled down model of what the opening of the 2310 looks like. 

ATTEMPTED TO COLLECT DATA FOR THE WRITE ISSUE

I had brought out a signal on one of the unused output lines of the main unit of the V2315CF so that I could capture it along with the -Write Gate,  -Write Clock Phase B and -Write Clock and Data signals that the 1130 sends to the 2310 disk when it is writing a sector of data onto the 2315 disk cartridge. The V2315CF intercepts this data and stores it in RAM so that it can be written out to the mini 2315 cartridge which serves as the disk cartridge for our system with the V2315CF installed. 

The testing is simple. I first issue a read command from the 1130 that requests the data from cylinder 0, head 0, sector 0 be brought into memory at the location specified in the I/O instruction. The data on the mini cartridge should appear there - it has been reading correctly up until today - but instead of the valid data I found the filled with random garbage, mostly 16 bit words of 0xAAAA. 

If it had read correctly, I would then modify a few words in the memory buffer and issue a write command to store the buffer back in cylinder 0, head 0, sector 0. When I unloaded the cartridge at the end of the session, what had been written back to the mini cartridge was just the random junk, not the changes I made. Further, I found random junk written through many other sectors on other cylinders. 

It is acting as if the RAM is not working properly now. When I load a mini cartridge, the V2315CF reads the contents from the mini cartridge and stores it in RAM, then turns on the File Ready status allowing the 1130 to issue I/O instructions to the disk. However, the data is either not loaded properly into RAM or corrupted somehow while the testing is underway. Another possibility would have been that the rewrite to the mini cartridge when we turn off the disk drive is what is failing, except that the read command is finding the garbage so it is definitely in RAM. 

I may have introduced this error during the recent code changes I made for the diagnostic output needed to conduct this test. I will go home and use simulation to examine the behavior of my logic to discover what is going wrong. 

Test build of Virtual 2315 Cartridge Facility enclosure and mini disk drive

ENCLOSURE TO MOUNT VIRTUAL 2315 CARTRIDGE FACILITY IN IBM 1130

The Virtual 2315 Cartridge Facility (V2315CF) is installed inside an IBM 1130 computer with the main enclosure, constructed of acrylic, bolted to the top of the internal 2310 disk drive of the computing system. Cables from that enclosure connect to other elements of the V2315CF, as well as to the 2310 disk drive and the 1130 system itself. The 2310 disk drive accepts 2315 disk cartridges, which enclose a 14" disk platter that holds 512K 16-bit words of 1130 data. 

The enclosure front plate houses the main electronics of the V2315CF on the left and a miniature version of the front of the 2310 disk drive on the right. Mini 2315 cartridges are inserted into the mini disk drive, in the same way the real 2315 is inserted into the 2310 drive from the front of the IBM 1130. A switch on the miniature disk drive is an analog of the motor on/off switch of the real 2310. 

The mini 2315 cartridges hold a microSD card inside them that stores the 512K words of data that would reside on a real 2315. When the mini cartridge is inserted into the mini drive of the V2315CF, the motor switch on the mini drive turned on and the switch on the main electronics panel is flipped to Load, the contents of the mini cartridge are read and copied into RAM inside the main electronics. The File Ready lamp on the IBM 1130 console turns on when the V2315CF is ready to let software read, write and seek between cylinders of the virtual disk drive. 

The V2315CF supports two modes - real and virtual. In real mode, the physical 2310 drive in the IBM 1130 is switched on with a dummy 2315 inserted. It spins and the disk arm moves around as commanded by software in the 1130, while the V2315CF transfers data from the mini cartridge instead of the disk heads of the real 2310. In virtual mode, the physical 2310 drive is not turned on, but the V2315CF instead simulates its behavior so that the 1130 software can access the mini cartridge. 

When the motor is turned off and the main electronics switch flipped to Unload, the contents of RAM, which may have been updated as the 1130 software wrote new data to sectors of the 2315, will be transferred back to the microSD card inside the mini cartridge. Thus, the data is permanently saved on the mini 2315 just as it would be on a physical 2315 cartridge used with an unaltered 1130 and its 2310 disk drive. 

PROTOTYPE ENCLOSURE LASER CUT AND GLUED TOGETHER

My friend Barry Ward cut the design on some smoked black colored acrylic and glued it together. I added the support brackets and tested the mounting of all the components. Here I am looking to discover all the interference issues or other changes that will make the production version easier to build and service. 

TESTING PROTOTYPE OF MINI DISK DRIVE DESIGNED BY BARRY WARD

Barry Ward measured the front entrance of the 2310 disk drive from the IBM 1130 system at my workshop, along with a 2315 disk cartridge, and modeled miniature versions that will be used with the V2315CF. 

The mini 2315 cartridge is 3 3/4" in diameter and proportional to an IBM built 2315 cartridge. It mounts a PCB underneath with a microSD socket, a few components and a male 2x4 header that is in the rear. That header plugs into a female socket inside the disk drive when the mini cartridge is slid into the mini drive.

The front of the disk drive in the IBM 1130 is accessed by swinging the right front door open on the 1130 system, where you see the opening of the disk drive, with a blue handle used to open and close the drive, plus a motor switch. 

The drive handle is opened in the real 2310 drive, allowing a 2315 disk cartridge to be slid into the drive or pulled out. When the handle is returned to the vertical position, the cartridge is ready to be used. 

Prototype without motor switch mounted

The motor switch can be recreated with a very small toggle switch that is only a bit out of proportion (bigger than the real drive scaled down). Barry and I did some careful modeling in CAD and he is test fitting the modified front bezel right now. 

What a real 1130 internal drive front looks like

Barry has laser cutters and 3D printers in his home (and heavier duty machinery in his workshop). He is making the next revision of the prototype while I finish the work on the enclosure and other parts of the V2315CF. 

Debugging write of Virtual 2315 Cartridge Facility - ensuring data is captured correctly

WRITING DATA EARLIER IN THE CAPTURE OF EACH WORD

My logic had been waiting until the last of the twenty bits had been captured - the 16 bits of the data word and then the four error checking code bits that validate the integrity of the data. That was unnecessary and put the request too close to the point where we reset to begin accumulating the next word. I now lock in the data value while we are starting on the first ECC bit and request the write while we are starting on the second ECC bit. The RAM controller will put the word away in RAM while we are finishing up on the ECC bits.

Since it was possible that my garbled data was a consequence of address and data bits changing too close to the time when the RAM controller is driving the write, starting earlier should eliminate this risk. I updated the FPGA logic and loaded it into the Virtual 2315 Cartridge Facility (V2315CF) main unit. I again repeated my test where I read in a sector, changed a few words and then did a write to replace the sector. 

RESULTS OF TESTING WITH THE CHANGED LOGIC

The data was still wrong, but when comparing the data on the mini cartridge after the write with the original contents, I noticed that the sector was only changed up until the halfway point. That was a major clue. I went through the entire logic for writing to a sector, including the process of storing it in RAM. I expanded my simulation testbench to track all the aspects of reading and writing to RAM as well as the SPI link data that flows between the PICO and the FPGA.

I identified two issues that have to be resolved. First, the data is not being stored in RAM correctly. Second,  if I restore the logic that locks up the disk drive and puts it off line when an ECC error is detected during a write from the 1130 to the V2315CF, the fault light goes on during the write. That means I am detecting an ECC error during the write logic somehow, although the logic analyzer trace I collected makes it appear that I should be grabbing it correctly. 

The ECC error signal is routed on the V2315CF bus connector B pin U2 which I should be able to detect with the logic analyzer. This will tell me where in the sector write the error is first detected and that may serve as a clue. 

My next diagnostic change will be to output the data bit value that was captured, using the same connector B pin U2 of the V2315CF. Syncing that with the -Write Clock Phase B and -Write Clock and Data signals being captured on connector A pin T2 and connector A pin F2 respectively, I can see any place where I DON'T correctly capture the data value coming from the 1130. The changes were made ready and the logic will be installed into the V2315CF FPGA for the next testing session. 

EXHAUSTIVE SIMULATION RUNS AND INCREASINGLY SOPHISTICATED TESTBENCH

I have not been able to cause the ECC errors to show up when simulating the logic. I have not thought of a type of glitch or timing issue in the incoming signals that should produce the error, but keep adding details to the simulation allowing me to experiment until I can recreate the failure. Hard to fix it when the nature of the failure is unknown.

I should be able to triangulate in on the cause by alternating simulation sessions with live system data collection. Fixing the issue is easy once I know what is going wrong, but the real work has been in capturing the errors.