I have an FTDI chip (reference manual here) that translates USB from a PC to an SPI channel connected to an FPGA. I would like to test that the communication path between the PC and the FPGA is functional.

Probably the easiest approach would be to have a loopback test of some sort between the PC and the FPGA, where the PC drives the test, and the FPGA reflects all it receives.

The FTDI chip comes with a C API for SPI communication (example available here). On the FPGA side, I want to have to write minimal Verilog.

What would be the easiest loopback test I could have on the FPGA side that is compatible with this SPI API?

  • \$\begingroup\$ I am also doing almost exactly the same this. Could you please share how exactly you proceeded? \$\endgroup\$ – gpuguy May 6 '13 at 12:08

Note: Question can be interpreted as a design problem, I'm addressing it as such.

If you want to test the FTDI chip I would leave out the FPGA. If you use that you'll be testing two things at once, and not know where the error is in case it shouldn't work.

The loopback is a good idea, but I would go directly from FTDI output to its input, and connect a scope or logic analyzer to that. SPI is very easy to recognize and decode directly from the screen. Send a byte, check on the scope/logic analyzer, and see if you get the byte back.

Once the FTDI is OK'd you can go on to the next step, the SPI implementation on the FPGA.

For a production test you could also use a loopback. Your FPGA has the SPI implemented, and its shift register acts as a delay. Have the PC send a specific byte, that will shift in the SPI shift register. Then let the PC send another byte, and it will get back the previous one (assuming you have an 8-bit shift register. IIRC the NXP Cortex controllers have a 16-bit SPI). That doesn't require any extra test logic in the FPGA.

This allows you to get a good/bad check for the complete loop, but you don't have any information where the error is in case the test fails. Therefore I would let the FPGA compare the first received byte with the expected value, and output a good/bad bit which then can be read by the test jig. Then in case of error at least you know whether the path from PC to FPGA is OK or not.

  • \$\begingroup\$ This is for a production test, so automated testing (without a scope) is better. Also, I'm interested in the link between the FPGA and the FTDI chip. (I.e. check if any of the pins are faulty.) \$\endgroup\$ – Randomblue Jun 7 '12 at 17:05
  • \$\begingroup\$ @RandomBlue - I edited the focus of my answer. Sorry for the misunderstanding. \$\endgroup\$ – stevenvh Jun 7 '12 at 17:13
  • \$\begingroup\$ There is a project FTCJTAG dll on FTDI site. Once I have it built and used with USB, FTDI, C#, C++, JTAG target. If SPI is not enough and FPGA supports JTAG then try this project. \$\endgroup\$ – user924 Jun 8 '12 at 0:19

ok for the FPGA you will need to write/create/obtain an SPI module. With a suitable SPI module you might be able to loop the output to input but likely to require some sort of buffer to store the data. The reason for this by the time the first bit of the input byte is received you will of already tried to transmit the first byte of the response.

So you will will need some buffers and logic to interface to the SPI module to receive the byte, buffer it, and send it back to the SPI module for retransmission.

On the PC side some sort of terminal programme to interface to the virtual serial port that the FTDI will install. Tera term is good for that.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.