Hello,

  I have a board with an FX3 connected to an FPGA where the GPIF is the synchronous master mode. I am not planning on using any address lines so I'm kind of confused about how to use threads and sockets. My main goal is to read several USB3 packets worth of data at a time from the GPIF using IN_DATA and send them over USB. Is it alright if I only use one thread, and one consumer and one producer socket? Is there an advantage to use more threads and sockets?

Looking at the slfifosync example, I see that PIB_SOCKET_0 was selected as the producer and PIB_SOCKET_3 was selected as the consumer. I'm actually pretty uncertain about threads and sockets, even though I've read all of the documentation in the FX3API guide, watched the video tutorials, and read the appnotes.

What exactly are DMA threads? Are these the same threads that are created by the C API function, CyU3PThreadCreate()? When would you use multiple threads and why? And when would you use multiple sockets and why?

What physical meaning do these thread and socket numbers have, do they come from what is placed on the bus during an IN_ADDR action?

The threads that we are talking about on the GPIF II side of FX3 are not same as the threads that you create in software.

They are not software threads. This terminoligy might be confusing a bit. But they are hardware threads specific to FX3.

Is it alright if I only use one thread, and one consumer and one producer socket? Is there an advantage to use more threads and sockets?

Yes. You can go ahead with one consumer and one producer socket. In this case you will be using a single thread for data transfer.

You will be creating a DMA channel (using DMA channel create API) between these sockets (one consumer and one producer). There will be some buffer allocated to that channel to do data transfers.

Let say you have created a buffer  of total 64KB (each buffer is 16KB, count - 4). GPIF II side socket is continuously filling this buffer and it filled the initial 16KB of buffer completely. Then it will switch to next 16KB buffer. This switching requires some time.  The point to note here is that there is some latency. It may have some effect on your throughput.

Let say you want to optimize it for better throughput. Then it is better to have multiple threads. when you are using two threads then it will create a total of 64KB for each thread. GPIF II side socket is continuously filling this buffer and it filled the initial 16KB buffer of thread 0 completely. Then you can switch to Thread 1 and start filling the 1st buffer of thread 1. There is no latency in switching the threads. In this way, you can avoid the buffer switching delay using multiple threads.

Please refer to the attached document for more clear information regarding the same.

Thanks,

sai kirshna.

 Ah awesome, that cleared up a lot for me!

So the DMA threads are basically GPIF DMA channels? So with a total of 4 separate channels I can conceiably double buffer IN as well as OUT endpoints to the GPIF?

Also then thread switching refers to manually selecting Thread0 then Thread1 as IN_ADDR's parameter (like in the UVC example)?

So Socket 0 is mapped to Thread 0, and as is Socket 4. Why does this exist, what is offered by having this many aliases to the same Thread? I guess I'm not understanding what a Socket is. Is it the DMA thread's state representation of a DMA buffer?

Thanks for the prompt reply!

Hi,

You can have single DMA channel and multiple GPIF II threads/sockets pushing data to the PC through a single endpoint.

You can use MANY_TO_ONE or ONE_TO_MANY type DMA channels, if you have multiple threads on the GPIF II side.

Right. Thread selecting you can do similar to UVC example. If any device connected to FX3's GPIF II is acting as master then it will switch the threads using adress lines (2bit for selcting 4 threads/sockets, 5 bit addressing for addressing all 32 sockets available).

You may want to take a look at the following application notes:

2-bit addressing:

http://www.cypress.com/?rID=51581

5-bit addressing:

http://www.cypress.com/?docID=34371

Thanks,

sai krishna.