Using DMA with MPY

Hello, Brent

I guess that my reply isn't helpful for your design anymore, but I feel obliged to share some experience for those who would be interested in the "MPY + DMA mystery". Both the user's guide and MSP430 forums lack of any comprehensive explanation of how these modules work together. Obviously the information is scarce because the application is very rare and exotic, but anyway ...

The multiplier provides a single(!) trigger to the DMA, that's why the only transfer mode that works is "block mode" (or "repeated block mode", i.e. DMA_1 or DMA_5). Another important issue is the size of the operands: the first operand can be of any size (8, 16, 24 or 32 bits). The second operand must be 24 or 32 bits! It is possible to emulate the second operand of 8 or 16 bits just by a "dummy" write access to OP2H, i.e. "OP2H = 0;".Skipping to do so, the MPY result registers will contain the correct data, but the DMA destination will not. Accessing the high word of the second operand is crucial, because it generates the trigger request and it defines the exact moment when the trigger should fire (4 cycles later after the end of the high word access). The write access can take from 3 up to 5 cycles, thus the trigger timing will vary. By the way, transferring the result less than 64 bits by the DMA is not worth trying, because the CPU would do that almost as fast as the DMA. Here is the code snippet:

uint64_t mpy_result = 0u;                                             // RAM location of max size

void DMA_MPY_Init(void)
{
  mpy_result = 0u;
  DMACTL1 = DMA2TSEL__MPY;                                // DMA2TSEL_29
  DMA2SA = (void __data20 *)&RES0;
  DMA2DA = &mpy_result;
  DMA2SZ = (sizeof mpy_result) / 2;                              // 4 words
  DMA2CTL = DMADSTINCR_3 | DMASRCINCR_3 |   // src & dst incremented as word
                       DMADT_5 | DMASWDW | DMAEN;        // block mode (preferably repeated)
}

The DMA transfer of 4 words takes 8 MCLK cycles, which saves 10 clock cycles instead of 18 cycles by the CPU (using the indirect autoincrement addressing). The call-return instructions will consume all the MCLKs that were so painfully gained. That's why no function should be used, only an inlined macro:

#define DMA_MPY_MULT_U32_U32(x, y)\
{\
__istate_t mpy_state = __get_interrupt_state();\
__disable_interrupt();\
*(uint32_t *)&MPY32L = (uint32_t)(x);\
*(uint32_t *)&OP2L = (uint32_t)(y);\
__set_interrupt_state(mpy_state);\
__delay_cycles(1);\
} // look for the result in mpy_result

#define DMA_MPY_MULT_U16_U16(x, y)\
{\
__istate_t mpy_state = __get_interrupt_state();\
__disable_interrupt();\
MPY32L = (uint16_t)(x);\
OP2L = (uint16_t)(y);\
OP2H = 0;\
__set_interrupt_state(mpy_state);\
__delay_cycles(1);\
} // DMA2SZ can be set to 2

The "dummy" delay cycles and restoring the interrupt state are needed for synchronization, if the result is accessed right away. They consume exactly 4 MCLKs. But they can be removed at your own choice and risk.

Transferring the both operands to the multiplier by the DMA is also possible. The first operand is transferred by the DMA channel 0 (e.g. software trigger, 2 words, block mode), the second operand is transferred by the DMA channel 1 ("end of channel 0" trigger, 2 words, block mode), the MPY result is transferred by the DMA channel 2 ("multiplier ready" trigger, 4 words, block mode). Using this approach would make interrupt disabling unnecessary, but sacrificing the three DMA channels is a real overkill...

You can also transfer the result backwards by decrementing from RES3 down to RES0, but it takes by 4 MCLK cycles longer (I don't know why) and is not recommended. All the time measurements were made by a hardware timer sourced by SMCLK 4x faster (the faster the better) than MCLK taking into account the overhead for handling the timer.

After all, never forget the DMA10 erratum issue! It can bite you when you don't expect ;)