How does LUT sharing work?

ersmith

OK, I get that we have to allocate an even/odd pair of COGs (call them cog #0 and cog #1) and that a COG that wants to receive writes has to issue SETLUTS #1. Let's say cog #0 does SETLUTS #1. Then:

(1) Do all wrlut calls in cog #1 result in writes to both the cog #1 and cog #0 LUT?
(2) Assuming the answer to (1) above is "yes", is there any way for cog #1 to write to its own LUT (only) and not to its partner's?
(3) Does SETQ2/RDLONG in cog #1 also write to both LUTs?

rogloh

From my recollection only half the LUTRAM gets shared when enabled. So you get one half as your own, and the other half (top?) is shared between COG pair. I would hope that SETQ2 block moves from HUB to LUT still works with LUT sharing but you'd need to test or get Chip to answer that one.

TonyB_

ersmith wrote: »

OK, I get that we have to allocate an even/odd pair of COGs (call them cog #0 and cog #1) and that a COG that wants to receive writes has to issue SETLUTS #1. Let's say cog #0 does SETLUTS #1. Then:

(1) Do all wrlut calls in cog #1 result in writes to both the cog #1 and cog #0 LUT?
(2) Assuming the answer to (1) above is "yes", is there any way for cog #1 to write to its own LUT (only) and not to its partner's?
(3) Does SETQ2/RDLONG in cog #1 also write to both LUTs?

I think the answers are:

(1) Yes.
(2) No, apart from SETLUTS #0 in cog 0.
(3) Yes.

Whole LUT is shared, I believe. The half LUT behaviour is that reads/writes are not possible in upper half using immediate addressing. Note that either paired cog reading/writing top four longs in LUT can set selectable-event flags 1 to 4, therefore it might be better not to put fixed lookup tables at very top of LUT RAM if sharing is enabled.

evanh

My understanding is same as Tony's.

revA silicon has a design flaw on coinciding read and write at same address. revB is fixed.

If both cogs are sharing both ways, be careful not to have coinciding writes at same address. That doesn't work. Shouldn't be needed anyway, with only two parties.

cgracey

Tony is right.

TonyB_

From the EVENTS section of the doc:

POLLSE1/WAITSE1 event flag

● Cleared on ‘SETSE1 D/#’, for which D/# selects the event:

%000_00_00AA = this cog reads LUT address %1111111AA
%000_00_01AA = this cog writes LUT address %1111111AA
%000_00_10AA = odd/even companion cog reads LUT address %1111111AA
%000_00_11AA = odd/even companion cog writes LUT address %1111111AA

[Same applies to SE2/3/4.]

Is any of this dependent on SETLUTS #1?

Cluso99

TonyB_ wrote: »

From the EVENTS section of the doc:

POLLSE1/WAITSE1 event flag

● Cleared on ‘SETSE1 D/#’, for which D/# selects the event:

%000_00_00AA = this cog reads LUT address %1111111AA
%000_00_01AA = this cog writes LUT address %1111111AA
%000_00_10AA = odd/even companion cog reads LUT address %1111111AA
%000_00_11AA = odd/even companion cog writes LUT address %1111111AA

[Same applies to SE2/3/4.]

Is any of this dependent on SETLUTS #1?

It was added for LUT-LUT communication so I would presume yes but we will need to hear from the master

evanh

All of those function without any SETLUTS. I just tested. As far as I can tell, SETLUTS has no impact on behaviour. There is events for read and write for this cog and read and write for the paired cog. The events are tied to the relevant cog's action rather than who's lutRAM is accessed.

ersmith

Thanks everyone for your replies.