DMA interrupts

[timpart]

[hewsmike]

I think I may have a 'simple' solution to notifying the target core of DMA write completion - assuming that's what's wanted.

Have the destination buffer structured with a flag positioned at the very end. As DMA transfers are sequential across blocks of transferred data then this flag will be the last location to be written to. Assuming ( potential ) source cores are aware of this structure then :

(A) The target core sets the flag state to 'ready for data', as and when it pleases.

(B) Source cores can initiate DMA writes of data to the buffer by first checking the flag's value for 'ready for data' state.

(C) The flag is then set by the source core to a 'data being transferred' state.

(D) Must use TESTSET to achieve B and C here, atomically accessing and maybe changing in case there is a race with another source core also wanting to write to the destination buffer. This implies the 'ready for data' state of the flag must be of value binary zero.

(E) You need a 'data being transferred' state on your flag as (a) the target core ought know it's request is being fulfilled, but that the contents aren't yet valid, and (b) any other potential source cores must be excluded from writes to the buffer, else you may get overwrites during transfer ( one source core chasing the tail of another through the buffer, mutual overwrites etc depending on core locations and eMesh state and timings .. UGH ).

(F) The final address in the source buffer contains the flag value 'transfer complete', this is hence written to the flag's location in the destination buffer as the final act in the DMA transfer. Which is the desired behaviour !

(G) The target core checks the flag for 'transfer complete' state - busy waiting, non-blocking, whatever you like - before using the data in the buffer.

Rinse, lather, repeat .....

Cheers, Mike.

( edit ) You want DMA writes at source, with the status of that sampled locally on the target, as this fully leverages the asymmetry of the eMesh .....

[ysapir]

@hewsmike

... or just use E_MSGMODE_INT? (look a few posts back)

[hewsmike]

Ah ! I spend my life re-inventing the wheel ...

Cheer, Mike.

( edit ) Or having clever chaps such as yourselves invent better ones ....

[hewsmike]

Actually the question still remains ( assuming it has importance for some software design ) : can the source core reliably communicate to the target core, via these interrupt mechanisms, the destination to which the completed DMA transaction refers ?

[ I know I'm being a devil's advocate here : but I'm trying to define what may be implicit, and thus what must be honored in the generality ie. do we have to assume something about DMA (in)activity .... ]

I guess this still devolves to whether the source DMA itself moves on - overwriting it's config/control registers - before the interrupt service can read said registers ?

Please do advise if I've stupidly missed something ....

Cheers, Mike.

[ysapir]

[ysapir]

[hewsmike]

[timpart]

[mhonman]

How about using conventional DMA for the transfer (initiated by the sending core), and reserve message-mode DMA for signalling - a control data path?

That way
(a) a sender can inform the receiver that data transfer is complete, and in the meanwhile the receiver can be doing useful work
(b) a receiver can inform communication partners that it is ready to receive data (not sure this would be useful)

Also, if multiple cores are trying to make master-slave message mode DMA transfers to a particular core, if the control message size can be kept to a doubleword or less, those should be guaranteed to be atomic (or is it that if a message-mode DMA transfer is already in progress and another core attempts to make a message-mode transfer to the same slave-mode core, the newcomer is blocked until the first transfer has completed?).

For synchronous transfers it should be possible to use control words much like Mike suggested a few posts back. However (borrowing shamelessly from concepts in the barrier implementation) if each core has a control word for its end of the communication - and it is only the peer that writes to that control word - the two cores can keep each other informed of the communication state by low-cost remote writes, and purely local busy waiting.

At least that is what I think will work - thanks to Ben's generosity that theory will tested RSN.

In a buffered extension to that model, message-mode DMA could be used to interrupt the receiving core instead of it having to busy-wait. But the "proof of the pudding is in the eating"...

Mark