> On juin 27, 2016, 5 après-midi, Nikos Nikoleris wrote: > > src/mem/cache/tags/base_set_assoc.hh, line 218 > > <http://reviews.gem5.org/r/3502/diff/8/?file=56390#file56390line218> > > > > Would it make sense to move most of this code in the constructor? The > > flag sequentialAccess and the condition lookupLatency >= dataLantency > > shouldn't change during the simulation. > > Sophiane SENNI wrote: > I think this code should be left here. Because the total access latency > now depends on both tag_latency and data_latency, the value of the 'lat' > parameter specifying the access latency is not correct when the accessBlock() > function is called. As a result, the 'lat' value should be updated inside the > function depending on if it is a sequential or parallel access.
Regarding your suggestion, I am agree with you that it would be better to move the code in the constructor since as you mentioned the flag sequentialAccess and the access latency value should not change during the simulation. I will see how I can modify the patch accordingly. - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8441 ----------------------------------------------------------- On juin 28, 2016, 1:06 après-midi, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated juin 28, 2016, 1:06 après-midi) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11536:1a3a96d435ed > --------------------------- > mem: Split the hit_latency into tag_latency and data_latency > > If the cache access mode is parallel, i.e. "sequential_access" parameter > is set to "False", tags and data are accessed in parallel. Therefore, > the hit_latency is the maximum latency between tag_latency and > data_latency. On the other hand, if the cache access mode is > sequential, i.e. "sequential_access" parameter is set to "True", > tags and data are accessed sequentially. Therefore, the hit_latency > is the sum of tag_latency plus data_latency. > > > Diffs > ----- > > configs/common/Caches.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/Cache.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base_set_assoc.hh > 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/Tags.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > > Diff: http://reviews.gem5.org/r/3502/diff/ > > > Testing > ------- > > Tested using --Debug-flags=Cache > > > Thanks, > > Sophiane SENNI > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
