derek/gem5
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

mem: Split the hit_latency into tag_latency and data_latency

Browse Source 
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.

Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This commit is contained in:
Sophiane Senni
2016-11-30 17:10:27 -05:00
parent 047caf24ba
commit ce2722cdd9
15 changed files with 95 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
configs/example/memcheck.py
View File

@@ -153,7 +153,7 @@ for t, m in zip(testerspec, multiplier):
# Define a prototype L1 cache that we scale for all successive levels
proto_l1 = Cache(size = '32kB', assoc = 4,
hit_latency = 1, response_latency = 1,
tag_latency = 1, data_latency = 1, response_latency = 1,
tgts_per_mshr = 8)
if options.blocking:
@@ -175,7 +175,8 @@ for scale in cachespec[:-1]:
prev = cache_proto[0]
next = prev()
next.size = prev.size * scale
next.hit_latency = prev.hit_latency * 10
next.tag_latency = prev.tag_latency * 10
next.data_latency = prev.data_latency * 10
next.response_latency = prev.response_latency * 10
next.assoc = prev.assoc * scale
next.mshrs = prev.mshrs * scale