Usefull Application Note for FPGA downloading using GPIF: AN63620. Need HELP

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JeBo_4132831
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Hi,

We already use the GPIF solution for FPGA downloading.

We are studying an enhancement of the GPIF to work in // by 16.

The firmware has been modified accordingly.

The Bistream Size can be more or less 64 Mo. (XILINX UltraScale+ VU7P).

I've update the Visual C# 2008 project to be able to support the .BIN file of 64Mo.

The file_buffer point to the .BIN file

The file_bytes is the size of the .BIN : 53439904

As soon as i execute this  :

success = myDevice.BulkOutEndPt.XferData(ref file_buffer, ref file_bytes);

the file_bytes return Something that is not the file_bytes => All data have not been sent through the BulkOut. Why ? This is my problem ....

I tried with the original CyDLL.dll from the AN (from 2009) and with the one form 2014.

With the DLL from 2014, the file_bytes is even set to 0 !!! 0 bytes has been sent with the 64Mo file ...

Is there any limitation in terms of size using the BulkOutEndPt.XferData ?

If i use a smaller .BIN file it works.

Thanks for your help.

1 Solution
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

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.

Thanks,

Yatheesh

View solution in original post

17 Replies
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

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.

Thanks,

Yatheesh

Hi,

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 ?

0 Likes

Hello,

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

then,

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?

Thanks,

Yatheesh

Hi,

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;

Right ?

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.

Regards

0 Likes

Hello,

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.

Thanks,

Yatheesh

0 Likes

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

etc ...

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.

0 Likes

Hello,

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.

Thanks,

Yatheesh

0 Likes

Hi,

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 ...

Many Thanks.

***** 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.

0 Likes

Hello,

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.

pastedImage_0.png

Please do not use any check statements between the XferData calls

pastedImage_1.png

Thanks,

Yatheesh

0 Likes

Thanks Yatheesh.

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

for (i=0;i<16;i++)

    myDevice.BulkOutEndPt.XferData(ref buffer0, ref max_size_bytes);

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 :

pastedImage_0.png

With Decision point :

pastedImage_8.png

USB timing using 4mo Packets

pastedImage_0.png

0 Likes

Hello,

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.

Thanks,

Yatheesh

0 Likes

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 ...).

Thanks.

** 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.

0 Likes

Hello,

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.

Thanks,

Yatheesh

0 Likes

Hi,

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 ...

Thanks

0 Likes

Hello,

There is no plan to EOL the part in the next 5 years.

Thanks,

Yatheesh

0 Likes

OK Great.

Do you know if it exists  FX2LP18 low cost board like FX2LP ?

I've only seen FX2LP mini board. Or Any schematic to share ?

We imagine use a mini daughter board with FX2LP18. To connect to our FPGA.

Then in the future, a FX3 SuperSpeed Explorer Kit Low Cost board, replacing the FX2LP18 board.

We imagine doing the same connectors than current FX3 Explorer Kit.

0 Likes

Hello,

We do not have any development boards for FX2LP18.

Thanks,

Yatheesh

0 Likes