MACNET: BDs expected to be set to "Ready" in reverse order?

[hmijail]

Vybrid's MACNET is appallingly scarcely documented, seemingly like the rest of the uC, but I have finally managed to find good information in the i.MX52 Reference Manual about the FEC module, which is theoretically similar to MACNET - apart from the register changes and who knows what else.

The thing is, in there there is discussion about the TX BDs having to be marked as "Ready" in reverse order. For example, if we have buffers 1, 2 and 3 defining together a single frame, they should be marked as "Ready" starting by the 3rd, then 2nd, then 1st. The explanation is that in that way we avoid the situation of the DMA starting transmission of a buffer (say, the 1st) when the 2nd is still not marked as "Ready", which would cause an underrun.

My question is: what about the situation of the 3rd buffer being marked as "Ready", and before we manage to mark the 2nd one, the DMA engine starts transferring the 3rd one?

To me it looks like a worse problem, because at that point the FIFO is *guaranteed* to underrun. In contrast, if we had marked them in their natural order, there is the chance that while the DMA transfers the 1st buffer, the 2nd might still be marked "Ready" on time.

Furthermore, the description of how the DMA engine looks for ready buffers says that once DMA finds a non-Ready BD, it will recheck it once more. So we have an extra chance - if we set the buffers as Ready in the natural order, not reverse!

Of course this talk about "chances" sounds rather unreliable anyway, and yet it is better than the guaranteed underrun/broken frame.

One possible answer is that, since the DMA would have stopped when it found the non-Ready BD, then marking them in reverse order makes the DMA engine stop before it finds the already-marked BD. But that in fact only minimizes the window of opportunity: say the 3rd buffer is Ready, DMA checks 2nd buffer and finds it non-Ready, and before it re-checks, the 2nd buffer is set. Again we have underrun/broken frame.

So, am I missing something?

Another related question is: the TDAR discussion always says that setting TDAR tells the DMA to read the *next* BD in the ring. Now, let's suppose that in the last transmission the last buffer read was the 2nd. So, next time TDAR transitions 0->1, the DMA will directly go to the 3rd buffer? What happens then if it was part of a BD "chain"? Again underrun/broken frame?

On the other hand, let's suppose that transitioning TDAR 0->1 makes the DMA start from the 1st BD. Now, what happens if we had set our BD in position 2? (for example because we had just transmitted a frame from buffer 1). Theoretically the DMA engine would find the 1st BD non-Ready, will retry, will find it again non-Ready and will stop trying.

Looking at how u-boot's, Linux's, and MQX's FEC drivers work, it has to be that the DMA continues working from where it was. But then what happens to a possible BD chain?

At this point it looks highly suspicious that all those drivers work exclusively with non-chained BDs...

[naoumgitnik · Accepted solution]

Dear hmijail,

Our Ethernet expert provided his feedback:

===================================

>>Vybrid's MACNET is appallingly scarcely documented, seemingly like the rest of the uC, but I have finally managed to find good information in the i.MX52 Reference Manual about the FEC module, which is theoretically similar to MACNET - apart from the register changes and who knows what else.

• MACNET supports the FEC Buffer Descriptor Programming Model. However, MACNET also implements the new Enhanced Buffer Descriptor programming model to support new/enhanced features which are not supported by FEC. These features such as, TCP/IP/UDP/ICMP Offload Engine (Hardware Accelerator), IEEE 1588 Time Stamping, etc. In addition to these, the MAC-NET also support 1000 Mbps mode (if it is enabled), while FEC is not capable of 1000 Mbps.

>> The thing is, in there there is discussion about the TX BDs having to be marked as "Ready" in reverse order. For example, if we have buffers 1, 2 and 3 defining together a single frame, they should be marked as "Ready" starting by the 3rd, then 2nd, then 1st. The explanation is that in that way we avoid the situation of the DMA starting transmission of a buffer (say, the 1st) when the 2nd is still not marked as "Ready", which would cause an underrun.

• This is about using 3 Tx BDs (instead of a single Tx BD) to transmit a frame. The user needs to consider this multi BDs approach as a single “consolidated” BD approach, for which the user can only set the READY bit if ALL Tx Data associated with these BDs are ready. This is why the Ready bit should be marked in the reverse order.

>> My question is: what about the situation of the 3rd buffer being marked as "Ready", and before we manage to mark the 2nd one, the DMA engine starts transferring the 3rd one?

• No, the DMA will not transferring the third-one. The DMA will always transfer/process these Multi-BDs, starting from BD 1 -> BD 2 -> BD 3.  This is why in a single frame transmission using Multi-BDs, the user needs to mark/set the Ready bit in the reverse order.

>> Another related question is: the TDAR discussion always says that setting TDAR tells the DMA to read the *next* BD in the ring. Now, let's suppose that in the last transmission the last buffer read was the 2nd. So, next time TDAR transitions 0->1, the DMA will directly go to the 3rd buffer? What happens then if it was part of a BD "chain"? Again underrun/broken frame?

• In a single BD case (i.e., transmitting a frame with a single BD), it will go to the third buffer.
• In a multi-BD case (i.e., transmitting a frame with more than one BD), it will still go to the third buffer. Therefore, as stated above, the user needs to first prepare ALL Tx Data associated with these multi-BDs, and then set the Ready bit of all this Multi-BDs in a reverse order (i.e.,  The user needs to consider this multi-BDs approach as a single “consolidated” BD approach).

=================================

This more or less the level we can discuss the product operation; digging deeper into its internal structure, however, might be quite likely considered touching the company confidential information.

Sincerely, Naoum Gitnik.