NoC總線架構拓撲介紹

路科驗證 2021-09-01 12:03

測試中斷？接觸漂移？5 道題找到根因 一站式破解芯片研發全流程痛點，西門子 EDA Forum 2026等你來

弄清了訪存的路徑，可能就會想到一個問題：處理器發出去的讀寫請求到底是個什么東西？要想搞清楚它，就需要引入總線。下文我拿ARM的AXI/ACE總線協議以及由它衍生的總線結構來展開討論。這兩個協議廣泛用于主流的手機芯片上，是第四代AMBA（Advanced Microcontroller Bus Architecture)標準。

簡單的總線就是一些地址線和數據線，再加一個仲裁器，就可以把處理器發過來的讀寫請求送到內存或者外設，再返回數據。在這個過程中，我們需要一個主設備，一個從設備，所有的傳輸都是主設備發起，從設備回應。讓我們把處理器和它包含的緩存看作一個主設備，把內存控制器看作從設備。處理器發起訪問請求，如果是讀，那么總線把這個請求（包括地址）送到內存控制器，然后等待回應。過了一段時間，內存控制器把內存顆粒里面讀出的數據交給總線，總線又把數據交給處理器。如果數據無誤（ECC或者奇偶校驗不出錯），那么這個讀操作就完成了。如果是寫，處理器把寫請求（包括地址）和數據交給總線，總線傳遞給內存控制器，內存控制器寫完后，給出一個確認。這個確認經由總線又回到了處理器，寫操作完成。

以上過程有幾個重點。第一，處理器中的單個讀指令，被分為了請求（地址），完成（數據）階段。寫指令也被分為了請求（地址，數據），完成（寫入確認）階段。第二，作為從設備，內存控制器永遠都無法主動發起讀寫操作。如果一定要和處理器通訊，比如發生了讀寫錯誤，那就得使用中斷，然后讓處理器來發起讀寫內存控制器狀態的請求。第三，未完成的讀寫指令就變成了OT，總線可以支持多個OT。然而，總線支持多OT并不表示處理器能發送這么多請求出來，尤其是讀。所以瓶頸可能還是在處理器。

我遇到過幾次這樣的情況，在跑某個驅動的時候，突然系統掛死。但是別的設備中斷還能響應，或者報個異常后系統又繼續跑了。如果我們把上文的內存控制器替換成設備控制器，那就不難理解這個現象了。假設處理器對設備發起讀請求，而設備沒有回應，那處理器就會停在那等待。我看到的處理器，包括PowerPC, ARM，都沒有針對這類情況的超時機制。如果沒有中斷，那處理器無法自己切換到別的線程(Linux等操作系統的獨占模式)，就會一直等待下去，系統看上去就掛住了。有些設備控制器可以自動探測這類超時，并通過中斷調用相應的異常或者中斷處理。在中斷處理程序中，可以報個錯，修改返回地址，跳過剛才的指令往下走，系統就恢復了。也有些處理器在觸發某類異常后能自動跳到下一行指令，避免掛死。但是如果沒有異常或者中斷發生，那就永遠掛在那。

繼續回到總線。在AXI/ACE總線協議中，讀和寫是分開的通道，因為他們之間并沒有必然聯系。更細一些，總線上規定了五個組，分別是讀操作地址（主到從），讀操作數據（從到主），寫操作地址（主到從），寫操作數據（主到從），寫操作確認（從到主）。讀和寫兩大類操作之間，并沒有規定先后次序。而在每一類操作之內的組之間，是有先后次序的，比如地址是最先發出的，數據隨后，可以有很多拍，形成突發操作。而確認是在寫操作中，從設備收到數據之后給出的。對內存控制器，必須在數據最終寫入到顆粒之后再給確認，而不是收到數據放到內部緩存中的時候。

對于同一個通道，如果收到連續的指令，他們之間的次序是怎么樣的呢？AXI/ACE協議規定，次序可以打亂。拿讀來舉例，前后兩條讀指令的數據返回是可以亂序的。這里包含了一個問題，總線怎么區分住前后兩讀條指令？很簡單，在地址和數據組里加幾根信號，作為標志符，來區分0-N號讀請求和完成。每一對請求和完成使用相同的標志符。有了這個標志符，就不必等前一個請求完成后才開始第二個請求，而是讓他們交替進行，這樣就可以實現總線的OT，極大提高效率。當然，也需要提供相應的緩沖來存儲這些請求的狀態。并且最大的OT數取決于緩沖數和標志符中小的那個。原因很簡單，萬一緩沖或者標志符用完了，但是所有的讀操作全都是請求，沒有一個能完成怎么辦？那只好讓新的請求等著了。于是就有了AXI/ACE總線的一條規則，同一個讀或者寫通道中，相同標志符的請求必須按順序完成。

有時候，處理器也會拿這個標志符作為它內部的讀寫請求標志符，比如Cortex-A7就是這么干的。這樣并不好，因為這就等于給自己加了限制，最大發出的OT不得大于總線的每通道標志符數。當一個處理器組里有四個核的時候，很可能就不夠用了，人為限制了OT數。

最后，讀寫通道之間是沒有規定次序的，哪怕標志相同。

看到這里可能會產生一個問題，讀寫指令里面有一個默認原則，就是相同地址，或者地址有重疊的時候，訪存必須是順序的。還有，如果訪問的內存類型是設備，那么必須保證訪存次序和指令一致。這個怎么在總線上體現出來呢？總線會檢查地址來保證次序，一般是內存訪問前后亂序地址不能64字節內，設備訪問前后亂序地址不能在4KB內。

在AXI/ACE中，讀和寫通道的比例是一比一。實際上，在日常程序中，讀的概率比寫要大。當然，寫緩存實際上伴隨著緩存行填充linefill（讀），而讀緩存會造成緩存行移除eviction（寫），再加上合并和次序調整，所以并不一定就是讀寫指令的比例。我看到Freescale PowerPC的總線CCB，讀寫通道的比率是二比一。我不知道為什么ARM并沒有做類似的設計來提高效率，也許一比一也是基于手機典型應用統計所得出的最好比例。

至此，我們已經能夠在腦海中想象一對讀寫通道中讀寫操作的傳輸情況了。那多個主從設備組合起來是怎么樣的情況？是不是簡單的疊加？這涉及到了總線設計最核心的問題，拓撲結構。

在ARM當前所有的總線產品里，根據拓撲的不同可以分為三類產品：NIC/CCI系列是交叉矩陣的（Crossbar），CCN系列是基于環狀總線的(Ring)，NoC系列是網狀總線(Mesh)。他們各有特點，適合不同場景。交叉矩陣連接的主從設備數量受到限制，但是效率最高，讀寫請求可以在1到2個周期內就直達從設備。如下圖所示，這就是一個5x4的交叉矩陣：

根據我看到的數據，在28納米制程上，5x4的配置下，這個總線的頻率可以跑到300Mhz。如果進一步增加主從對數量，那么由于扇出增加，電容和走線增加，就必須通過插入更多的寄存器來增加頻率。但這樣一來，從主到從的延遲就會相應增加。哪怕就是保持5x3的配置，要想進一步提高到500Mhz，要么使用更好的工藝，16納米我看到的是800Mhz；要么插入2-3級寄存器，這樣，讀寫延時就會達到4-5個總線時鐘周期，請求加完成來回總共需要10個。如果總線和處理器的倍頻比率為1:2，那么僅僅是在總線上花費的時間，就需要至少20個處理器時鐘周期。倍率為4，時間更長，40個時鐘周期。要知道處理器訪問二級緩存的延遲通常也不過10多個處理器周期。當然，可以通過增加OT數量減少平均延遲，可是由于處理器的OT數是有限制的，對于順序處理器，可能也就是1-2個。所以，要達到更高的頻率，支持更多的主從設備，就需要引入環狀總線CCN系列，如下圖：

