[Cache一致性模型：GEM5 MSI/MSI

最近在總結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

小結

1. 這個實作的簡單之處在於，S cache 不提供數據: HN中S 態,在收到RN GetM/GetS的時候，雖然知道up stream RN有數據（不考慮Silent），但是HN還是從Memory 裏面讀，不讓RN fwd S態數據。這個原因是HN要充當「管理"角色，RN fwd path的一定要讓HN知道的，不然一致性會出問題，Global Order不能保證。
2. M 提供數據： HN中M態，存取許可權是Invalid的，最新數據在upsteam RN，
1. 收到RN的 GetS， HN自己沒有辦法獨立完成，所以要Fwd給M態RN，RN 的數據提供Original RN，並且給HN(這是維護S態語意的需要，也是HN充當「管理角色」的需要)
2. 收到RN的GetM，HN把目錄sharelist,ownerlist更新一下，HN不保證fwd是否完成，HN如果繼續FwdGetM/FwdGetS 到一個IM D,SM_D的RN上，此RN會Stall這個請求（和ACE不一樣，Fwd*是可以在RN阻塞的，就是因為clean的數據都是從Memory裏面取，不會形成Depency Cycle）
3. 這個實作的簡單之處還在於，一致性請求只有GetM/GetS，沒有像ACE/CHI，那種ReadUnique/CLeanUnique/MakeUnique只有GetM
4. 變I態，只有cache replacement 才會引入暫態。S態和M態如果不是replacement,收到inv/FwdGetM就直接變成I態.
5. 不支持slient clean cacheline.

1. I態toM態相關的暫態，收到Directory 的Data或者peer RN的data，已經peer RN的Inv_Ack
2. M態toI態相關的暫態, 最新數據還在這裏，有人需要，還是要提供，說明RN此時的race已經失敗。