Debugging the resilient high speed link between fpga boards
After adjusting the timeout logic quite a few times, I came to the conclusion that the link was most reliable with no timeout at all. That is, the slave automatically resets when the master drops the select line and the master will resync automatically to a dropped slave. A dropped slave may trigger an unrecoverable SECDED error, but then recover immediately; in most cases, it recovers without an error.
The highest I could get my error count, with repeated power cycling of both master and slave, was to 2 retries. The link is rock solid without timeouts and I can confidently move on to hooking many physical peripherals by using high speed links and slave FPGA boards. I will begin testing the 1627 plotter functionality over the link tomorrow.
Implementing virtual 1403 printer
I worked through the logic necessary for handling the shadowing of the virtual carriage control tape between the PC program and the fpga logic. I have one very minor tweak to make in the fpga and then some coding for the Python program.
The fpga is directly interrogating the virtual carriage control tape buffer memory when the program issues an XIO Write (skip to one/more channels on the tape). Thus, my fpga takes the correct amount of time at a rate of 16ms per line skipped then interrupts the processor with the movement completion status.
Meanwhile, the Python program sees that XIO Write command and can independently look through its copy of the virtual carriage control tape, figuring out the new line number. It will insert blank lines in the output file for every line skipped. An XIO Control is a space command, writing out an end of line character.
Meanwhile, when the line itself is printed by the program issuing XIO Init Write, the Python program sees the command, fetches the data words from core memory using cycle steal transactions, then issues a 'get special data' transaction to tell the fpga to interrupt the processor with a transfer complete status. The fpga will continue for 200ms before interrupting again with the print complete status.
I have almost everything constructed on both sides and can move on to the debugging of it all. The remaining part is the logic to open a virtual carriage control tape file on the PC, which will load the tape buffer by 'write special data' transactions so that both fpga logic and Python have the same tape loaded. I will also set up a default tape with channel 1 at the first line, channel 9 and 12 at the 66th line, and the other channels punched at various places.
If a channel has no hole punched in any line, then the real 1403 printer would 'run away', spewing paper continuously out of the printer as it looked in vain for a punched hole to stop the motion. Putting a hole somewhere for every channel protects against that error case.
If a channel has no hole punched in any line, then the real 1403 printer would 'run away', spewing paper continuously out of the printer as it looked in vain for a punched hole to stop the motion. Putting a hole somewhere for every channel protects against that error case.
No comments:
Post a Comment