Ok. I will take a look. Thanks
Cordialement / Best Regards SENNI Sophiane Ph.D. CNRS / LIRMM (www.lirmm.fr) Le 03/06/2016 à 16:11, Andreas Hansson a écrit : > 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) > 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) >> 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
