SPI link operating at 12MHz, 2501 reader function getting more solid

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Final debugging of virtual 2501 card reader function

I was still puzzled by inconsistent behavior - I have set some indicators that prove that I fire off the upddevtrigger signal because an FSM is cycled as a result and the FSM condition is detected. However, a simple process to flip on an output signal if that trigger signal is every on fails to flip on. Same global clock, but it might be a sync issue of some sort since the trigger signal is just one cycle in duration.

However, since I know that my FSM is triggering, I had to dive deeper into the logic there. I realized that I am coding VHDL that should be synthesizable correctly but it seems to me that it is not happening as I expected. I tested this by changing the expression of the logic to a different method more certain to be correctly synthesized, then retested.

This worked, ensuring that the state of the DSW, as stored in the UCW, was updated by the transaction from the PC program. Now I had to work through and replace any expressions in my fpga logic that were similar to the improperly synthesized logic I had debugged.

I found a clue, in that resetting the operation complete state of the card reader from one area of the Python code worked while another section did not. This helped me get to the bottom of the issue. The limited time for testing in the evening was over, leaving further progress for tomorrow

Debugging of high speed SPI link to slave board

I made a tweak to the startup and my SPI link is moving data between the two boards. My display logic for the indicators on the slave needs a bit of tweaking then I can work on increasing the link speed. The change was made and my scope attached to watch signal quality as I ratchet up the link speed a bit.

At 500KHz, I can see mild ringing just at the edges of the clock, but a nice clean signal otherwise. With the speed ramped up to 1MHz, the parity error checker spots bad frames, which wipes out some of the advantage of the speedup.

However, I didn't create clean twisted pairs or good impedance matching, which would sharply reduce the error rate. The initial wiring is flat cable into mismatched impedance inputs on the slave board. For testing purposes I will drop back to 500KHz, with speedup to full rate a later task.

I did jack up the rate to 4.8MHz once I had the parity checking logic in place to ignore any frames with errors. I found that certain inputs from the slave - sw7, btn0, btn1 and btn2 - would introduce solid parity errors at the high rate, while any of the other signals or combinations did not induce errors. This corresponded to signals 7, 8, 9 and 10, which is a clue I will use to see why these suffer the problems.

Interestingly, the spurious parity errors went away when I jacked the SPI link up to 12MHz, until after a while I got it to lock up pretty solidly when activating any of the switches/buttons. That meant the problem is loss of synchronization when I send a never-ending sequence of 128 bit words over the link. I think I can fix this by pausing and dropping the select, although that will lower the net data rate.