CCN總線上的每一個節點，除了可以和相鄰的兩個節點通訊之外，還可以附加兩個節點組件，比如處理器組，三級緩存，內存控制器等。在節點內部，還是交叉的，而在節點之間，是環狀的。這樣使得總線頻率在某種程度上擺脫了連接設備數量的限制（當然，還是受布線等因素的影響），在16納米下，可以達到1.2GHz以上。當然，代價就是節點間通訊更大的平均延遲。為了減少平均延遲，可以把經常互相訪問的節點放在靠近的位置。

在有些系統里，要求連接更多的設備，并且，頻率要求更高。此時環狀總線也不夠用了。這時就需要NoC出馬了，如下圖：

這個圖中，剛才提到的交叉矩陣，可以作為整個網絡的某部分。而連接整個系統的，是位于NoC內的節點。每個節點都是一個小型路由，它們之間傳輸的，是異步的包。這樣，就不必維持路由和路由之間很大數量的連線，從而提高頻率，也能支持更多的設備。當然，壞處就是更長的延遲。根據我看到的數據，在16納米上，頻率可以跑到1.5Ghz。并且它所連接每個子模塊之間，頻率和拓撲結構可以是不同的。可以把需要緊密聯系的設備，比如CPU簇，GPU放在一個子網下減少通訊延遲。

不知你有沒有發現，以上每一種總線，都可以在網絡設備上找到原型。從設備直連，到環狀局域網，到交換和路由。他們的拓撲結構是相通的。

在實際的ARM生態系統中，以上三種拓撲結構的使用情況是怎么樣的呢？一般手機芯片上使用交叉矩陣，網絡處理器和服務器上使用環狀網絡，而網狀拓撲也被大量應用于手機芯片。最后一個的原因倒不是手機上需要連接的設備數太多，而是因為AXI/ACE協議都不支持一次傳輸拆分成多個，送給不同的內存控制器。這類傳輸有個名詞，叫做interleaving，交叉訪問。交叉訪問有很多定義，從總線角度看，一種是一個主設備和一個從設備之間的多個讀寫請求之間的完成次序可以打亂，這個我們已經解釋過。第二種是對于一個主設備的一次讀寫請求，把它分別送到多個從設備，并等待完成。為什么需要這種傳輸呢？因為在手機里面，GPU，顯示控制器，視頻控制器對內存帶寬要求是很高的。一個1080p的屏幕，每秒要刷新60次，2百萬個像素，每個像素32比特顏色，再加上8層圖層，就需要4GB/s的數據。而一個1.6GHz傳輸率的DDR3控制器，64位數據，也只能提供10GB/s的的理論帶寬。理論帶寬和實際帶寬由于各種因素的影響，會有很大差別，能做到70%的利用率就不錯了。那處理器怎么辦，其他各類控制器怎么辦？只有增加內存控制器的數量，也就是多放幾個從設備。但是，不能簡單的增加數量。原因是，如果僅僅把不同的物理地址請求發送到不同的內存控制器上，很可能在某段時間內，所有的物理地址全都是對應于其中某一個，還是不能滿足帶寬要求。解決方法就是，對于任何地址，都拆成多個請求，送到不同的內存控制器。并且這件事最好不是處理器來干（ARM的核都不支持拆分的讀寫），因為只有總線清楚有多少個內存控制器。最好處理器只管發請求，總線把所有請求拆分，并將數據收集完后，統一返回到處理器。

不幸的是，AXI/ACE總線天然就不支持一對多的交叉訪問。原因很簡單，會產生死鎖。想象一下，有兩個主設備，兩個從設備，通過交叉矩陣連接。M1發送兩個讀請求，標志符都是1，先后送到到S1和S2，并等待完成。然后M2也做同樣的事情，標志符都是2，先后送到S2和S1。此時，假設S2發現它如果把返回的數據次序交換一下，會更有效率，于是它就這么做了。但是M1卻不能接收S2的返回數據，因為根據同標志符必須順序完成的原則，它必須先等S1的返回數據。而S1此時也沒法送數據給M2，因為M2也在等待S2返回的數據，死鎖就出現了。解決方法是，任何一個主設備，不能同時發送請求到多個從設備。于是，就沒法實現多內存控制器的交叉訪問了。

而基于包傳輸的網狀總線就沒有這個問題，所有包都是異步的，不存在依賴關系。于是，出現了一家專門做NoC總線的公司Arteris，它們抓住這個機會，把支持多內存控制器同時訪問的總線賣到了大部分做手機和平板芯片的公司。而ARM到目前為止，雖然也有了解決方案Arachne，但是還沒什么實際應用。

現在的中低端手機很多都是8核，而根據ARM的設計，每個處理器組中最多有四個核。這就需要放兩個處理器組在系統中，而他們之間的通訊，包括大小核的實現，就需要用到總線一致性。每個處理器組內部也需要一致性，原理和外部相同，我就不單獨解釋了。使用軟件實可以現一致性，但是那樣需要手動的把緩存內容刷到下一級緩存或者內存，對于一個64字節緩存行的64KB緩存來說，需要1000次刷新，每次就算是100納秒，且OT=4的話，也需要25微秒。對處理器來說這是一個非常長的時間。ARM使用了一個協處理器來做這個事情，這是一個解決方案。為了用硬件解決，ARM引入了幾個支持硬件一致性的總線，下圖是第一代方案CCI400：

CCI400是怎么做到硬件一致性的呢？簡單來說，就是處理器組C1，發一個包含地址信息的特殊讀寫的命令到總線，然后總線把這個命令轉給另一個處理器組C2。C2收到請求后，根據地址逐步查找二級和一級緩存，如果發現自己也有，那么就返回數據或者做相應的緩存一致性操作，這個過程稱作snooping（監聽）。具體的操作我不展開，ARM使用MOESI一致性協議，里面都有定義。在這個過程中，被請求的C2中的處理器核心并不參與這個過程，所有的工作由緩存和總線接口單元BIU等部件來做。為了符合從設備不主動發起請求的定義，需要兩組主從設備，每個處理器組占一個主和一個從。這樣就可以使得兩組處理器互相保持一致性。而有些設備如DMA控制器，它本身不包含緩存，也不需要被別人監聽，所以它只包含從設備，如上圖桔黃色的部分。在ARM的定義中，具有雙向功能的接口被稱作ACE，只能監聽別人的稱作ACE-Lite。它們除了具有AXI的讀寫通道外，還多了個監聽通道，如下圖：

多出來的監聽通道，同樣也有地址（從到主），回應（主到從）和數據（主到從）。每組信號內都包含和AXI一樣的標志符，用來支持多OT。如果在主設備找到數據（稱為命中），那么數據通道會被使用，如果沒有，那告知從設備未命中就可以了，不需要傳數據。由此，對于上文的DMA控制器，它永遠不可能傳數據給別人，所以不需要數據組，這也就是ACE和ACE-Lite的主要區別。

我們還可以看到，在讀通道上有個額外的線RACK，它的用途是，當從設備發送讀操作中的數據給主，它并不知道何時主能收到這個數據，因為我們說過插入寄存器會導致總線延遲變長。萬一這個時候，對同樣的地址A，它需要發送新的監聽請求給主，就會產生一個問題：主是不是已經收到前面發出的地址A的數據了呢？如果沒收到，那它可能會告知監聽未命中。但實際上地址A的數據已經發給主了，它該返回命中。加了這個RACK后，從設備在收到主給的確認RACK之前，不會發送新的監聽請求給主，從而避免了上述問題。寫通道上的WACK同樣如此。

我們之前計算過NIC400上的延遲，有了CCI400的硬件同步，是不是訪問更快了呢？首先，硬件一致性的設計目的不是為了更快，而是軟件更簡單。而實際上，它也未必就快。因為給定一個地址，我們并不知道它是不是在另一組處理器的緩存內，所以無論如何都需要額外的監聽動作。當未命中的時候，這個監聽動作就是多余的，因為我們還是得從內存去抓數據。這個多余的動作就意味著額外的延遲，10加10一共20個總線周期，增長了100%。當然，如果命中，雖然總線總共上也同樣需要10周期，可是從緩存拿數據比從內存拿快些，所以此時是有好處的。綜合起來看，當命中大于一定比例，總體還是受益的。

