How to transfer a fast parallel byte stream to internal RAM using DMA.

Leonix said:

When is the byte at input port P6 read?

At the 2nd MCLK cycle after the trigger, the source memory location (which is the P6IN register in this case) is read and on the 3rd the data is written to the destination.
The leading cycles ise required to synchronize the DMA logic with MCLK, ensure that the CPU is not accessing the data bus at the moment and halt the CPU.
If you set the bit that delays the DMA transfer in case of a RMW instruction (as this might alter memory that has just been read by the CPU and will be written back in an atomic operation, causing problems if DMA has read or written the location in-between), it will cause additional cycles. In most cases, this isn't necessary, but should be considered nonetheless, even if only to exclude the neccessity)
I honestly do not know why there is a trailing cycle needed...

Leonix said:

How long has the byte at P6 to be stable

There's no data, but since there is only a simple clock tick (nto a two-phase clock), I assume that on rising edge of the clock signal, the address is put on the address bus and on the fallign edge, the data is read from the data bus. But that's just an assumption.

Leonix said:

4th cycle: synchronise
Is this ok?

It seems so. At least as long as you're in active mode. The users guide gives a hint in 10.2.7:
"The DMA controller requires one or two MCLK clock cycles to synchronize before each single transfer or complete block or burst-block transfer. Each byte/word transfer requires two MCLK cycles after synchronization, and one cycle of wait time after the transfer."
If LPM was active, MCLK needs to be switched on first, which may (but not must) add another sync cycle.

Leonix said:

I think it is a good idea to put a latch in front to P6. With 24MHz MCLK the MSP430 should be able to handle a 6MHz DCLK.

'should' is the keyword. :) On 6MHz trigger, you'll need 24MHz MCLK, but better more than that or you might loose clock cycles by jitter/skew. The calculation is only valid if th etwo clocks are derived from the same source, which they aren't. I think, going for full 25MHz will compensate for this.
However, this will mean that all MCLK cycles go to DMA and there's nothing left for the CPU in-between. So you indeed can go for block transfer mode - which then would only require 2 clock cycles afte rthe initial trigger and does not do further synchronization by teh trigger. So MCLK should be exactly 2*DCLK. Or at least msu tnot drift more than 1/2 MCLK cycle during the whole transfer.
Burst mode would do 4 DMA transfers, then two cycles are given to the CPU, then the next 4 DMA transfers happen. Timed by MCLK (so no addiitonal sync is needed) rather than the external trigger. This is most likely not what you want.

You could try for 16 bit transfers, if you can connect the chip to a port pair. A 16 bit transfer is as fast as an 8 bit transfer. So if you can use P1/2, P3/4 or P5/6, this would halve your transfer speed and significantly relax timing.

P.s.: NANDing DCLK, VCLK and HCLK is maybe not what you need, as the two are low at the beginning of the stream, but not low for the whole duration. You'll need an R/S flipflop that is set by HCLK/VCLK and reset by MSP after transfer is complete. This flipflop will then gate the DCLK signal.
Or, if you synchronized DCLK and MCLK so MCLK is 2*DCLK (not trivial, but maybe best solution), you only need HCLK/VCLK to trigger the start of the block mode transfer, as DCLK is implicitely taken account for by MCLK then.