Rephrasing your question,
The same setup can send/receive data properly to FPGA in 32-bit GPIF mode and does not send/receive any data when setup in 16-bit GPIF mode. Is my understanding right?
It must be due to buffer switching, the FLAG will also be high when the DMA engine is switching to the next available buffer for the FIFO being written.This is done to avoid loss of data.
Thanks for your answer!
But If it is due to buffer switching, why data can not be sent to FPGA in 16-bit GPIF mode? Is there another factor for this phenomenon？
This is the number on the usb3014 chip which i am using, I want to know if this version of the usb3014chip could work rugularly in slavefifo 32/16-bit GPIF mode?
The PC environment is win7/XP32-bit or linux. At the same time, I do not think it is due to buffer switching, because when USB3014 sends incrementing data to FPGA, the sending-data is not correct.
It is important for me to use usb3014 in slavefifo mode.
From the previous responses my understanding was that in 32-bit mode the data is being received properly. If this is not the case, what is the type of corruption being seen, when you hook up the logic analyzer do you see FX3 sending the right data or not?
For 16-bit mode which firmware you using and what are the modifications made? What is the clock frequency being used?
thanks for your help!
The data is not correct when i use the logic analyzer to see FX3 sending data to FPGA, the pclk-clock on the usb3014 which i use is 60MHz, i think the clock is in principle.
i just use the primary firmware and do not make any modifications. Had a discussion with our guys, we are eager to know if this version chip is OK in slavefifo mode~ Is there a bug on this version chip?
These firmware and well tested and used by quite a lot of engineers at this point of time. I'm not sure as to why you're facing this issue. Please create a tech support case (MyAccount -> MyCases) so that one of engineers can look into this issue.