Could someone in-the-know please check KBA90743 "Interpreting the DMA_RDY Flag of the GPIF II Block of FX3". Its discussion is hopelessly confusing.

This article tries to tackle the topic "The terminology “DMA_RDY” is not quite correct", but it goes a long way to making matters worse.

If parts of the article are to be believed, the terminology is not just "not quite" correct, it would be completely wrong, and such a degree of wrongness should be pointed out extremely clearly. But other parts of the article undermine this conclusion.

Starting point: The discussion revolves around the master-slave interfacem where the FX3 implements the slave, with an external master. Then there are two cases, FX3 sends data through the P port to external device, and vice versa. Now:

1. For FX3 Output:

"For a channel that outputs data to the P-port (to an external chip or device), the DMA_RDY flag indicates whether there is data ready to be read out from any of the buffers. If there is at least one buffer with data committed to the P-port, the DMA_RDY flag is deasserted. It is essentially an empty flag in this case."

a. The narrative claims that when data is ready, the FX3 deassertsDMA_RDY. That would make the name a complete reverse of the meaning. Is this really true?

b. "It is essentially an empty flag, in this case". In which case? For the "output data" case, DATA_RDY assertion means empty? Or is this saying that the DATA_RDY DEassertion case means empty? Because if it's the second, that actually makes sense (DEasserting a READY signal would make sense for buffer empty), but says the opposite of the previous sentence.

2. For FX3 Input:

"For a channel that inputs data to the P-port (from an external chip or device), the DMA_RDY flag indicates whether there is buffer area available to write into. If there is at least one buffer available to be filled with data, the DMA_RDY flag is deasserted. It is essentially a full flag in this case."

a. Again, the description says that when a DMA buffer is available, the FX3 signals NOT ready! A

b. Again, it's not clear what "this case" refers to: the FX3-as-input case, or the flag deasserted case. Again the latter would make sense, but is the opposite of the previous sentence.

I agree that the wordings used in the KBA are not proper. I apologize for the inconvenience and confusion and take necessary steps to revise it.

Here is how you interpret it:

1) External device to FX3 transfer:

If the flag is asserted, no more data can be written to Fx3. If the flag is deasserted, the external device can write data. (If this flag is asserted it means FX3's DMA is full. So the external device cannot write any more data.)

2) FX3 to External device transfer:

If Flag is asserted, no more data can be read from FX3. If the flag is deasserted, the external device can read data. (If this flag is asserted it means FX3's DMA is empty. So the external device cannot read any more data)

Keeping it simple,

Flag asserted -> No data transfer

Flag deasserted -> Data transfer possible.

(In our example projects, the polarity of the flags are active low. So low on flag pins indicate assertion and high indicate de-assertion)

The way I read your discussion, you appear to describe an active-low signal (so let me label it with "#") which might reasonably be named "DMA_NOT_READY#".

(This would be a poor name for a a signal as a reader might be confused whether the NOT and # are intended to act separately, which I do intend in this case, or whether instead the the NOT merely emphasizes the #. But setting that aside...)

To spell it out, when DMA_NOT_READY# is low, and thus asserted, it means:

For FX3 data output: no data available, don't try to read from FX3,

For FX3 data input: buffer full, don't try to write to FX3.

This would make DMA_NOT_READY# the same as an active-high signal called DMA_READY.

If what you say is true, it would mean that KBA90743 is unnecessary because the signal is already correctly named. Unless the KBA is needed to emphasize that the signal is active-high, which perhaps is unexpected for some reason?

Also, this seems to be a conclusion exactly opposite to the one from this thread here: