search

bluespec / Toooba

RISC-V Core; superscalar, out-of-order, multi-core capable; based on RISCY-OOO from MIT
Other
161 stars 36 forks source link

Topology appears confused in CoreW #15

Open jonwoodruff opened 4 years ago

jonwoodruff commented 4 years ago

The topology in CoreW appears to be confused. There are references to separate imem and dmem interfaces from the core, when the RISCY-OOO master0 and master1 interfaces appear to be cached and uncached memory respectively (combining instruction and data potentially behind the LLC cache). The extra RISCY-OOO LLC slave port we believe is present for coherent accesses and should be reexported, but appears to be used as a slave for standard memory accesses. I haven't understood yet how accesses eventually reach memory rather than looping through the LLC cache repeatedly.

jrtc27 commented 4 years ago

CoreW's cpu_imem_master should really be called cpu_cached_master, and is merely Proc's master0, which itself is the LLC's master.

CoreW's cpu_dmem_master should really be called cpu_uncached_master, and is the master coming from the 2x3 fabric for I/O accesses that aren't the PLIC/CLINT.

The extra LLC DMA port is currently connected to the core's tlbToMem.

Where do you think the looping is happening?

jonwoodruff commented 4 years ago

Reading a little deeper, the mkLLCDmaConnect module in Core merges all the TLB interfaces with the external DMA interface into a DMA server interface of the LLC. The external DMA interface of the Core is named "debug_module_mem_server", and CoreW refers to this slave "llc_slave_num" and appears to route all requests to the memory controller into this interface.

Presumably, if these requests are to the memory controller, they will again be routed out of master0? Again, there's something missing from this picture, but it appears that something unintended is happening here.

jonwoodruff commented 4 years ago

I think I understand this now. The path that routes LLCache accesses back into the LLCache is only on the "dmem"/master1/uncached interface, and only happens when the address is to the main memory. As the main memory is in the cached region (right?), this path should never be taken. At any rate, I currently believe this connection is nonsense and there should either be nothing connected to debug_module_mem_server, or it should be exported.