Hi Sophiane, The cache is pretty good at the configuration it currently captures, where the various latencies “align” in a specific way.
Note that the latencies in the actual C++ class are already broken out: lookupLatency, forwardLatency, fillLatency, and responseLatency. These components are simply not exposed in the Python class, and not applied consistently throughout the code. If you can take a stab at this that would be great. Thanks, Andreas From: senni sophiane <[email protected]<mailto:[email protected]>> Date: Friday, 3 June 2016 at 15:06 To: Andreas Hansson <[email protected]<mailto:[email protected]>>, gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: Re: Parallel and Sequential access for cache Thanks Andreas. Yes, I can have a look. What do you mean by "It is doing an ok job at a very specific timing behaviour" ? Can you explain, please ? Maybe through an example ? So, I can understand what is (and is not) taken into account when accessing cache. Regarding the sequential access, and as a first change, I think the cache access latency needs to be splitted in tag lookup and RAM latency. Cordialement / Best Regards SENNI Sophiane Ph.D. CNRS / LIRMM (www.lirmm.fr<http://www.lirmm.fr>) Le 03/06/2016 à 09:36, Andreas Hansson a écrit : Hi Sophiane, I think the bottom-line is that the classic cache needs a bit of a timing revamp. It is doing an ok job at a very specific timing behaviour, but it doesn’t quite respond as you want to the various parameters. It would be great if you could re-do the timing annotation, and also expose the more detailed C++ parameters in the python wrapper. For the various flows through the cache we’d then have to make sure that the right delay components are added or maxed together (tag lookup, RAM access, pipeline latency). Do you think you could have a look and post a patch? Thanks, Andreas From: senni sophiane <[email protected]<mailto:[email protected]>> Date: Thursday, 2 June 2016 at 14:37 To: gem5 users mailing list <[email protected]<mailto:[email protected]>>, Andreas Hansson <[email protected]<mailto:[email protected]>> Subject: Re: Parallel and Sequential access for cache Hi, Maybe my question was not clear. A simpler question, does gem5 consider the same cache access latency (tag access + data block access) for both parallel and sequential modes ? If not, where this difference is taken into account. Does someone have a part of the answer ? Thanks Cordialement / Best Regards SENNI Sophiane Ph.D. CNRS / LIRMM (www.lirmm.fr<http://www.lirmm.fr>) Le 31/05/2016 à 15:01, senni sophiane a écrit : Hi Andreas, I have a question regarding the cache access mode for cache. I saw the cache can be accessed either in parallel (tag and data arrays accessed in parallel) or sequentially (tags accessed in parallel, only one data array (or block) is accessed on a hit). By reading the "src/mem/cache/tags/base_set_assoc.hh" file, I noticed that the number of data blocks accessed is different depending on the cache access mode. However, I did not see where the difference in terms of latency is taken into account. It seems that for both modes, the cache access latency coresponds to the "hit_latency" parameter, isn't it ? If so, I am not sure what does the "hit_latency" parameter represent ? Does the "hit_latency" correspond to the tag lookup latency ? Or does it represent the complete access cache (tag lookup latency + latency to read out the data block) ? As far as I know, sequential access is slower than parallel access. Thanks for your help. -- Cordialement / Best Regards SENNI Sophiane 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. 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 [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