可從實際的應用程序情況來看，除了特殊設計的程序，通常命中不會大于10%。所以我們必須想一些辦法來提高性能。一個辦法就是，無論結果是命中還是未命中，都讓總線先去內存抓數據。等到數據抓回來，我們也已經知道監聽的結果，再決定把哪邊的數據送回去。這個辦法的缺點，功耗增大，因為無論如何都要去讀內存。第二，在內存訪問本身就很頻繁的時候，這么做會降低總體性能。

另外一個方法就是，如果預先知道數據不在別的處理器組緩存，那就可以讓發出讀寫請求的主設備，特別注明不需要監聽，總線就不會去做這個動作。這個方法的缺點就是需要軟件干預，雖然代價并不大，分配操作系統頁面的時候設下寄存器就可以，可是對程序員的要求就高了，必須充分理解目標系統。

CCI總線的設計者們還使用了一個新的方法來提高性能。他們在總線里加入一個監聽過濾器(Snoop Filter)。這其實也是一塊緩存(TAG RAM)，把它所有處理器組內部一級二級緩存的狀態信息都放在里面。數據緩存(DATA RAM)是不需要的，因為它只負責查看命中與否。這樣做的好處就是，監聽請求不必發到各組處理器，在總線內部就可以完成，省了將近10個總線周期，功耗也優于訪問內存。它的代價是增加了一點緩存（一二級緩存的10%左右）。并且，如果監聽過濾器里的某行緩存被替換（比如寫監聽命中，需要無效化(Invalidate)緩存行，MOESI協議定義），同樣的操作必須在對應處理器組的一二級緩存也做一遍，以保持一致性。這個過程被稱作反向無效化，它添加了額外的負擔，因為在更新一二級緩存的時候，監聽過濾器本身也需要追蹤更新的狀態，否則就無法保證一致性。幸好，在實際測試中發現，這樣的操作并不頻繁，一般不超過5%的可能性。當然，有些測試代碼會頻繁的觸發這個操作，此時監聽過濾器的缺點就顯出來了。

以上的想法在CCI500中實現，示意圖如下：

在經過實際性能測試后，CCI設計人員發現總線瓶頸移到了訪問這個監聽過濾器的窗口，這個瓶頸其實掩蓋了上文的反向無效化問題，它總是先于反向無效化被發現。把這個窗口加大后，又在做測試時發現，如果每個主從接口都拼命灌數據(主從設備都是OT無限大，并且一主多從有前后交叉)，在主從設備接口處經常出現等待的情況，也就是說，明明數據已經準備好了，設備卻來不及接收。于是，又增加了一些緩沖來存放這些數據。其代價是稍大的面積和功耗。請注意，這個緩沖和存放OT的狀態緩沖并不重復。

根據實測數據，在做完所有改進后，新的總線帶寬性能同頻增加50%以上。而頻率可以從500Mhz提高到800Mhz。當然這個結果只是一個模糊的統計，如果我們考慮處理器和內存控制器OT數量有限，被監聽數據的百分比有不同，命中率有變化，監聽過濾器大小有變化，那肯定會得到不同的結果。

作為一個手機芯片領域的總線，需要支持傳輸的多優先級也就是QoS。因為顯示控制器等設備對實時性要求高，而處理器組的請求也很重要。支持QoS本身沒什么困難，只需要把各類請求放在一個緩沖，根據優先級傳送即可。但是在實際測試中，發現如果各個設備的請求太多太頻繁，緩沖很快就被填滿，從而阻塞了新的高優先級請求。為了解決這個問題，又把緩沖按優先級分組，每一組只接受同等或更高優先級的請求，這樣就避免了阻塞。這些方法和網絡防擁塞設計如出一轍。

此外，為了支持多時鐘和電源域，使得每一組處理器都可以動態調節電壓和時鐘頻率，CCI系列總線還可以搭配異步橋ADB(Asynchronous Domain Bridge)。它對于性能有一定的影響，在倍頻是2的時候，信號穿過它需要一個額外的總線時鐘周期。如果是3，那更大些。在對于訪問延遲有嚴格要求的系統里面，這個時間不可忽略。如果不需要額外的電源域，我們可以不用它，省一點延遲。NIC/CCI/CCN/NoC總線天然就支持異步傳輸。

