Hello Liang,
The cache timing model is something that me, Jason and Nikos have been recently
discussing. You can follow part of the discussion on the following links:
https://gem5-review.googlesource.com/c/public/gem5/+/13697 and
https://gem5-review.googlesource.com/c/public/gem5/+/13835.
Reworking the timing model to be more accurate and flexible is a hard task, and
you will likely just want to modify code related to timing, as the latency in
atomic mode is not well defined (in the sense of how correct it should be;
There is no clear answer). I'd suggest you to look at these patches and their
evolution to have and idea of the decisions that you may or may not want to
take (I am not saying they are the right way to do it, though).
Regarding the Tags, we currently have 3 sub-classes: BaseSetAssoc, FALRU and
SectorTags. Although we can think of FALRU as a subset of BaseSetAssoc (and you
can definitely create a full associative tag using BaseSetAssoc), FALRU has its
own implementation, which leverages from hashes and the awareness of a single
replacement policy (LRU), because otherwise the cost of checking every block
would be too high for greater cache sizes.
Regards,Daniel
Em sexta-feira, 9 de novembro de 2018 22:00:59 GMT+1, 梁政
<liangzh...@pku.edu.cn> escreveu:
Hi
I am reading the latest code of gem5 and try to make the cache model more
flexible (e.g., allowing non-constant access latency). So I will change the
timing behavior of the Cache class.
Currently, I am reading the code in /mem/cache. I found that two major classes
have their timing model: the Cache/NoncoherentCache/BaseCache family and the
Tag family.
So what I need to do is to change related codes with a device timing model,
right? Or there may be other points I missed? Thanks for your advice.
BTW, what are the FALRU tags for? It seems all configurations use SetAssoc
Tags. I found a paper from UC.Berkeley. It is related to Sector Cache. Maybe
someone will use that model in the future. But why should Fully-associative LRU
cache be considered separately?
Regards
Zheng Liang
EECS, Peking University
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
