Sunday, March 6, 2016

Fine tuning the resilient high speed fpga 2 fpga link, plus implementing virtual 1403 printer function


Debugging the resilient high speed link between fpga boards

There were a couple of minor issues with the way that the link started and restarted, having to synchronize among six FSMs split between two boards, but eventually I got it starting and recovering well. I had a counter displayed on the LEDs of the slave board to show me how many recoveries had taken place since power-up.

The link is up and running. randomly dropping either side is handled well, with immediate resync. So far I have only seen one unrecoverable hamming crc error on the slave side, which is harmless at a very low rate.

I began experimenting with timeout values - when too short, the slave would flicker an LED to show restarts forced by the master when it waited too long for the return transaction. It is slow going with a 30 minute change-synthesize-test cycle time, but if I simply put in a very long timeout then it will increase the potential delay on signal changes being sent between the boards. Some very fast peripherals might be impacted by excessive delays. Also, it is more elegant to get a close to optimum value which wastes little more than the bare minimum.

Implementing virtual 1403 printer

The first steps in implementing the virtual printer functionality were to put in the print line and carriage control tape buffer memories, with their associated logic to fetch and store respectively.

Next I set up all the FSMs to handle the simulation of printing and carriage movement. At this point I think I have all the fpga side logic complete, but I may need to add something to the carriage control tape logic once I finalize the Python side and begin testing.

No comments:

Post a Comment