- Please confirm that you are using the default firmware and GPIF state machine from the application not AN65974 https://www.cypress.com/documentation/application-notes/an65974-designing-ez-usb-fx3-slave-fifo-interface or is it some custom firmware.
- Please let me know how much data is being sent from the USB side to FX3 and the DMA size used in the firmware.
- To check the PROD and CONS events, register for both events and track the PROD and CONS events in the DMA callback. You can use debug prints.
- What is the initial state of the flags i.e. just after programming FX3 with firmware and not transferring data. Please share the traces.
If the firmware or GPIF state machine is custom one. Please share the DMA configuration and GPIF state machine files.
- Yes, I am using that example with the Default GPIF state machine. The only difference is that the clock of the Zedboard is already working at 100MHz so I do not need to use the clock wizard. However, it should not affect to the DMA flags.
- I am transferring 1024 bytes of data. I have used cyusb tool and also my own libusb library that has been tested successfully with other examples.
- I have not done that I will check the events. However, the default firmware prints the number of buffers received and transferred. When I send the buffer the Cypress increased that counter so buffers are received from PC to Fx3.
- Regarding the initial state, it is the one that I showed in the picture. Tha FLAG A starts at high value after programming and even with a do some transfer, any of the other FLAGS change their value. I checked the system by programming the signal as GPIO to verify that the constraints file was ok.
I attached you in this answer the Vivado project sources.
Slave-FIFO-ZEDBOARD.zip 11.1 K
From the attachment, you are using the same verilog file shared with the application note. And from the previous response, i understand that the data transfer is from USB to FPGA through FX3. Is that right?
If the data transfer is from USB to FPGA through FX3:
In the verilog code (Path: ..\001-65974_AN65974 (3)\AN65974\FPGA Source files\fx3_slaveFIFO2b_xilinx\rtl_verilog\slaveFIFO2b)
- this is the top module slaveFIFO2b_fpga_top.v which has the input mode_p, based on the switched on the SPARTAN 6 board
According to the status of these switches (on the SPARTAN 6 board) or the value of mode_p the FPGA transfer modes are switched and appropriate module is instantiated.
So, the verilog coed need to be modified such that
next_fpga_master_mode = fpga_master_mode_stream_out;
and stream_out module instantiation is done
STREAM_OUT transfer mode allows full packets to be transferred fro USB to FPGA i.e. for USB 2.0 packet size will be 512 bytes and for USB 3.0 packet size will be 1024 bytes. So please try sending full packet data after modifications to verilog code.
- Also, refer to this thread FX3-FPGA and confirm that CLK is fed correctly to the FX3 PCLK pin.
Thanks for your help.
Regarding the modes, I set the modes to the switches of the Zedboard, so there is no problem with that. Regarding the pclk, I think it is well generated but I will check with an oscilloscope to make sure the clock is being generated. I will let you know when I checked that.
I have one question, there are two reset signals in the Verilog code. However the GPIF documentation, only appears one that is connected to the GPIO 59, where should be the output reset be connected to. I guess it does not care since its value is always 1 and I think it is connected to the RESET of the Fx3 that is handled by a button. If you can tell me where those lines are connected to, it would help me a lot.
In the verilog code (AN65974), there is only one reset_in pin(input to FPGA), which is assigned as follows
The reset2pll is fed to the pll for clock generation and lock is the output of that module which is used as reset_ in the entire code
So, we can say there is only one reset signal which is input to FPGA. On the other hand GPIO 59 is used as output from FX3
When the application starts (i.e. after proper enumeration) the RESET signal (GPIO 59) is driven from the firmware. The initial value of the reset is HIGH.
Please let me know if any queries on this