Home
Welcome to the ECP5_BGA381_FT2232HQ_FIFO wiki!
The first step in the bring up process is to program the EEPROM of the FT2232HQ to enable synchronous FIFO operation on startup. This can be done by using the FTDI provided utilities: FT_PROG or MProg. I used FT_PROG, the older of the two. Note that you will need a Windows machine to run FT_PROG as it is the only platform supported for FT_Prog (and the newer MProg alternative). I did my bring-up on Linux and I was able to modify the EEPROM/write example in the D2XX Driver download archive and successfully program the EEPROM. The essential settings to set in FT_PROG are as follows:
- Enable the Bus power operation with current up to the maximum of 500mA.
- Set Port A and Port B in '245 FIFO' mode.
- Set the Driver for Port A and Port B to D2XX.
Once all these settings are correctly set, press the EEPROM program button. You can find all the details of using FT_PROG in the FTDI User Guide for FT_PROG.
The next step is to program the FPGA with the basic loopback Verilog code. This code simply loops back each byte received from the FT2232 in the most basic way. The Verilog code is in the /hdl_loopback directory. Here are the steps to follow:
- Download the open source oss-cad-suite 0.1.0, unpack it into a folder say "/home/gil/tools-oss-cad-suite-0.1.0/".
- Edit fpga.sh to update the TOOLS_PATH script variable to point to the oss-cad-tools directory:
TOOLS_PATH="/home/gil/tools-oss-cad-suite-0.1.0"
- Run ./fpga.sh. Depending on how permissions are set on your machine you may have to enter your root password so that the openFPGALoader can write the bitstream to the FPGA RAM. The successful outcome looks like this:
Jtag probe limited to 3MHz
Jtag frequency : requested 6000000Hz -> real 3000000Hz
ret 0
Open file: DONE
b3bdffff
Parse file: DONE
Enable configuration: DONE
SRAM erase: DONE
Loading: [==================================================] 100.00%
Done
Disable configuration: DONE
The hardware uses a green LED to indicate that the ECP5 bitstream was successfully written to the FPGA SRAM.
The instructions for setting up the FTDI D2XX Drivers are included in the D2XX Driver download for your specific platform. I followed the instructions for Linux and MacOSX and the drivers installed without any problems.
Note that the driver download contains source code for sample apps. I built the samples and as I mentioned earlier I used the EEPROM/read and EEPROM/write examples to test if I can read and write the EEPROM. The reason this was useful to me is that when I used FT_Prog in Windows I changed the Vendor ID in EEPROM and after that FT_Prog no longer discovered my FT2232 device (which is expected). The simple solution was to modify the EEPROM/write example by adding a call to FT_SetVIDPID with my new Vendor ID and Product ID so that FT_Open would work, then and setting the EEPROM fields (including VID and PID) to whatever values my application required. After successfully writing the EEPROM I got back to the default VID and PID.
In the host_loopback directory type make:
> make
cc main_loopback.c -o ft2232 -Wall -Wextra -lftd2xx -lpthread -lrt -Wl,-rpath /usr/local/lib -L/usr/local/lib
Finally run the app with ./run.sh.
> ./run.sh -c 64000 -p 128
Send bytes: 64000, packet bytes: 128
Done sending 64000 bytes
==== Test successful ====
The reason I am using a script to run the host app is the two lines before the ft2232 command line (see run.sh):
sudo rmmod ftdi_sio
sudo rmmod usbserial
This eliminates the conflict between the D2XX drivers and the FTDI sio driver.
Optionally you can test the loopback Verilog code, without the host code by using the Verilog code available for simulation in sim_ft22232.sv. To run the loopback simulation use sim.sh.
> ./sim.sh -p 8
0INIT: Clock period 40690(ps).
20345 CORE: -- STATE_RESET_BEGIN
20345 FT_FIFO: -- Reset.
20345 FT2232: -- Reset.
427245 CORE: -- STATE_RESET_END
427245 FT2232: ---> Sending: 0.
458315 FT_FIFO: [STATE_RD] Read: 0.
474981 FT2232: ---> Sending: 1.
491647 FT_FIFO: [STATE_WR] Wrote: 0.
508313 FT2232: <--- Received: 0.
524979 FT_FIFO: [STATE_RD] Read: 1.
541645 FT2232: ---> Sending: 2.
558311 FT_FIFO: [STATE_WR] Wrote: 1.
574977 FT2232: <--- Received: 1.
591643 FT_FIFO: [STATE_RD] Read: 2.
608309 FT2232: ---> Sending: 3.
624975 FT_FIFO: [STATE_WR] Wrote: 2.
641641 FT2232: <--- Received: 2.
658307 FT_FIFO: [STATE_RD] Read: 3.
674973 FT2232: ---> Sending: 4.
691639 FT_FIFO: [STATE_WR] Wrote: 3.
708305 FT2232: <--- Received: 3.
724971 FT_FIFO: [STATE_RD] Read: 4.
741637 FT2232: ---> Sending: 5.
758303 FT_FIFO: [STATE_WR] Wrote: 4.
774969 FT2232: <--- Received: 4.
791635 FT_FIFO: [STATE_RD] Read: 5.
808301 FT2232: ---> Sending: 6.
824967 FT_FIFO: [STATE_WR] Wrote: 5.
841633 FT2232: <--- Received: 5.
858299 FT_FIFO: [STATE_RD] Read: 6.
874965 FT2232: ---> Sending: 7.
874965 FT2232: Done sending.
891631 FT_FIFO: [STATE_WR] Wrote: 6.
908297 FT2232: <--- Received: 6.
924963 FT_FIFO: [STATE_RD] Read: 7.
958295 FT_FIFO: [STATE_WR] Wrote: 7.
974961 FT2232: <--- Received: 7.
974961 FT2232: ==== Test successful. Received 8 bytes.
That's it! The hardware verified and the host and FPGA code is tested in loopback mode.
One thing I did not do yet is to write the bitstream to the EEPROM. At this time the bitstream is written to the FPGA SRAM and therefore after powering the board down I will have to write the bitstream again after powering up next time. I still make many changes to the Verilog code and therefore writing to EEPROM is not useful at this time. I will do that in a later stage of the project.
Writing the loopback Verilog code mentioned in the Bring-up section was useful but the goal of the project is to provide Verilog code for interfacing to the FT2232 over the synchronous FIFO interface. Two asynchronous FIFOs are used by an application to send and receive data to and from the host allowing the application to operate at clock different than 60MHz which is what the FT2232 synchronous FIFO is operating at. The following diagram shows the software architecture with its most important blocks.
The code host and the HDL code implement three tests: TEST 0: The host sends frames to the FPGA. TEST 1: The host sends frames to the FPGA and the FPGA sends frames back to the host each containing one byte received. TEST 2: The FPGA sends frames to the host.
A frame has a one byte header: two bits represent the command type and six bits represent the number of bytes following the header. The maximum size of the payload is 63 bytes. For the purpose of my app this was sufficient. For all tests the size of the frame can be configured from 1 to 63 bytes. The number of frames sent can be configured from 1 to 255.
The commands sent by the host C code are as follows: The command CMD_HOST_START is sent with a payload of 3 bytes:
- The test to run (from 0 to 2)
- The size of frame payload
- The number of frames sent
CMD_HOST_DATA is sent with the payload specified by a command line parameter.
CMD_HOST_STOP has no payload and it is used by the host when it completes the test.
The commands sent by the FPGA are as follows:
CMD_FPGA_DATA is sent with a payload of bytes representing data originating at the FPGA. The data consists of monotonically increasing byte values (that persists across multiple CMD_FPGA_DATA commands).
CMD_FPGA_LOOPBACK is used to loop back data received by the FPGA with a payload of one byte.
Finally CMD_FPGA_STOPPED is always sent by the FPGA at the end of a test. This command can be sent in response to CMD_HOST_STOP (for test 0 and 1) or when the FPGA is done sending all the data it needed to sent (test 2).
The host sends CMD_HOST_START [test 0, number of payload bytes per frame, number of frames]. The host sends CMD_HOST_DATA commands with the number of payload bytes specified by CMD_HOST_START. It sends a number of such frames equal to the number of frames specified in CMD_HOST_START. The host sends CMD_HOST_STOP to which the FPGA responds with CMD_FPGA_STOPPED [error code]. If there is no error, the error code is 0. CMD_FPGA_STOPPED may be sent at any time by the FPGA if an error is detected during the test. For example if the FPGA receives a CMD_HOST_DATA command with a payload that does not match the one specified in the CMD_HOST_START, it will send an error code as well as the payload it received. The error codes are defined in test_definitions.svh.
The host sends CMD_HOST_START [test 1, number of payload bytes per frame, number of frames]. The host sends CMD_HOST_DATA commands with the number of payload bytes specified by CMD_HOST_START. It sends a number of such frames equal to the number of frames specified in CMD_HOST_START. The FPGA sends back a CMD_FPGA_DATA frame with a payload of one for each payload byte received from the host. The host sends CMD_HOST_STOP to which the FPGA responds with CMD_FPGA_STOPPED [error code]. Again, CMD_FPGA_STOPPED may be sent at any time by the FPGA if an error is detected during the test.
The host sends CMD_HOST_START [test 2, number of payload bytes per frame, number of frames] telling the FPGA to send the specified number of frames each with the specified number of payload bytes. The FPGA sends CMD_FPGA_DATA commands per the host request. The FPGA sends CMD_FPGA_STOPPED indicating to the host that it is done sending data.
To be continued...