1 - AHB引言

在上篇文章文章我們已經分析了AMBA總線系列中的APB總線的優點和缺點。

缺點1： APB支持且僅支持一個主機

缺點2： APB兩個周期才能完成一個數據的傳輸，數據傳輸效率不高。

所以針對以上的缺點，ARM 開發了更高級的總線AHB，下文將詳述AHB基于APB的改進點，改進策略，以及AHB的協議運行機制。

1-1 背景

在[漫談AMBA總線-APB]文章中我們知道 只有一個水果店，只賣三種水果分別是：草莓藍莓和蘋果。 隨著該地區人數的上漲， 一個水果店（單主機） 已經不能滿足該地區的要求，又因為 水果店和廠商的配合時間太長（傳輸效率低） ，所以大家在商議之下，又開了一家水果店，兩家水果店獨立運營。在這樣的情況下，之前設計的 水果運輸總線（類比APB） 就不能滿足當前的需求，所以需要根據當前的需求重新定制水果運輸總線V2。

對于V2版本的水果運輸總線，在 尋求制定策略方面碰到很多問題 ，但是最主要的兩個問題如下：

**問題1 : ** 當水果店1和水果店2同時缺貨 ，所以 同時使用大喇叭廣播自己的訂單需求 ，那么供應廠商 由于兩個大喇叭同時通知，會聽不清訂單的需求，因為互相干擾 。

概念 1：總線碰撞（Bus Collision ）

由于水果店1和水果店2同時使用大喇叭廣播自己的需求，導致供貨商聽不清訂單需求，那么這次水果運輸的任務就算是失敗的。

類比：

在AHB總線里面，ARM在設計的時候就支持連接多個主機進行操作。當兩個或者兩個以上的主機同時發起數據操作的時候，那么總線就會產生混亂，導致數據傳輸失敗。

本質原因： 一條總線服務兩個主機，難免會產生沖突，比如兩個人同時打第三個人的電話，第三個人只能接其中某一個人的電話，主要是 資源沖突 。

解決方法：

（1） 給 每個水果店配套一個水果運輸總線 ，同時 供應廠商也再配套三個 ，專門為對應的水果店服務（因為供應商同時只能服務一家客戶），在IC設計中也叫 資源復制 。這種方案設計最簡單，但是耗費大量的資源。

（2） 當出現兩個水果店同時進行訂單需求的時候，水果店自己需要先確認 一下另一個水果店有沒有廣播 ，如果有，就等另一個水果店使用大喇叭廣播完畢，自己再使用大喇叭廣播，在總線協議中，這個動作也叫 總線偵聽 。

（3） 兩個水果店 不想派人力進行偵聽廣播（或者不具備條件） ，所以購買一個 仲裁設施 ，該設施對水果店進行等級分類，如果兩個水果店同時發起要求，那么最重要的水果店****先獲得使用這個仲裁設施的允許再使用大喇叭廣播（這個獲取仲裁設施的允許也叫獲取總線授權），等最重要的水果店完成訂單之后，仲裁設施再服務相對比較不重要的水果店，總線仲裁中 稱為優先級仲裁策略 。

結論： ARM在升級APB的時候，為了支持多主機，同時為了解決總線沖突的問題，引入了第三種解決方法（ 優先級仲裁 ），給每個主機分配不同的優先級，優先級高的主機先發送數據，優先級低的等待完成之后再進行數據發送。

PS：CAN總線，IIC總線使用的是第二種解決方法（總線偵聽）來解決總線碰撞的問題。一般來說，分布式總線比較傾向于使用第二種策略，集中式總線比較傾向于第三種（例如SOC片內總線）。

Q1 ：可能有同學會問，那 兩個水果店同時發起請求的幾率很小 ，有沒有必要引入優先級仲裁策略：

答：如果為了安全的完成數據的策略，即使這種情況出現的概率很小，但是也要考慮這種最壞的情況。同時同樣的問題，在SOC設計中遇到這種情況的概率相對較大。

