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.