Hi Daniel, Thanks for your response! As I understand from the code, the access latency for parallel-access cache (meaning the cache look up happens in parallel) is determined in gem5 by max(lookup latency, data latency), and for sequential access-mode it becomes (lookup latency + data latency).
I was particularly interested in observing what numbers of cycles is spent in classic cache for handling a miss. gem5 code designates two such latencies: *lookup latency* and *forward latency*. *Both of them are exactly equal to the tag latency*. When a cache miss occurs, gem5 assigns "*lat = lookupLatency*", where "lat" is gem5's internal latency variable to hold the value of appropriate latency in terms of clock cycles. This assignment is quite intuitive, and it *creates an impression that whatever value lookup latency contains is used to handle a cache miss*. If I pass any value "X" cycles into lat by "lat = X", it does not get reflected in the system. But if I force forward latency to be "X", I see it being reflected in the system handling the cache miss. *So, I find even though the assignment "lat = lookupLatency" created an impression that "lookupLatency" is used to handle a miss, "forwardLatency" is actually used.* All these things do not matter because lookup latency = forward latency = tag latency (by default). Regards, Aritra On Fri, Sep 25, 2020 at 3:42 PM Daniel Carvalho <oda...@yahoo.com.br> wrote: > 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