問題2： 在上一版本水果運輸總線的時候， 水果店需要一箱水果 ，則廠家就需要 提供一次水果的運輸 ，水果店 再需要一箱 ，又得 再次提供一次水果的運輸 ，這就導致了水果店訂單小，但是經常發起訂單，浪費了廠家有效運輸的時間，因為****等待訂單和運輸是串行工作 ，先訂單發出再運輸再發出訂單再運輸 。

概念2：突發傳輸（Burst）

水果店發起請求的時候，不是按照一箱水果作為訂單的單位，而是10箱或者其他數目N個作為訂單請求(Burst類型)，雖然 廠家運輸單位是一箱（也就是一輛車只能運送1箱） ，但是廠家可以派出多輛車同時運輸，形成運輸的 車隊 （ 流水線 ），這樣 n拍運輸時間就基本滿足水果店的需求 ，而 之前是2n拍時間才能滿足需求 。所以這個方案需要水果店和水果廠家同時改進方案。

類比：

在AHB總線中，數據傳輸時基于Burst類型進行傳輸的，每次傳輸都是多個（總線位寬的）數據，通過數據形成多拍（流水的）效果，相比APB總線提升數據的傳輸效率。

這兩個點是AHB針對APB總線提升最大的兩個點 ，當然AHB為了兼容一些其他的問題，有自己獨立的一些信號，這個下面繼續討論。

在這里我們總結一下****多主機總線 的正式概念 ：

總線是被總線上所有的部件所共享的一組通路（連線），對于 支持多主機的總線 ，如果某一個主機想要與 其他的部件進行通信 （獲得數據），首先****需要 向總線內部的仲裁器發起使用總線的請求，獲得內部仲裁器授予所有權。 其次需要將地址（廠商名字）、數據（水果）、命令（進貨還是退貨）放到總線上，其他的部件對總線上的數據進行偵聽，檢查地址數據和命令的是否與自己相關，最后相關從機部件做出命令響應。

2 - AHB總線詳解

2-1 AHB在SOC內使用的部分：

如上圖：

CPU ： CPU是操作的發起者，CPU發起讀寫外設數據的操作。

DMA: DMA也是操作的發起者，DMA從一個部件搬移數據到另一個部件。

比如Mem 2 Mem 、 Mem 2 Peri 、 Peri 2 Mem 、Peri 2 Peri

AHB_interconnect(AHB_Bridge):

根據上文所說的總線協議和傳輸信號的要求，構建出來的設計實體，該實體首先 接收主機端發送過來的獨占AHB總線和通路的請求 ，其次根據內部的 仲裁算法拒絕或者授予該主機訪問總線的權利 。當主機端被授予訪問總線的權利時，該AHB_interconnect(AHB_Bridge)接收主機端的命令、數據、地址總線并傳播和生成相應的信號到外設。同時接收外設返回的數據并交付給主機端。

SLAVE：對AHB_interconnect輸出數據和指令進行響應。

**Q2 : **是否可以不需要AHB_interconnect，AHB_Interconect的作用是什么？

同上篇APB文章類似，當CPU只有一個外設，那么直接可以和外設相連，不需要AHB_Interconect。同時也不需要總線的仲裁邏輯，所以關于總線仲裁邏輯的接口直接根據信號狀態tie相應的值或者懸空。

當CPU需要連接多個外設的時候，且不止有一個主機（還有DMA）時，需要AHB_interconnect進行仲裁、路由、相應外設信號的生成。

2-2 AHB總線接口： （AMBA AHB 2.0）

AHB信號較多，相應功能也比較強大

從這張大表可以看出，為了克服APB的缺點從而支持多主機模式、提升效率操作****，所在 總線接口上付出的代價 。至少AHB總線位寬和信號個數遠遠超過了APB總線。

根據上面的AHB信號列表，結合之前的類比和概念我們基本上就知道AHB該怎么運行，相應的信號如何動作也有了一般的概念。

接下來會從這種總體傳輸的概念分析到AHB總線內部的時序邏輯和相關的具體操作，希望大家多多支持。