Thank you very much for so detailed answer.
It was very usefull for me.
Your answer is a little confusing.
For a channel that inputs data to the P-port (from external chip/device), the DMA ready flag indicates whether or not there is buffer area available to write into. If there is at least one buffer available to be filled with data, the DMA ready flag is deasserted. It is essentially a full flag in this case.
You are using the word "deassert" which to me means the signal is in its false state. i.e. deassert means DMA Ready is not true. If the signal is active-high, then deassert would mean that it is at a logic low level.
Is this how you are intending the description? You say that if there is at least one buffer ready the DMA Ready de-asserts? I would have expected that if the GPIF interface is able to receive data into a buffer then DMA Ready would be asserted (i.e. become active, meaning logic high for active-high signals).
Can you please clarify?
I wanted to share the information I got from Cypress which clears things up considerably. +1 for their support case workers, thank you!
First, "DMA_RDY" is actually a signal that is asserted when there is no DMA buffer available to satisfy the request (read or write) -- this is very confusing because "DMA Ready" to myself and anyone I've asked sounds like a signal that is asserted when the DMA operation should proceed. Anyway... If you think of the signal as "DMA NOT AVAILABLE" then things start to make a lot of sense. The example given to me helps this understanding:
Let's say you have a DMA descriptor with 4 1kB DMA buffers. Let's also say you want the transfer to take data from GPIF and transfer it into the FX3 (i.e. a DMA IN operation). When the system is first initialized, all four buffers are empty. Since there is at least one buffer available, DMA_RDY will NOT be asserted. The FPGA transfers 1kB of data. Now you have 1 buffer full, 3 buffers empty. DMA_RDY will remain in its inactive state. The FPGA transfers another 1kB... now you have 2 full, 2 empty, and DMA_RDY stays inactive. Transfer another 1kB. 3 full, 1 empty, DMA_RDY still inactive. Transfer 1kB. Now you have 4 full, 0 empty. DMA_RDY now asserts. Remember that DMA_RDY really means "DMA not ready".
The DMA_RDY flag will remain asserted now until one of those buffers is completely emptied (e.g. it was consumed by the USB peripheral). Now you have 3 full, 1 empty and since there is at least one DMA buffer available to transfer, DMA_RDY will de-assert, signalling the FPGA that it can now transfer data again.
I have specifically used the words assert/active and de-assert/inactive beause the flag can be configured as active-high or active-low. While remedial, I will include this for completeness: for an active-high signal, assert means that the output will be at a logic high, and de-assert means the output will be at a logic low. For an active-low signal, the opposite is true. i.e. for active-low, when the signal is asserted, the pin is at a logic low, and when it is de-asserted, the pin is at a logic high.
Personally, I was confused by two aspects of this flag:
- DMA_RDY means "DMA not ready" or "DMA full" -- it asserts when a DMA transfer cannot be performed
- The DMA_RDY flag reports the availability of ANY buffer in the descriptor for the DMA thread, not the current buffer. This makes a lot of sense in hindsight.
Regarding the DMA_PARTIAL flag:
The DMA PARTIAL flag cannot be used to start a DMA transfer because the state of this flag is indeterminate during the time when the descriptor is being updated to use the next buffer. This is not described in the documentation. This is why DMA_RDY must be used to start a transfer, and DMA_PARTIAL can be used to end a transfer if simple data counting is insufficient.
It would be greatly appreciated if the documentation were updated to elaborate on these points. The naming of this flag is really, really bad.
Thanks for the info!
-10 for the documentation team though. An example project is required IMHO
And why are we not getting this direct from Cypress employees?
So is there some special steps to take to make sure that these DMA buffer does not interact/overlap with each other. Will it be safe just by setting the dmaConfig.size respectively? For example, setting the one for the channel of USB3.0 data transfer to 16K and then setting another one 16 byte for other DMA channels. Will they just work fine?
I failed in trouble with DMA now, the above comments maybe are useful for me.
I should take some time to understand these information.