> On juil. 27, 2016, 4:52 après-midi, 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 ? > > Andreas Hansson wrote: > 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
Ok. So if I understood, we actually need to apply the accessLatency on top of the blk->whenReady. Hence, the good code would be as follows: if (blk->whenReady > curTick() && cache->ticksToCycles(blk->whenReady - curTick()) > accessLatency) { lat = cache->ticksToCycles(blk->whenReady - curTick()) + accessLatency; } Does this change make more sense ? - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8552 ----------------------------------------------------------- On juil. 28, 2016, 10:31 matin, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated juil. 28, 2016, 10:31 matin) > > > 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev