> 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
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
