Hello Aritra, It seems that the tag lookup latency is indeed disregarded on misses (except for SW prefetches). The cache behaves as if a miss is always assumed to happen and "pre-prepared" in parallel with the tag lookup. I am not sure if this was a design decision, or an implementation consequence, but my guess is the latter - there is no explicit definition of the cache model pursued by the classic cache. Regards,Daniel Em sexta-feira, 25 de setembro de 2020 11:00:39 GMT+2, Aritra Bagchi via gem5-users <gem5-users@gem5.org> escreveu: Just a humble reminder. Any comment would be highly solicited. Thanks,Aritra On Thu, 24 Sep, 2020, 12:22 PM Aritra Bagchi, <bagchi95ari...@gmail.com> wrote:
Hi all, While experimenting with gem5 classic cache, I tried to find out how an access miss is handled and with what latency. Even if in cache/tags/base_set_assoc.hh, the access (here a miss) handling latency "lat" gets assigned to the "lookupLatency", the actual latency that is used to handle a miss (in cache/base.cc: handleTimingReqMiss( ) method) is the "forwardLatency". This is my observation. Both "lookupLatency" and "forwardLatency" are assigned to the cache "tag_latency", which is okay! But I experimented with different values for them and observed that the value of "forwardLatency" actually gets reflected ( in terms of the clock cycle delay from the cpu_side port to the mem_side port) into the system for handling a cache miss. Could someone please confirm whether my observation and understanding is correct or not? Regards,Aritra _______________________________________________ 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
_______________________________________________ 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
