最近在总结Cache相关的东西，看到Gem5里面关于Cache相关的资料，觉得还是比较完整的. 其对cache的抽象是通过Ruby/C++/Python 来完成的，专门为Cache开发了一个描述语言SLICC，类似C++，Python语言编写其Complier。基本的这些语法糖，就不谈了，直说干货。
现在谈谈阅后感：
MSI Cache Controller和 MSI Directory Controller的特点:
S cache 不提供数据（可以提供，要看具体实现，只是这个实现为了简单不支持）
M cache 的数据提供数据（无论是GetM/GetS,这个M是系统中唯一的最新数据，肯定要提供）
Gem5 MSI Example Cache protocol
Gem5 MSI Directory Implementation
小结
- 这个实现的简单之处在于，S cache 不提供数据: HN中S 态,在收到RN GetM/GetS的时候，虽然知道up stream RN有数据（不考虑Silent），但是HN还是从Memory 里面读，不让RN fwd S态数据。这个原因是HN要充当「管理"角色，RN fwd path的一定要让HN知道的，不然一致性会出问题，Global Order不能保证。
- M 提供数据： HN中M态，访问权限是Invalid的，最新数据在upsteam RN，
- 收到RN的 GetS， HN自己没有办法独立完成，所以要Fwd给M态RN，RN 的数据提供Original RN，并且给HN(这是维护S态语义的需要，也是HN充当「管理角色」的需要)
- 收到RN的GetM，HN把目录sharelist,ownerlist更新一下，HN不保证fwd是否完成，HN如果继续FwdGetM/FwdGetS 到一个IM D,SM_D的RN上，此RN会Stall这个请求（和ACE不一样，Fwd*是可以在RN阻塞的，就是因为clean的数据都是从Memory里面取，不会形成Depency Cycle）
- 这个实现的简单之处还在于，一致性请求只有GetM/GetS，没有像ACE/CHI，那种ReadUnique/CLeanUnique/MakeUnique只有GetM
- 变I态，只有cache replacement 才会引入暂态。S态和M态如果不是replacement,收到inv/FwdGetM就直接变成I态.
- 不支持slient clean cacheline.
- I态toM态相关的暂态，收到Directory 的Data或者peer RN的data，已经peer RN的Inv_Ack
- M态toI态相关的暂态, 最新数据还在这里，有人需要，还是要提供，说明RN此时的race已经失败。
