> 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.
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. > On juin 27, 2016, 5 après-midi, Nikos Nikoleris wrote: > > src/mem/cache/tags/fa_lru.cc, line 212 > > <http://reviews.gem5.org/r/3502/diff/8/?file=56392#file56392line212> > > > > Same here Same here - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8441 ----------------------------------------------------------- On juin 20, 2016, 3:07 après-midi, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated juin 20, 2016, 3:07 après-midi) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11536:1a3a96d435ed > --------------------------- > cache: Split the hit latency into tag lookup latency and data access latency > > If the cache access mode is parallel ("sequential_access" parameter set to > "False"), tags and data are accessed in parallel. Therefore, the hit latency > is the maximum latency between tag lookup latency and data access latency. On > the other hand, if the cache access mode is sequential ("sequential_access" > parameter set to "True"), tags and data are accessed sequentially. Therefore, > the hit latency is the sum of tag lookup latency plus data access latency. > > > Diffs > ----- > > configs/common/Caches.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/Cache.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/Tags.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base_set_assoc.hh > 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.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
