TCP3e and EDMA3 memory alignment

Ran Yaniv,

You are correct on both items. The EDMA3 operation does not have any restrictions on data alignment in the general case. However, the TCP3e has a restriction on the alignment of accesses to that peripheral.

To properly access the TCP3e, all accesses must be 32-bit aligned. This includes DSP-driven accesses as well as DMA or QDMA accesses.

Does this help to clarify the situation?

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

Hi Randy,

I'm considering a typical use case, where a buffer in memory holds a large transport block (TB). The TB is segmented into code-blocks, which are then transferred to the TCP3e. Some of the code blocks will be aligned to 32-bit address, and some wont (depending on the code-block sizes and considering that without the CRC-24 most sizes are not a multiple of 32 bits).

Since the sizes of the code-blocks in the TB vary, they can't all be processed with one TCP3e command (using MCNT > 1). So even if the first code-block is aligned, some code-blocks will require a separate command with a start address that is not aligned to 32 bits.

Of course, each non-aligned code-block can be copied by the DSP to an aligned buffer before transfer to the TCP3e, but this is very wasteful.

Going back to EDMA3, I understand why the TCP3e side of the EDMA transfer (that is, DST in the input transfer stage) must be 32-bit aligned (a TCP3e requirement on mapping of its internal memory to addresses).

However, why should the DSP side of the EDMA transfer (SRC) be concerned with this? Isn't it responsibility of EDMA3 to allow transfer of data from non-aligned SRC address to aligned DST address?

Thanks

Ran

Ran Yaniv,

I missed that this is on the DSP side of the transfer. Like you I would not have assumed that this restriction would exist on that side, so I did not consider your question correctly.

You and I could try to disect the inner byte-alignment operations of the EDMA3 to figure out if there is some condition that would result in multiple writes to the TCP3e that are not multiples of 4 bytes, or some condition where the initial write to the TCP3e is not a multiple of 4 bytes. But that would be very hard to model and to validate.

The fact that this restriction is listed means that someone has already determined that this could be a problem. This is not a cut-and-paste error where a similar restriction was placed in another part of the document (no other occurrence in this UG) or in another document (not in TCP3d UG, for example). The author specifically wrote in this restriction.

All I can tell you is to follow the User's Guide's conditions, or take the risk of bad encoder behavior. If you have enough control over the creation of the Transfer Block, then perhaps you can easily segment the large block so that each segment is 32-bit aligned.

Perhaps someone else monitoring this thread will have a more satisfying answer for you, but I am not sure that will be the case.

If you require more follow-up, please name a device that you are using.

Regards,
RandyP