Hi, I am currently extending the cache maintenance in gem5 to support a new kind of operation and I am looking to get some feedback and suggestions on the design from developers familiar with the gem5 cache modelling.
Some background: current SoC's contain multiple CPUs, GPUs, HW accelerators etc., a mixture of coherent and non-coherent devices. The devices share data and make use of multi-level cache hierarchies. AMBA4 ACE (AXI Coherence Extensions) specifies a protocol for supporting system coherency by hardware. A major part of this protocol is a set of cache-coherent, cache-maintenance, and barrier transactions. Further motivation and background is available at: http://www.arm.com/files/pdf/CacheCoherencyWhitepaper_6June2011.pdf<https://nexus.arm.com/owa/redir.aspx?C=f5ce067c11364ce9a2dcdd921500c321&URL=http%3a%2f%2fwww.arm.com%2ffiles%2fpdf%2fCacheCoherencyWhitepaper_6June2011.pdf> In order to analyze the impact of such system-coherency hardware support, I'm working on modeling ACE-like transactions. Hence, adding request types and logic to the cache and bus models. One of the most important transactions to be added is ReadOnce, which basically is meant for "peeking" at data, e.g. GPU reading configuration which is in some CPU cache. The initiator must not cache the response; the response must not be a dirty copy. Further details are available in the AMBA ACE Specification, available at:https://silver.arm.com/download/download.tm?pv=1198016<https://nexus.arm.com/owa/redir.aspx?C=f5ce067c11364ce9a2dcdd921500c321&URL=https%3a%2f%2fsilver.arm.com%2fdownload%2fdownload.tm%3fpv%3d1198016> (requires _free_ login). The 2 distinctions between gem5's Read and ReadOnce are: (1) response should not allocate a line in cache (this does not mean UNCACHEABLE, which is memory-region specific and not request-specific) (2) owner can keep his line in writable state My proposed changes: In order to add support for ReadOnce in gem5, I plan to: 1. add 2 new command enums to MemCmd::Command (src/mem/packet.hh): ReadOnceReq & ReadOnceResp 2. add 2 commandInfo entries to MemCmd::commandInfo (src/mem/packet.cc), using the command attributes used for ReadReq & ReadResp 3. To distinguish these requests from ReadReq/Resp, add a new attribute "NoAllocate" (to enum Attribute in src/mem/packet.hh), for specifying not to allocate a line for the response. The code already contains attributes (e.g. IsPrint, IsFlush) for other, not-so-common cases. * using the UNCACHEABLE flag is improper as UNCACHEABLE requests are not forwarded to caches, as UNCACHEABLE address ranges cannot reside in caches while ReadOnce's requested address may. * adding as attribute flag (FlagsType in src/mem/request.hh) seemed less appropriate; requiring the flag to be set according to the request type. This seems like an awkward way of achieving the same effect. 4. Adding the actual logic requires minor changes to cache_impl.hh, base.hh and bus.cc. I've recently posted a table on the wiki summing current packet commands and their attributes (see http://www.gem5.org/Packet_Command_Attributes<https://nexus.arm.com/owa/redir.aspx?C=f5ce067c11364ce9a2dcdd921500c321&URL=http%3a%2f%2fwww.gem5.org%2fPacket_Command_Attributes>). My proposed change means adding 2 new rows (new commands) and 1 new column (new attribute). My request: Since this requires changes to several core files (packet.hh/cc, cache_impl.hh, base.hh, bus.cc), I prefer asking for your feedback, rather than doing that at the patch review-request stage. A) any objections to the proposed added transaction enums? B) any insights to share. Your feedback is most welcome. Thanks and regards, Uri _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
