Tightly coupled memory

[9ary]

Supporting TCM, similar to ARM cores, would be a good alternative to caches. It should be a bit less resource-hungry, it's more deterministic for hard real-time applications, and we can take advantage of the dual-port block RAMs in most FPGA architectures to have a shared instruction and data TCM. The core could run entirely out of TCM and use external memory busses only to talk to peripherals.

[Dolu1990]

Hi,

Do you mean TCM for cache full or cache less VexRiscv configs ? I mean both are very different case, so i just want to know which one we are takling about ^^

dual-port block RAMs in most FPGA

Sure that's a good thing to use

[9ary]

I'm not sure how much the presence of absence of a cache would affect this, but there are cortex-m cores with both. It's just a chunk of RAM that's placed closer to the core in the memory hierarchy, and has lower access latencies than external RAM since it doesn't have to go through the bus multiplexer, but the cost is of course that external peripherals can't access it. Ideally it would be even closer to the core, or at the same level as the cache.

Here's how it looks in the cortex-m3 implementation for FPGAs:

In the cortex-m1, they show the TCMs on a different path, not sure what's up with that.

[tomverbeure]

Do you mean TCM for cache full or cache less VexRiscv configs ? I mean both are very different case, so i just want to know which one we are takling about ^^

FWIW, with or without cache is orthogonal when talking about TCM. Many embedded CPUs have both, with TCM that is small but fast (almost always the same access latency, or faster, than a cache hit) with predictable access time (used for real-time interrupt driven routines etc.) and cache (or not) for all the rest of the code.

Tom

[9ary]

Yeah, that's what I was thinking. FPGAs also give you a lot of freedom for how you allocate the available block RAM to components. Dual port RAMs allow for a unified code+data memory while keeping a full Harvard architecture. For example on a Spartan 6 LX9 or an ECP5 12k, you could easily have a 32KB TCM as the main memory for the processor, and then use the rest (still 16x 18Kb) for private peripheral buffers, or DMA space, which don't necessarily require as much space. This way you don't need cache at all, so you may end up saving resources (since caches require more block RAMs for the metadata, and also extra logic which may limit your Fmax).

[Dolu1990]

So currently the status of VexRiscv is as following : Cached =>

• the I$ plugin support TCM interface
• the D$ do not support any form of TCM interface, but it shouldn't be something complicated to add, excepted if you also want atomic support in the TCM memory space, then things will be a bit more tricky.

Uncached =>

• the cacheless iBus dBus plugins do not implement any form of TCM support, the reason for that are multiple, but one big part of it is it isn't realy a big deal if you have a proper controle over your memory interconnect architecture. But this is something often hard to do with third party AXI / AHB interconnect which any do have all sorts of overhead.
• To fix that, we could totaly imagine some IBus dBus wrapper which would internaly manage the TCM and expose a general purpose memory bus master to connect the rest of the design.

One thing to keep in mind is if you want JTAG debugging to work, it is required the DBus to have access to the instruction TCM. Else it is probably not required with a proper linkerscript (as far i know).

[9ary]

Thanks for the clarification.

To fix that, we could totaly imagine some IBus dBus wrapper which would internaly manage the TCM and expose a general purpose memory bus master to connect the rest of the design.

That would be nice to have yes.