Parallella Community

Andreas says the assumption at the start of this post is wrong, so this approach does not work, please ignore.
Does the TESTSET instruction go out to the target core via the write mesh? (I assume it does unless read mesh is 64 bit data path solely to accomodate this instruction) If so there is a possible alternative to the Read after Write sync problem.

Advantages: Core B RAM content effectively unchanged by the synchronisation. No flooding the mesh with polling read operations.

Comments welcome, especially spotting any flaws!

; Syncing remote Reads after Writes

; Program running on Core A
; Do your writes to Core B here

MOV R1,#%low(CoreBaddress) ; CoreBaddress can be any writable location in ordinary RAM
MOVT R1,#%high(CoreBaddress)
MOV R0,#0
TESTSET R0,[R1,R0] ; Do a test set on location CoreBaddress
; First a write goes from Core A to Core B (from way TESTSET works)
; This write arrives at Core B after any previous writes there from Core A program because of Write after Write guarantee
; The TESTSET acts at Core B. What happens here is cunning but irrelevant to the Read after Write sync
; if the target address is non-zero, it is unchanged.
; If it is target address is zero it is overwritten with zero in an atomic operation, effectively leaving it unchanged
; The outcome of the TESTSET goes from Core B to Core A via the write mesh
ADD R0,R0,R0 ; arbitrary instruction referencing R0, to force Core A to wait for the data to return from Core B

; Do your reads from Core B here
; Results from the reads are returned via the write mesh from Core B to Core A.
; They must come after the write the TESTSET did from B to A because of the Write after Write guarantee

Tim

Unfortunately the TESTSET goes out over the rMesh network
Andreas

The e-mem-sync example on the git repository seems incomplete. The test.sh passes arguments (0 0 4 4 0x12345678) but the code (e-mem-sync.c) ignores any arguments (and has no usage() routine). The code allocates emem but does nothing with it. There are also several unused variables being declared (row, col, i, j).

Was e-mem-sync supposed to "test" each core?

For those interested, this subject (wrong read-after-writes with the Epiphany) is discussed in a practical case study in (search for The Curious Case of the Epiphany).