Address Space - I_MEM/D_MEM/CR strc

[amichai-bd]

@DL8 - moved the LOTR Design discussion to the github

[amichai-bd]

From the HW Point of view:

In the LOTR_TILE interface, we have a basic protocol where we send RD/WR (load/store) request core<->fabric.
It has the Address + Data/DatRsp + Header.
Using the address LSB's for the interface will simplify the interconnects and reduce the number of HW connections between Tiles.

Note:

I agree this is true also if we use the "middle" bits as Reserved and MSB core id - but it keeps things simple.
Also Please Note:
Having bits [13:0] -> AKA 16KB in the Local-Memory (16KB Data + 16KB Instruction = 32KB SRAM for each core),
&& when we plan to have many cores-> even hundreds or thousands - 16KB per core is very very generous.
(I was thinking something like 2-4KB per core in our POC design)

In case we want to use the core in a more standard way - a single core and not multi-threaded RING design,
we might want to be more scalable for larger "near memory" within the core.

So I think your suggestion very logical and we should have a larger "memory offset" which will allow each core to have larger local memory.

my concern was

How does the compiler handle acting addresses which are further away from offset 0?

From what I noticed - when the compiler is trying to set addresses larger than the immediate this takes multiple instructions to perform the load/store

So my intuition was to move the address Space to the LSB.

Looking more into it - we want and expect the majority of the load/store done from the core to the local memory.

• so moving the CORE_ID to the MSB should really affect the performance. (and also in the current design we need multiple instructions to perform the load/store to the non-local memory address.

To conclude

• I agree and I think we should move the CORE_ID to the MSB and move the reserved bits in the middle of the address space bits.
• regarding the "region bits" - I think once we already use more than 12bits for the memory offset (see the ISA Immidate bits), we need multiple instructions to perform the load/store to the CR/D_MEM (shared memory space) due to when accessed we don't use the Stack pointer as a relative address. - we "Hard Code" load and store to the Shared region and the CR region.

[DL8]

The table you showed shows how to load addresses into PC. I don't see how moving the core ID bits helps in this scenario, because I_MEM is small either way.
Regarding loads and stores, what you described is not the case: the address is calculated as rs+offset, where rs is a 32-bit register. How you use the offset vs. register is up to you.

Using a small amount of memory for the PoC is fine, but the memory layout should be future-proof.
In addition, perhaps there should also be an indication of how many bits are available for memory offset.

[amichai-bd]

"indication # of bits are available for memory offset" -you mean CR?

Regarding your suggestions - I agree..
Let's do it and document it in both the SW Arch && the HW LOTR Arch.

Please start with the SW documentation, and open an issue to add the HW LOTR Arch on my name, project LOTR, milestone RTL0.3.

And please note - you are this project SW expert.