Tuesday, August 2, 2016

Corrected 0.1% data corruption rate on USB link, finished replica cosmetics, successfully tested demonstration tasks

PREPARATION FOR VCF WEST EXHIBITION

This morning I thought about the corruption of the USB channel that seems to be causing problems. If even a transaction in a thousand fails to be received properly, that is enough to grind a job under DMS2 to its knees when using virtual disks and printers. Each disk IO involves dozens of transactions and each print line involves dozens too.

Turns out infrequent corruption was what was happening. See work below that toughened up the integrity of the USB link and yielded much better outcomes when heavily using the link - for example, booting from  virtual 2310 disk drive, printing on a virtual 1403 printer and reading cards from a virtual 1442 reader.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

USB link data integrity


I am suspecting that I have a low but nonzero rate of bad data transfer over the USB link, which produces problems such as failure to load core correctly or data corruption on a transfer. I devised a quick solution by doubling the transaction - resending the twelve words a second time to make a 24 word transaction. Then, if the two don't match, the FPGA will invert the first set of words and copy it to second set, then send it back instead of a transaction response, Otherwise, the second set of words is always an exact copy of the first set.

I had to work on the transactional engine to make this change. The GUI was changed to check for a pairwise match of the twelve words from the two sets, and resend the transaction if they don't match. This loop also emits a warning to the log on each error so that I will know the approximate rate of problems.

I had a bitstream ready to test with the changed GUI. I also set up the About function of the GUI to loop 1000 times before throwing up the dialog box, in order to see whether I was indeed getting corrupted transactions.

My first two runs of 1000 echo transactions gave me one error transaction each. The similarity of the error rate to my guesstimate yesterday of one in a thousand is a pure coincidence. I knew it had to be infrequent or most things would fail. However, it had to be often enough to cause the more sizeable traffic using virtual disk to fail, so it had to happen at meaningful words not just one in a million.

My recovery logic is designed to catch any dropped data and to resend the transaction. It isn't perfect, since there is still a way that a communications fault could slip through. What must happen is that the transaction gets down to FPGA fine, the response is sent back with return values in words 2 through 12 plus the mirrored input words 1-12 going back in words 13-24. If the only corrupted data is in words 2 to 12 of the 24 returned words, I can't catch it.

I need to figure out a way to checksum the returned data so that the receiving logic in the GUI can know whether there was a problem with its data words 2-12. To do this, I have to extend the transaction by another two words, sending a word 25 that is a checksum of words 2-12 and word 26 that shows the parity of words 2 to 12. I will have to think about whether this is indeed good enough or if I need an even more robust error test.

I may be experiencing this problem of bad return data in words 2-12, because I see some random lines of bad data printing on the virtual 1403, interspersed among many good lines. This makes it worthwhile to put in the additional error testing.

I had to shake down my code in both logic and the GUI program to ensure I was properly generating and checking the various parity and checksum values, but by the afternoon I had the GUI and FPGA talking to each other again, with all the error autodetect code in place.

It was too hot to run the 1130 by this point, so I moved on to the replica tasks. Tomorrow morning I can run the new and improved SAC Interface system and see how things behave.

COMPLETING REPLICA COSMETICS

Having sprayed the sand colored stone paint last night to give my new pedestal base the right texture, I put on the pebble gray color coats today, the major coat in the morning and a light second coat at lunchtime.

I cut sections of wood that will be the braces to hold the relatively heavy MDF faux covers in place. The need to be 1" wide, enough face area to stick to the MDF, and able to hold a screw for the small plate that will swing to hold the cover onto the frame bar.

I will make three heavy braces per panel - two for the bottom and one for the top on the three heavier ones - plus two light braces that will keep the panel from sliding left or right. For the two light panels, I only need two heavy braces.

By late afternoon, I was beginning to glue on the braces to the rear of the panels, starting with the blue front cover that will be so prominent. Given the work area in the back yard, I can only glue three of the five blocks on at a time, with half an hour of setting time before I unclamp and rotate.

My braces are not a full inch wide, so the rotating plates that will be attached by screw need some washers to raise them up. I should have plenty of washers as well as short wood screws. What I need to fabricate are the rotating plates themselves, hopefully leveraging some scrap wood I already have.

Did a test fit of the blue front cover - perfect with the blocks positioning it. Time to drill for the screw, set up the plates and try to install it in place. It worked just as I hoped, on solidly.

I placed the pedestal base on the frame but might need to secure it some how. It is pretty secure as it is, so I think I can just leave it as it is, I can place the display pedestal in position onto the base.

Just after dinner, I began gluing on the braces for the right hand gray side cover, the next major part to fit up. Taking two passes of gluing to get all five braces installed, I wasn't done until 7:30. Adding the rotating plates and installing on the frame took only a few extra minutes.

I do have a challenge in how to mount the last cover. The other four have four frame bars forming a rectangle upon which the braces can sit. The fifth, which runs front to back inside the footwell, from the edge of the blue plate to the inner gray cover, has only two vertical frame bars. There is nothing at the bottom nor the top.

I may be able to depend upon friction, if I put two braces the each of the vertical sides, but there will be a tendency for this cover to slip down. I will have to test how resistant to slip it will be, to understand if I need a more complex fastening method.

I marked up and glued the braces on the gray front facing cover that sits under the keyboard in the footwell. The sun went down before I could install it on the frame. In addition to this cover, I have the left side cover and the last footwell one that has the mounting challenges I described before.

After the covers, the one remaining cosmetic task is the mounting of the display pedestal to the base. From that point, mounting and wiring up the electronic components will complete the replica.

No comments:

Post a Comment