cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

YuRe_4727406
New Contributor

Hey guys, I'm trying to config a FPGA via SelectMap mode. And what I did is to use GPIO to emulate a 16-bit parallel IO. It works but the speed is quite slow. The problem might be caused by the multi-threading in the firmware: one thread wait for usb vendor cmd and one thread do the job (here is config the fpga from flash). The two threads have the same priority and preemption disabled with time_slice = 1 as I don't want the main thread stall when the worker thread is working. I'm glad to know if there are ways to speed up the configuration process? It can be achieved from the multi-threading side or the 16-bit parallel IO side. Here is a code snippet:

pastedImage_0.png

0 Likes
1 Solution
YashwantK_46
Moderator
Moderator

Hello.

The performance limitation is because of the bit-banged GPIO's being used for the parallel interface where the max frequency is in the order of ~500KHz (as mentioned in the KBA).

Alternatively, instead of using bit-banged GPIO's to emulate a parallel data bus, you can develop a GPIF II state machine that can be used to configure the FPGA at much higher rates and in less amount of time (according to your query).

Regards,

Yashwant

View solution in original post

0 Likes
3 Replies
YashwantK_46
Moderator
Moderator

Hello,

Please refer to the following KBA: Increasing Frequency of Bit-Banged GPIO Clock in EZ-USB® FX3™ - KBA90267

The above KBA mentions the max frequency of a GPIO is ~500KHz.

Can you please elaborate your application more so that i can better understand it?

Also, can you let me know the selectMap Implementation that you are using (have you developed a GPIF state machine to make it work)?

And as you pointed, the delay might also be due to the multi-threading implementation of your firmware as you are using time-slicing for the threads to work.

This can cause an unnecessary delay into the threads when a thread which doesn't have any data is still getting time_slice and just wasting the time and introducing a delay.


You can use the CyU3PThreadRelinquish() API to relinquish the control of a thread to a ready thread of the same priority and take back control when the previous thread has ready status.
Please refer to the FX3APIGuide.pdf from the following path: c:\program files (x86)\Cypress\EZ-USB FX3 SDK\1.3\doc\firmware\FX3APIGuide.pdf

Regards,
Yashwant

0 Likes
YashwantK_46
Moderator
Moderator

Hello.

The performance limitation is because of the bit-banged GPIO's being used for the parallel interface where the max frequency is in the order of ~500KHz (as mentioned in the KBA).

Alternatively, instead of using bit-banged GPIO's to emulate a parallel data bus, you can develop a GPIF II state machine that can be used to configure the FPGA at much higher rates and in less amount of time (according to your query).

Regards,

Yashwant

View solution in original post

0 Likes
YuRe_4727406
New Contributor

Hi, thanks for your reply. Indeed the GPIF will boost the performance but for now I can't implement it in my firmware. I managed to accelerate it by using registers

0 Likes