0

How can one transfer data from PC to FPGA and read back result for test purpose where the data must not get corrupted i.e resend if data integrity was lost or use some other error recovery mechanism. The method must be simple to implement so it does not become a whole project on its own.

This scenario can occur where several kB or few MB of data has to be transferred into a digital design to aid in testing. An example is testing of image processing design.

It is true that using the UART is a very simple solution to such a problem. However, UART does not have elaborate error detection and correction mechanism except the parity bit.

One method could to be create a simple mechanism on top of UART where data is transferred in blocks along with CRC bytes. The receiver end can then send an ACK or NAK and the sender will try again if NAK received. Since the data does not need to be transferred in real-time, this could be a satisfactory solution to this problem. Is there something else that I should look into so as not to reinvent the wheel?

My focus is Intel FPGAs for this question but it would be great if this could work with Microsemi FPGAs as well.

gyuunyuu
  • 1,933
  • 7
  • 31
  • Creating a protocol with error checking on top of serial is a very standard way (one of) to approach this. Could be slow though for transferring MBs of data. – Eugene Sh. Feb 22 '21 at 20:47
  • Actually I would just go with the UART. However, since it does not have CRC inside it, it is not enough. Also, the data will be a few MBs or a couple of 10s of MB at most. – gyuunyuu Feb 22 '21 at 21:09
  • Well, plain UART is not useful for virtually anything. You need something on top of it. You can take a look at my old question (more of overview): https://electronics.stackexchange.com/questions/186254/serial-protocol-delimiting-synchronization-techniques – Eugene Sh. Feb 22 '21 at 21:15
  • You also want "simple to implement". UART fits this requirement. – Elliot Alderson Feb 22 '21 at 22:42
  • Yes of course. Is there a "ready made" solution for this type of scenario that you may be aware of which also has faster data rates. The answer from bobflux is interesting but I need to look into it in detail. – gyuunyuu Feb 23 '21 at 09:47
  • SPI is easier than UART and also faster. – Dave Tweed Feb 23 '21 at 11:26
  • CRC on the actual serial bits is really cheap in an FPGA, you can implement the polynomial directly, at the cost of one lookup table per four nonzero terms, and the only other resources you need are registers to store the current state. CRC16 would use 18 LE that way, plus whatever logic you need for the output. – Simon Richter Feb 23 '21 at 12:57
  • You are right that CRC generation and checking is simple. However, on the FPGA and also the PC side, we need something that will wait for CRC OK signal before transmitting the next block of data and retransmit the old block of data if CRC was not ok. On the receiving side, there must be capability to discard a block of data if CRC did not match and wait for it to be retransmitted. – gyuunyuu Feb 23 '21 at 14:59

1 Answers1

3

Last time I did this, it was a while ago, I used a Cypress FX2LP USB micro. It has a FIFO interface which is very FPGA friendly, and on the USB side it uses bulk transfers.

No issues maxing out USB2 bulk bandwidth with python/libusb.

Pros: 480 Mbps is great if you need it, bulk USB does the error correction, and the chip is not difficult to use. python/libusb on the PC side is quite simple.

Cons: more complicated than UART, uses more pins than a simple serial or SPI connection. So if you have a FPGA already on a board, and you don't have enough available pins, then it won't work.

I hear FTDI also makes some user-friendly USB FIFO chips. They even sell ready-made cables that will do 30 Mbps SPI, so that could be a nice solution with a low pin count to interface with a SPI core in your FPGA.

bobflux
  • 70,433
  • 3
  • 83
  • 203