> On July 27, 2016, 4:52 p.m., Andreas Hansson wrote: > > src/mem/cache/tags/base_set_assoc.hh, line 228 > > <http://reviews.gem5.org/r/3502/diff/12/?file=57342#file57342line228> > > > > 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? > > Sophiane SENNI wrote: > I actually don't really understand what this code represents, which was > already present before applying the patch. Because it seems to show a case > where the cache latency is greater than accessLatency, when the lat variable > is updated as follows: > lat = cache->ticksToCycles(blk->whenReady - curTick()) > Can this situation actually occur ?
blk->whenReady represents the fact that the block is technically not available yet. Due to how we do timing modelling we annotate the block when it arrives, but have to remember when it is _actually_ availalbe. Thus, anything we do here should add on top of the blk->whenReady. Same for fa_lru - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8552 ----------------------------------------------------------- On July 28, 2016, 10:31 a.m., Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated July 28, 2016, 10:31 a.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 > ----- > > configs/common/Caches.py 4aac82f109517217e6bfb3812689280e7a8fa842 > configs/common/O3_ARM_v7a.py 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/Cache.py 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/base.hh 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/base.cc 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/tags/Tags.py 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/tags/base.hh 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/tags/base.cc 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/tags/base_set_assoc.hh > 4aac82f109517217e6bfb3812689280e7a8fa842 > src/mem/cache/tags/fa_lru.cc 4aac82f109517217e6bfb3812689280e7a8fa842 > > Diff: http://reviews.gem5.org/r/3502/diff/ > > > Testing > ------- > > Tested using --Debug-flags=Cache > > > Thanks, > > Sophiane SENNI > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
