Hi, Thanks Grabriel for responding Jianxing's question!
As the person that made that table, I apologize for any confusion. If anyone can cast some light on the distinction between ICN and HN that seem to be used interchangeably in many parts of the spec, you are very welcome :) At the Protocol/Transaction level the ICN is just a logical top-level block that encapsulates all responders for protocol transactions (HN-Fs, HN-Is and the MN). You can check page 29 in the spec<https://developer.arm.com/documentation/ihi0050/eb/> for a fig showing the components. On a particular physical implementation, the ICN would then also include the actual interconnect elements (e.g.: mesh network, a cross bar, a bus, etc) that will route messages to the appropriate responders. Regarding ICN/HN being sometimes used interchangeably, it was the case until the Issue D spec document. In the Issue E document I linked above, figures have been updated to be more specific (e.g. section 2.3 describing the transaction structure). ________________________________ From: gabriel.bus...@arteris.com <gabriel.bus...@arteris.com> Sent: Wednesday, August 17, 2022 4:02 AM To: gem5-users@gem5.org <gem5-users@gem5.org> Subject: [gem5-users] Re: downstream cache in CHI protocol table Hi, First, their is no downstream cache relative to HN and that’s by definition of HN. The table you linked to is the table for the CHI_Cache SLICC component which is the only component of the CHI model (aside from the CHI SLICC memory interface which merely is an implementation detail). A HN can be thought as the last layer before memory, aka the guy who shall not be snooped, aka the guy who can talk to SN-F. Other than that, the HN is yet another coherent cache. Now the architecture: a cache (which includes the HN) is in charge of maintaining coherency in the domain composed of “ itself + its upstream caches”. For instance an L2 is in charge of maintaining coherency with its upstream L1s. On the other hand, a downstream cache D sees a given upstream cache C and the other caches above C as a single RN-F (a single cache). As a result, the HN will only snoop the last level of caches which are in turn responsible for snooping their own upstream caches, if need be. Another way of describing it: 1. You are a cache that get a coherent request from an upstream cache. 2. If you have the data cached in the correct state, respond immediately and register the requester in your snoop filter (see the R* states). 3. If you don’t have the data in the correct state but another upstream cache has that data in the correct state, snoop it and respond to requester. Update your snoop filter accordingly. 4. If the data is nowhere to be seen in the required state, request it to the downstream node… * … Sending a coherent request to downstream cache if you are not a HN * … Or sending a NC request to memory interface (SN-F) if you are a HN Point 4. really is where HN and non-HN caches differ. ________________________________ Having said that, I must admit that I can’ t find that description explicitly in the CHI spec. In the CHI spec, there is only RN-F, ICN and SN involved in the coherent transactions. HN is not even explicitly mentioned on these figures. My interpretation is that, considering the definition of HN (“Home Node. Node located within the interconnect that receives protocol transactions from Request Nodes, completes the required Coherency action, and returns a Response.”), a cache must behave as a RN-F with respect to its downstream caches and as a HN with respect to its upstream caches. As such, HN could be more of a logical agent implemented by the ICN than an actual physical node. If anyone can cast some light on the distinction between ICN and HN that seem to be used interchangeably in many parts of the spec, you are very welcome :) Best, Gabriel IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