和一致性相關的是訪存次序和鎖，有些程序員把它們搞混了。假設我們有兩個核C0和C1。當C0和C1分別訪問同一地址A0，無論何時，都要保證看到的數據一致，這是一致性。然后在C0里面，它需要保證先后訪問地址A0和A1，這稱作訪問次序，此時不需要鎖，只需要壁壘指令。如果C0和C1上同時運行兩個線程，當C0和C1分別訪問同一地址A0，并且需要保證C0和C1按照先后次序訪問A0，這就需要鎖。所以，單單壁壘指令只能保證單核單線程的次序，多核多線程的次序需要鎖。而一致性保證了在做鎖操作時，同一變量在緩存或者內存的不同拷貝，都是一致的。

ARM的壁壘指令分為強壁壘DSB和弱壁壘DMB。我們知道讀寫指令會被分成請求和完成兩部分，強壁壘要求上一條讀寫指令完成后才能開始下一個請求，弱壁壘則只要求上一條讀寫指令發出請求后就可以繼續下一條讀寫指令的請求，且只能保證，它之后的讀寫指令完成時，它之前的讀寫指令肯定已經完成了。顯然，后一種情況性能更高，OT>1。但測試表明，多個處理器組的情況下，壁壘指令如果傳輸到總線，只能另整體系統性能降低，因此在新的ARM總線中是不支持壁壘的，必須在芯片設計階段，通過配置選項告訴處理器自己處理壁壘指令，不要送到總線。但這并不影響程序中的壁壘指令，處理器會在總線之前把它過濾掉。

具體到CCI總線上，壁壘機制是怎么實現的呢？首先，壁壘和讀寫一樣，也是使用讀寫通道的，只不過它地址總是0，且沒有數據。標志符也是有的，此外還有額外的2根線BAR0/1，表明本次傳輸是不是壁壘，是哪種壁壘。他是怎么傳輸的呢？先看弱壁壘，如下圖：

Master0寫了一個數據data，然后又發了弱壁壘請求。CCI和主設備接口的地方，一旦收到壁壘請求，立刻做兩件事，第一，給Master0發送壁壘響應；第二，把壁壘請求發到和從設備Slave0/1的接口。Slave1接口很快給了壁壘響應，因為它那里沒有任何未完成傳輸。而Slave0接口不能給壁壘響應，因為data還沒發到從設備，在這條路徑上的壁壘請求必須等待，并且不能和data的寫請求交換次序。這并不能阻撓Master0發出第二個數據，因為它已經收到它的所有下級(Master0接口)的壁壘回應，所以它又寫出了flag。如下圖：

此時，flag在Master0接口中等待它的所有下一級接口的壁壘響應。而data達到了Slave0后，壁壘響應走到了Master0接口，flag繼續往下走。此時，我們不必擔心data沒有到slave0，因為那之前，來自Slave0接口的壁壘響應不會被送到Master0接口。這樣，就做到了弱壁壘的次序保證，并且在壁壘指令完成前，flag的請求就可以被送出來。

對于強壁壘指令來說，僅僅有一個區別，就是Master0接口在收到所有下一級接口的壁壘響應前，它不會發送自身的壁壘響應給Master0。這就造成flag發不出來，直到壁壘指令完成。如下圖：

這樣，就保證了強壁壘完成后，下一條讀寫指令才能發出請求。此時，強壁壘前的讀寫指令肯定是完成了的。

另外需要特別注意的是，ARM的弱壁壘只是針對顯式數據訪問的次序。什么叫顯式數據訪問？讀寫指令，緩存，TLB操作都算。相對的，什么是隱式數據訪問？在處理器那一節，我們提到，處理器會有推測執行，預先執行讀寫指令；緩存也有硬件預取機制，根據之前數據訪問的規律，自動抓取可能用到的緩存行。這些都不包含在當前指令中，弱壁壘對他們無能為力。因此，切記，弱壁壘只能保證你給出的指令次序，并不能保證在它們之間沒有別的模塊去訪問內存，哪怕這個模塊來自于同一個核。

簡單來說，如果只需要保證讀寫次序，用弱壁壘；如果需要某個讀寫指令完成才能做別的事情，用強壁壘。以上都是針對普通內存類型。當我們把類型設成設備時，自動保證強壁壘。

我們提到，壁壘只是針對單核。在多核多線程時，哪怕使用了壁壘指令，也沒法保證讀寫的原子性。解決辦法有兩個，一個是軟件鎖，一個是原子操作。原子操作我看到過的有兩種，一種是總線收到請求時，直接封掉整個總線，同時只有一個核能訪問。這樣效率很低。還有個方法是把鎖的請求發送到對端設備，比如內存控制器，讓他禁止別的核的訪問，而總線依然可以運行，這樣效率就高不少，我看到過的數據，減少10倍時間。但是AXI/ACE協議不支持原子操作。所以需要用到軟件鎖。

軟件鎖中有個自旋鎖，能用一個ARM硬件機制exclusive access來實現。當使用特殊指令對一個地址寫入值，相應緩存行上會做一個特殊標記，表示還沒有別的核去寫這行緩存。然后下條指令讀這個行，如果標記沒變，說明寫和讀之間沒有人打擾，那么就拿到鎖了。如果變了，那么回到寫的過程重新獲取鎖。由于緩存一致性，這個鎖變量可以被多個核與線程使用。當然，過程中還是需要壁壘指令來保證次序。

對于普通內存，還會產生一個問題，就是讀寫操作可能會經過緩存，你不知道數據是否最終寫到了內存中。通常我們使用clean操作來刷緩存。但是刷緩存本身是個模糊的概念，緩存存在多級，有些在處理器內，有些在總線之后，到底刷到哪里算是終結呢？還有，為了保證一致性，刷的時候是不是需要通知別的處理器和緩存？為了把這些問題規范化，ARM引入了Point of Unification/Coherency，Inner/Outer Cacheable和System/Inner/Outer/Non Shareable的概念。

PoU是指，對于某一個核Master，附屬于它的指令，數據緩存和TLB，如果在某一點上，它們能看到一致的內容，那么這個點就是PoU。如上圖右側，MasterB包含了指令，數據緩存和TLB，還有二級緩存。指令，數據緩存和TLB的數據交換都建立在二級緩存，此時二級緩存就成了PoU。而對于上圖左側的MasterA，由于沒有二級緩存，指令，數據緩存和TLB的數據交換都建立在內存上，所以內存成了PoU。

PoC是指，對于系統中所有Master（注意是所有的，而不是某個核），如果存在某個點，它們的指令，數據緩存和TLB能看到同一個源，那么這個點就是PoC。如上圖右側，二級緩存此時不能作為PoC，因為MasterB在它的范圍之外，直接訪問內存。所以此時內存是PoC。在左圖，由于只有一個Master，所以內存是PoC。

再進一步，如果我們把右圖的內存換成三級緩存，把內存接在三級緩存后面，那PoC就變成了三級緩存。

有了這兩個定義，我們就可以指定緩存操作和讀寫指令到底發到哪個范圍。比如在下圖的系統上，有兩組A15，每組四個核，組內含二級緩存。系統的PoC在內存，而A15的PoU分別在它們自己組內的二級緩存上。在某個A15上執行Clean清指令緩存，范圍指定PoU。顯然，所有四個A15的一級指令緩存都會被清掉。那么其他的各個Master是不是受影響？那就要用到Inner/Outer/Non Shareable。

Shareable的很容易理解，就是某個地址的可能被別人使用。我們在定義某個頁屬性的時候會給出。Non-Shareable就是只有自己使用。當然，定義成Non-Shareable不表示別人不可以用。某個地址A如果在核1上映射成Shareable，核2映射成Non-Shareable，并且兩個核通過CCI400相連。那么核1在訪問A的時候，總線會去監聽核2，而核2訪問A的時候，總線直接訪問內存，不監聽核1。顯然這種做法是錯誤的。

對于Inner和Outer Shareable，有個簡單的的理解，就是數據共享屬于Outer Shareable；指令和TLB等只讀的共享，屬于Inner Shareable，也屬于Outer Shareable。在上圖的系統中，A15和A7共享指令，它們之間是Inner Shareable。當然，他們數據也是共享的，所以也是Outer Shareable。而DMA， Mali和處理器之間，就只有數據是共享的，所以不是Inner Shareable，而是Outer Shareable。

我們在集成A15/A7等ARM處理器到SoC系統的時候，是需要設置Inner和Outer Shareable屬性的。設了Inner，就表示指令操作和指令緩存，TLB等只讀的訪問會被送到總線。設了Outer，就表示數據操作，數據緩存的訪問會被送到總線。且如果設了Outer，必須設置Inner。反之不必。正常情況是這兩個都設上。

說了這么多概念，你可能會想這有什么用處？回到上文的Clean指令，PoU使得四個A7的指令緩存中對應的行都被清掉。由于是指令緩存操作，Inner Shareable屬性使得這個操作被擴散到總線。而CCI400總線會把這個操作廣播到所有可能接受的口上。ACE口首當其沖，所以四個A15也會清它們對應的指令緩存行。對于Mali和DMA控制器，他們是ACE-Lite，本不必清。但是請注意它們還連了DVM接口，專門負責收發緩存維護指令，所以它們的對應指令緩存行也會被清。不過事實上，它們沒有對應的指令緩存，所以只是接受請求，并沒有任何動作。

你可能又會想，我們要這么復雜的定義有什么用？用處是，精確定義緩存維護和讀寫指令的范圍。如果我們改變一下，總線不支持Inner/Outer Shareable的廣播，那么就只有A7處理器組會清緩存行。顯然這么做在邏輯上不對，因為A7/A15可能運行同一行代碼。并且，我們之前提到過，如果把讀寫屬性設成Non-Shareable，那么總線就不會去監聽其他主，減少訪問延遲，這樣可以非常靈活的提高性能。

再回到前面的問題，刷某行緩存的時候，怎么知道數據是否最終寫到了內存中？對不起，非常抱歉，還是沒法知道。你只能做到把范圍設成PoC。如果PoC是三級緩存，那么最終刷到三級緩存，如果是內存，那就刷到內存。不過這在邏輯上沒有錯，按照定義，所有Master如果都在三級緩存統一數據的話，那就不必刷到內存了。

簡而言之，PoU/PoC定義了指令和命令的所能抵達的緩存或內存，在到達了指定地點后，Inner/Outer Shareable定義了它們被廣播的范圍。

再來看看Inner/Outer Cacheable，這個就簡單了，僅僅是一個緩存的前后界定。一級緩存一定是Inner Cacheable的，而最外層的緩存，比如三級，可能是Outer Cacheable，也可能是Inner Cacheable。他們的用處在于，在定義內存頁屬性的時候，可以在不同層的緩存上有不同的處理策略。

在ARM的處理器和總線手冊中，還會出現幾個PoS(Point of Serialization)。它的意思是，在總線中，所有主設備來的各類請求，都必須由控制器檢查地址和類型，如果存在競爭，那就會進行串行化。這個概念和其他幾個沒什么關系。

縱觀整個總線的變化，還有一個核心問題并沒有被提及，那就是動態規劃re-scheduling與合并Merging。處理器和內存控制器中都有同樣的模塊，專門負責把所有的傳輸進行分類，合并，調整次序，甚至預測未來可能接收到的讀寫請求地址，以實現最大效率的傳輸。這個問題在分析性能時會重新提到。但是在總線這層，軟件能起的影響很小。清楚了總線延遲和OT最大的好處是可以和性能計數器的統計結果精確匹配，看看是不是達到預期了。

本文轉自：https://www.zhihu.com/people/zhong-zou-ci-jian-lu

本文內容僅代表作者觀點，不代表平臺觀點。

如有任何異議，歡迎聯系我們。

登錄閱讀全文

