riscv/riscv-CMOs

Feedback on CMO Spec

SanjayPatelRVI opened this issue · 7 comments

Hi, Providing some feedback on the markdown based specification maintained by David Kruckemyer. This is in regards to compatibility wrt our specification for CACHE and PREFETCH instructions as we'd eventually like to align the implementation for the 2022 Platform when software should be available.

  1. Our specification provides Index Invalidate and Index Writeback Invalidate operations which could be useful for flushing entire caches. However, if there is no need for this in planned RISC-V Software, then we can abandon this.
  2. DEMOTE.EA. Comment - Good that it is optional as in MIPS processors this was not implemented. Did not make sense to manipulate the LRU at such fine-grain.
  3. Perhaps if PREFETCH can be prioritized over CMOs, then we can implement RISC-V PREFETCH in lieu of our specification. PREFETCH is user-level so use is likely to be more pervasive. I would suggest distinguishing PREFETCH from CACHE.
  4. A CACHE FetchNLock will be very useful on L2 where the L2 is the shared cache for all the cores in the cluster.
  5. CB0.ZERO - would this be limited to a particular cache level, maybe the first cache level shared among all cores of a cluster?

Sanjay

Welcome to github and the RISC-V world :-) I'm guessing you won't have to rejig your cores much at all -- even just a shrunk R16k would be very competitive right now.

That works for us if the cache level to which CB0.ZERO allocates is implementation-dependent. It makes sense in our context to make it the cache prior to memory to avoid the memory latency. In regards to specifying levels in opcode, I only see it specified for the Cache Block Management instructions. I would expect it to also be given for Prefetch. Work in progress I assume. Sanjay

The specification does allow for levels to be specified for both CBO.ZERO and the various hint instructions. These are structural levels, e.g. L1, etc., as opposed to logical PoCs.

Closing since I think these issues have been addressed.