Hi all, I'm currently undertaking a research project where I am implementing fence.t, a proposed fence instruction for RISC-V allowing ISA access to clearing microarchitectural state, and performing relatively coarse assessments of performance impact. As a result, I'm trying to implement this functionality in gem5.
It would be greatly appreciated if someone more well-versed in gem5's memory model could double check some of my implementation ideas below, so I don't get caught by any gotchas. >From what I can tell, starting with the classic cache, the most sensible way >to add this feature is to extend the packet protocol to memory so it includes >a new command, much like FlushReq, but instead, for example, FullFlushReq. >Then modify BaseCache::access to handle this new packet, functionally handling >the flush with BaseCache::memWriteback and then BaseCache::memInvalidate, >perhaps with some simulated latency added for the act of 'flushing' the cache. >Since the instruction would need to act like a memory fence (or at the very >least, have no memory requests reordered past it), the IsWriteBarrier and >IsReadBarrier flags would be included in the ISA declaration of the >instruction. I may also need to extend Ruby to include a full cache flush instruction - I've seen other threads on this list with respect to that, but if there are any recent changes or pertinent information then it'd be greatly appreciated if you could let me know. Also - if there are any resources around on gem5's memory modelling that I might've missed, other than those in the documentation, please let me know as more stuff to aid understanding is definitely appreciated. Thanks, Ethan
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
