Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Topology appears confused in CoreW #15

Open
jonwoodruff opened this issue May 26, 2020 · 3 comments
Open

Topology appears confused in CoreW #15

jonwoodruff opened this issue May 26, 2020 · 3 comments

Comments

@jonwoodruff
Copy link
Contributor

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
Copy link
Contributor

jrtc27 commented May 26, 2020

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants