----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8552 -----------------------------------------------------------
src/mem/cache/tags/Tags.py (line 57) <http://reviews.gem5.org/r/3502/#comment7437> Why would the tags care about the data latency? src/mem/cache/tags/base.hh (line 75) <http://reviews.gem5.org/r/3502/#comment7438> Seems odd that the tags need to track this. Is this still the best division? Perhaps explain why it's here. src/mem/cache/tags/base_set_assoc.hh (line 227) <http://reviews.gem5.org/r/3502/#comment7439> Could you add a comment here? It seems to me this code is not right, as it checks if the data is technically written now, but we only need the data at time T. Should we not rather add the dataLatency to the blk->whenReady and then do the plus or max opteration? src/mem/cache/tags/fa_lru.cc (line 188) <http://reviews.gem5.org/r/3502/#comment7440> here we don't care about blk->whenReady? Some minor concerns that hopefully make sense. - Andreas Hansson On July 25, 2016, 1:16 p.m., Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated July 25, 2016, 1:16 p.m.) > > > 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 > ----- > > src/mem/cache/tags/fa_lru.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > 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 > > 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
