Accelerate the speed of GPIO emulated parrallel IO

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

cross mob
YuRe_4727406
Level 1
Level 1
Welcome!

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
Moderator
100 solutions authored 50 solutions authored 50 likes received

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
Moderator
100 solutions authored 50 solutions authored 50 likes received

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
Moderator
100 solutions authored 50 solutions authored 50 likes received

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

0 Likes

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