-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
CoreW's CoreW's The extra LLC DMA port is currently connected to the core's Where do you think the looping is happening? |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: