之前文章為大家介紹了AHB的基本結構,信號以及基本傳輸,這次續上次文章,繼續為大家介紹AHB總線
內容概括
這次為大家講述的內容包括:
AHB傳輸類型
突發操作
仲裁
01
AHB傳輸類型
每個傳輸都可以分類為四個不同類型之一,如HTRANS[1:0]信號所示狀態,詳解如下:
HTRANS[1:0] | 傳輸類型 | Description |
---|---|---|
00 | IDLE | 主設備占用總線,但沒進行傳輸兩次突發傳輸中間主設備可發IDLE。此時就算從機被使能,也不會從總線上獲取任何的數據信號。如果此時從機被選中,那么每一個IDLE周期從機都要通過HRESP[1:0]返回一個OKAY響應 |
01 | BUSY | 主設備占用總線,但是在突發傳輸過程中還沒有準備好進行下一次傳輸。一次突發傳輸中間主設備可發BUSY這時從機不會從總線上收取數據而是等待,并且通過HRESP[1:0]返回一個OKAY響應。需要注意的是,這個傳輸需要給出下一拍的地址和控制信號,盡管從機不會去采樣。 |
10 | NONSEQ | 表明一次單個數據的傳輸或者一次突發傳輸的第一個數據地址和控制信號與上一次傳輸無關 |
11 | SEQ | 突發傳輸中剩下的傳輸是連續傳輸并且地址是和前一次傳輸有關的??刂?a target="_blank">信息和前一次傳輸一樣。地址等于前一次傳輸的地址加上傳輸大?。ㄗ止潱?。在回環突發的情況下傳輸地址在地址邊界處回環,回環值等于傳輸大小乘以傳輸的次數(4、 8 或者 16 其中之一)。 |
圖2 表示了一組用到不同傳輸類型:
圖2
- 第一個傳輸是一次突發的開始所以傳輸類型為非連續;
- 主機不能立刻執行突發的第二次傳輸所以主機使用了忙傳輸來延時下一次傳輸的開始。在這個例子中主機在它準備還突發的下一次傳輸之前僅請求了一個忙周期,下一次傳輸的完成沒有等狀態;
- 主機立刻執行突發的第三次傳輸,但是這時從機不能完成(傳輸)并用 HREADY來插入一個等待狀態;
- 突發的最后一個傳輸以無等待狀態完成;
02
突發操作
AMBA AHB 協議定義了四、八和十六拍突發,也有未定長度的突發和信號傳輸。協議支持增量和回環操作:
**增量突發**訪問連續地址并且突發中的每次傳輸地址僅是前一次地址的一個增量;對于 **回環突發** ,如果傳輸的起始地址并未和突發(x 拍)中字節總數對齊那么突發傳輸地址將在達到邊界處回環。例如,一個四拍回環突發的字(4 字節)訪問將在16 字節邊界回環。因此,如果傳輸的起始地址是 0x34,那么它將包含四個到地址
0x34、 0x38、 0x3C 和 0x30;
突發信息通過使用 HBURST[2:0]并且 8 種可能的類型在中定義如下:
HBURST[2:0] | 類型 | 描述 |
---|---|---|
000 | SINGLE | 單一傳輸 |
001 | INCR | 未指定長度的增量突發 |
010 | WRAP4 | 4拍回環突發 |
011 | INCR4 | 4拍增量突發 |
100 | WRAP8 | 8拍回環突發 |
101 | INCR8 | 8拍增量突發 |
110 | WRAP16 | 16拍回環突發 |
111 | INCR16 | 16拍增量突發 |
突發禁止超過 1KB 的地址邊界。 因此重要的是主機不要嘗試發起一個將要超過這個邊界的定長增量突發。將執行單個傳輸時使用未指定長度的增量突發理解為長度為一的突發比較合理。
一個增量突發可以是任何長度,但是(長度)上限由地址不能超過 1KB 邊界這個事實限定了。
注:突發大小表示突發的節拍數量,并不是一次突發傳輸的實際字節數量。一次突發傳輸的數據總量可以用節拍數乘以每拍數據的字節數來計算,每拍字節數由 HSIZE[2:0]指示。所有突發傳輸必須將地址邊界和傳輸大小對齊。例如,字傳輸必須對齊到字地址邊界(也就是 A[1:0] = 00),半字傳輸必須對齊到半字地址邊界(也就是 A[0] = 0)。
當一個突發不允許完成的特定情況下,對任一從機設計而言,如果突發提前終止那么利用突發信息能夠采取正確的動作顯得很重要。從機能夠通過監控 HTRANS 信號決定一個突發何時提前終止并且確保在突發開始之后每次傳輸有連續或者忙的標記。如果產生一個非連續或者空閑傳輸那么這表明一個新的突發已經開始因此前一次突發一定已經終止。
如果總線主機因為失去對總線的占有而不能完成一次突發那么它必須在下一次獲取訪問總線時正確地重建突發。例如,如果一個主機僅完成了一個四拍突發的一拍那么它必須用一個未定長度突發來執行剩下的三拍突發。
下圖表示了一個四拍回環突發并且第一次傳輸伴隨一個附加等待狀態。
0****3
仲裁
仲裁機制被用來確保任意時刻只有一個主機能夠訪問總線。仲裁器的功能是檢測許多不同的使用總線的請求和決定當前請求總線的主機中哪—個的優先級最高。仲裁器也接收來自從機需要完成 SPIIT 傳輸的請求。
任何沒有能力執行 SPLIT 傳輸的從機不需要了解仲裁的過程,除非它們需要檢測因為總線所有權改變而導致突發傳輸不能完成的情況。
以下給出對每個仲裁信號的簡短描述:
HBUSREQx 被總線主機用來請求訪問總線的總線請求信號。每個總線主機都有自己的連接到仲裁器的 HBUSREQx 信號并且任何一個系統中都可以有高達16個獨立的總線主機。
**HLOCKx **由主機在請求總線的同時時斷言的鎖定信號。這提示仲裁器主機正在執行一系列不可分割的傳輸并且一旦鎖定傳輸的第一個傳輸,己經開始仲裁器不能授子任何其他主機訪問總線。HLOCKx必須在涉及到的地址被尋址到之前至少斷言一個周期,以防止仲裁器改變授子信號。
**HGRANTx **授子信號由仲裁器產生并且表示相關主機是當前請求總線的主機中優先級最高的主機,(優先)考慮鎖定傳輸和 SPLIT 傳輸。主機在 HGRANTx 為高時獲取地址總線的所有權并且在HCLK 的上升沿 HREADY 為高電平。
**HIVIASTER[3:0] **仲裁器使用 HMASTER[3:0]信號表示哪一個主機當前被授子總線并且該信號可被用來控制中央地址和控制多路選擇器。有SFLIT 傳輸能力的從機也可以請求主機的序號以便它們能夠提示仲裁器哪個主機能夠完成一個SFLIT 傳輸。
HMASTLOCK仲裁器通過斷言 HVASTLOCK 信號指示當前傳輸是一個鎖定序列的一部分,該信號和地址以及控制信號有相同的時序。
HSPLIT [15: 0] 這16位有完整分塊能力的總線被有分塊(SFLIT)能力的從機用來指示哪個總線主機能夠完成一個 SPLIT 傳輸。仲裁器需要這些信息以便于授子主機訪問總線完成傳輸。
-
半導體
+關注
關注
334文章
27367瀏覽量
218765 -
soc
+關注
關注
38文章
4165瀏覽量
218272 -
AMBA總線
+關注
關注
0文章
35瀏覽量
9553
發布評論請先 登錄
相關推薦
評論