1 of 1 people found this helpful
The maximum URB size that can be created for a bulk transfer for a High Speed Device is 4MB i.e. the XferData length can be a maximum of 4MB. Please refer to this doc from Microsoft: USB Bandwidth Allocation - Windows drivers | Microsoft Docs
If the the length parameter of the XferData for high speed device is more than 4MB the API will fail returning a INVALID PARAMETER.
If your Bistream size is exceeding 4MB, then you need to split the Bistream into smaller chunks, of size less than or equal to 4MB on the host side and then send the chunks one after the other through continuous XferData calls.
I've tried this but seems not working I'll try again.
Perhaps, can i try to use instead the USB Control Center to send a file directly ? Or the same 4Mo size exists in this application also ?
Another interrogation i've is what about the GPIF flow. Is it interrupted due to 4mo packet Size ?
Or it will be "invisible" onto GPIF outputs ?
Actually, i uses the GPIF at its maximun truput of 96 Mo/s. The GPIF send 16 bits each CPU cycle. The IFCLK is sent in // to the FPGA.
Using this method i need to sent the bitstream in one flow, without being interrupted. I.E i need to have the 16 bits sent onto GPIF datas VALID (coming from EP Buffer) at each cycle !
It is possible ? Even with 4 Mo packet Size ?
1 of 1 people found this helpful
Please make sure the length of the bit file it set in the firmware (TD_Poll), GPIFTCBx register should be assigned the length value.
For example if your bit file is 64 MB (67,108,864 Bytes) => 0x4000000
GPIFTCB3 = 0x04;
GPIFTCB2 = 0x00;
GPIFTCB1 = 0x00;
GPIFTCB0 = 0x00;
Please make sure that this is configured .
The control center makes use of a single Xferdata() call for file transfers. Hence you cannot send a file greater than 4MB through the control center.
In you custom host application please make sure you are splitting the .bin file properly, please split the file in chunks which is a multiple of 512/1024 as per the EP2 buffer size. The XferData() call for each chunk should be given the exact length value, including the last chunk.
If the last chunk size is just 64 bytes, the len parameter in the last XferData() call should have 64.
Please let me know what error are you facing when you are splitting the file and transferring?
In my case, i'm using the GPIF in 16 bits format (WORDWIDE = 1). So i need to set only HALF of the size in bytes ?
I want to send 32Mega - Word (Word being 16bits here).
GPIFTCB3 = 0x02;
GPIFTCB2 = 0x00;
GPIFTCB1 = 0x00;
GPIFTCB0 = 0x00;
And i'm afraid also that i cannot use the GPIG at its maximum "truput" of 96 Mbytes/s due to the split of 4mo.
AS i said, for XILINX configuration in Slave SelecMAP the CLK (IFCLK) and the DATA_BUS (GPIG Bus) MUST be sent in a continuous way. Each Word being a Word of the BIN FILE.
WHat i seen is between the 4Mbytes transaction is a kind of pause of the GPIF (i imagine this is a pause ...), where the IFCLK is toggling and the DATA_BUS is fixed onto the last FIFO EP.
Is there any software solution to avoid this latency ? (between the 2 BULK transfers).
The only solution i see my side is firmware side : Change my GPIF to reduce the truput to 48MHZ (2 cycles by DATA) and using a CK_EN signal for validating the IFCLK. During "pause" the CK_EN will be 0 for instance, then the FPGA will not "see" the word onto the DATA_BUS.
Yes, your understanding is correct. The GPIFTCBx register will count the number of transactions. If the GPIF data bus width is 16-bit then the GPIFTCBx register should hold the number of WORDs to be sent.
Please refer to section "10.4.3.1 Transaction Counter" in the EZ-USB Technical Reference Manual.
When the data is being written from the FX2LP to the FPGA through GPIF, the CSI_B pin will asserted. The CSI_B signal is monitored on the FPGA side and the data is sampled when the signal is asserted (low). The pin is configured in the GPIF Designer. The delay between two XferData call should not be a problem here because in-between the calls no data is written to the FPGA.
Care must be taken to ensure that each data buffer should be filled with data.
OK thanks for the GPIF buffer size.
If i do not want to use the CS_B (the CLK_EN) => to accelerate the FPGA downloading
The IFCLK will be sent each cyle with a DATA from the FIFO EP2 buffer. I can reach 96Mo/s. Then my FPGA is loaded in less than 600ms.
If i use the CS_B it will double the dpownloading time. Even if it not a big trouble i want to see the best i can do.
THis is to see if we will use FX2 or if we need FX3 ...
Concerning the continuous data_flow over the GPIF DATA_BUS is it possible ?
I.e could i send 64Mbytes (=32 Mwords) of DATA using Maximun 4Mo packets size (or less ?), without any "pause" in the DATA_BUS flow.
This is my first interrogation.
Concerning the software (HOST) side : We are agree that i need to do the a kind of loop, dividng my priginal .BIN file into MAX 4Mbytes packet SIZE (Here max_file_words is 0x200000.)
myDevice.BulkOutEndPt.XferData(ref file_buffer0, ref max_file_words); //check if transfer successfull
myDevice.BulkOutEndPt.XferData(ref file_buffer1, ref max_file_words); //check if transfer successfull
myDevice.BulkOutEndPt.XferData(ref file_buffer2, ref max_file_words); //check if transfer successfull
Sorry, for all theses questions, but the FX2 is quite new for me. (less than 2 weeks ... ).
Note that i wll use the FX2LP18 for 1.8V onto my future board. But GPIF will ne the same onto it.
Since your .bin file is greater than 4MB, you will need to use multiple URBs i.e. multiple USB transfers (Xferdata) from the host side and delay will be present between the URBs depending on the host controller and the host application.
The delay can be minimized using threads in your host application. Here you will need to remove/minimize the return status check (delay between calls) in the application.
Please try implementing a new thread for streaming the .bin file and call the thread when the transfer starts.
Hope this works.
Could you parhaps indicate me what are the MUST i have to do both onto software side and Firmware side to be sure that in GPIF mode i can send 64 Mo wihtout any "pause" between the Xferdata...
I've understood the need of a dedicated threads but in terms of all configurations, i need help.
Quad Buffering in firmware ? XferSize ? PackSize ? Etc ...
***** UPDATE *****
After many tests, changing the number of byte to send, the packesize used in XferData, the GPIF config , my issue is in the GPIF Waveform.
In my case i tried to use the TCExpire Flag to roll over the state ... but i think that in my case i can't !! (due to the fact that i'm over 4mo of data .... ?).
Between the 4mo packet the GPIF FSM continue to RUN (Flag Txpire is not set). And This is not what i want.
By using Ready FLAG instead... (set to Empty Flag in GPIF_INIT.c using the EP2GPIFFLGSEL register) it works NOW !!!.
64Mo sent in less than 4 seconds ... It is not as best as expected but not so bad.
I've optimized GPIF waveform. CS_N is 0 during all GPIF Exchange State and 1 in IDlE. Like this there is only one FX2 cycle for 16 bits.
I cannot do more. Now the time lost is between the Xferdata i think.
Please use quad buffering and 512 byte Endpoint size.
in the Xferdata, make use of the maximum URB size that can be created i.e. 4MB (4096).
to monitor the delay between the URBs please use a hardware analyzer between PC and FX2LP or a software analyzer like Wireshark USBPcap.
I have tried this on my side and I see ~(0.2 to 2) ms gap between two IRPs (URB transfers) when sending the data in different XferData calls which may still be undesirable for your application. Please try in on your side. If this is not desirable for your application, you will need to use a flow control on FX2LP->FPGA through the CSI_B pin to indicate the availability of data.
The highlighted ones are the IRP sent from the host to device.
Please do not use any check statements between the XferData calls
Mine is 16 loops of 4mo of data to reach the 64mo :
buffer0 is a 4 Mo Buffer containing 4 Mo of the bin file.
max_size_bytes = 1024 x 1024 x 4 ; 4 Mo
myDevice.BulkOutEndPt.XferData(ref buffer0, ref max_size_bytes);
A snapshot of what i saw is at the end.
A total of ~4s for the 64Mo. Quite Good !!!
This is my GPIF State Machine to go as fast as possible :
With Decision point :
USB timing using 4mo Packets
When using the transaction counter i.e. GPIFTCBx register to hold the number of transactions to be made the the GPIF state machine should branch to the idle state after every transaction.
I see that this is not being met in your GPIF state machine/waveform.
The status of the FIFO flags will be automatically handled by the GPIF state machine.
Please go though the Section "10.4.3.1 Transaction Counter " in the EZ-USB Technical Reference Manual for a clear understanding.
The GPIF state machine should go to Idle state unconditionally after every transaction. Use the state machine in the Application note AN63620 as it is.
OK i see.
So why there is the possibility to test the TXexpire flag Inside the GPIF Decision state machine ?
This is non sense .?.?
I think my solution works (and is faster than going to the IDLE state each FIFO DATA ... - GPIF lost its interest no ?).
I wll try more test to see if i've exactly the good number of CS_N.
Note that you said XferData is limted to 4mo : But 4mo is 4 x 1024 x 1000 OR 4 x 1024 x 1024 ... It dépends on the NORM used (before or after 1998 ...).
** UPDATE **
Using the CY3684 official Kit, i can see the exact numbers of CSN_N with IFCLK rising edge (and associated DATA).
The Proof of concept is done.
With FX2 The Complete 64 Mo is sent in 1.5 s.
LAST QUESTION : Is the FX2LP18 will be continued in the coming years ? Or will it be stopped for FX3 ?
In all case, thanks for your help.
FX2LP will be in production and its EOL/EOS is not planned anytime soon.
The Maximum URB that can be created for an High Speed device is 4MB i.e. 4 x 1024 X 1024 you can verify this using the Wireshark application.
An important thing to be noted, you can use the XferData to transfer more than 4MB data, for example try 8*1024*1024 bytes. The URBs will be created for 4MB (4*1024*1024).
It is not recommended to use XferData length more than 4 MB as it is dependent on the host controller driver and may fail.
Please refer to this KBA: Maximum Value of xferdata() Length Parameter - KBA84124
For in transfers you can use the packet mode: XferData Fails when Large Amount of Data is Requested - KBA215067
In the application note the GPIF transaction counter is implemented so as to decrement it on every branch to Idle state, the Application note follows the recommendation from the Technical reference manual.
In you case the transaction counter is decremented on every IFCLK, when the FIFO pointer is incremented i.e. the next data is placed on the line in S1 state and hence the transaction counter is decremented. Notice that the color of the data line has been changed in your GPIF waveform design.
Can you détails the "FX2LP will be in production and its EOL/EOS is not planned anytime soon" ?
Is there any gurantee before FX2 END OF LIFE ?
If we choose the FX2LP18 we need to have it for 10 Years ...