以下文章來源于AdriftCoreFPGA芯研社，作者CNL中子

前言

在 SoC、FPGA IP、外設控制器等系統中，配置通路(Configuration Bus) 幾乎無處不在——寄存器讀寫、狀態回讀、DMA 觸發、控制接口、模塊初始化這些都離不開一條穩定可靠的配置總線。

在實際設計中，工程師往往需要在 APB、AHB、AXI-Lite 之間做權衡與選擇。

然而，這三種協議各有優點，也各自帶著不容忽視的工程痛點。

雖然配置通路本身屬于低速域，看起來不復雜，但真正落地到幾十個外設、跨時鐘域、壓 timing、做slice、處理讀寫語義一致性時，往往會暴露出各種棘手問題。

本文將基于實際工程經驗，討論 APB / AHB / AXI-Lite 在真實項目中的常見痛點和使用場景。如果你有不同的觀點、踩過更深刻的坑，或有更好的架構方法，歡迎在評論區一起交流。

APB

APB 可以說是最簡單的一類總線協議，在眾多 IC 設計和 FPGA 項目中都被大量使用。它無流水、無突發，控制信號少、時序關系簡單，在所有常見總線中資源占用理論上最小。其優點是簡單、穩定、易集成;缺點同樣明顯：帶寬與性能有限。

在大多數配置場景中，只是寫寄存器、回讀狀態，對性能需求并不高，因此 APB 能在各類 SoC 中存活超過 20 年也就不足為奇。

然而，APB 的簡單只在系統規劃良好的前提下成立。當初期沒有做好 APB slave地址空間的規劃，例如一個 master 需要連接幾十路 slave 時，復雜度就會急劇上升。

時序收斂難度陡增

APB 信號數量雖然不多，但組合邏輯比例很大。當你把幾十路 PSEL、讀寫分配、多路選擇器等全部堆在一個大型crossbar中，綜合之后會出現典型問題：

? 長組合路徑鏈條過多

? 分布式邏輯跨區域布局

? 極高的 Fanout

? 全局走線拉得非常長

最終結果很容易是：時序全面崩壞。

APB 極不適合做slice/pipeline

在 SoC 中通過切關鍵路徑插一拍，是傳統且有效的時序優化手段。但 APB 具有一些獨特缺陷，使得 pipeline 十分困難：

? APB 沒有完整的握手機制

? 時序依賴固定的兩拍協議 + 半同步行為

? 讀寫共享通路，不像 AXI 那樣天然分離

? 寫路徑可能只有一條，而 pready / prdata 卻可能來自幾十路，從而難以統一處理

在這種情況下，隨意插入一拍非常容易破壞協議timing diagram，例如：

? PSEL / PENABLE 的時序關系被打亂

? PREADY 反饋延遲不一致

? PRDATA 返回周期無法與手冊周期要求匹配

即便你強行做成了slice，它也不會像 AXI-Stream 那樣形成一致、標準的pipeline結構。由于讀寫通路不分離、通道數不對稱、反饋路徑復雜，實現最終往往會變成一坨難以維護的“屎山”。

更糟糕的是，當系統已經發展到幾十路slave，這時候想再做分區規劃、把 slave 進一步級聯或分層，往往已經為時已晚。此階段想要重構 APB 配置通路意味著：

需要重新推導、重新規劃整個路徑，工作量巨大。

AXI-Lite

AXI-Lite 是 AXI 協議的精簡版本，主要用于配置類訪問。其請求、數據與響應完全分離，包含五個獨立通道：AR、AW、W、R、B。

與完整 AXI 不同，AXI-Lite 不支持 burst，也沒有 ID，因此僅支持單次訪問。然而，它允許：

? AR 通道連續握手(連續發起讀請求)

? AW/W 通道連續握手(連續發起寫請求)

? 讀寫并行執行(讀寫通道完全獨立)

因此在 Xilinx IP、Intel IP 等主流平臺中，AXI-Lite 是默認的配置通路方案。

多子系統下的順序不可控問題

在 多個 Slave 并存的系統中，AXI-Lite 的并行讀寫機制可能會讓順序處理變得異常棘手。

例如，你依次發起了兩次讀訪問：

1. Read SLAVE_A
2. Read SLAVE_B

AXI-Lite 不保證返回順序與發出順序一致。

由于讀通道是完全獨立且可并發的，SLAVE_B 的響應可能比 SLAVE_A 更早返回。

在多 SLAVE 情況下，讀寫之間不存在全局順序，你以為“先發起的 READ 會先回來”，但協議并不這么保證。

因此，如果系統邏輯需要順序語義(例如狀態機嚴格依賴先后順序)，就需要額外的順序控制手段，例如：

? Ordering FIFO(請求順序緩存)

? tag(人為添加事務 ID)

? 狀態同步機制

? 或者直接給每個子系統分配獨立的控制端口

這些都是額外的工程成本。

在特殊場景中，如果連續訪問的是同一個 slave，內部順序通常不會被打亂，但跨 slave 就必須顯式處理。

硬件資源與結構復雜度更高

由于 AXI-Lite 的五通道是分離的，并且允許連續發起請求，因此需要一定的 outstanding 能力(哪怕只有 1 層)，也導致：

? 接線較 APB 明顯復雜

? 資源成本更高

? crossbar、仲裁、通道同步邏輯更重

換句話說，AXI-Lite 在靈活性和并行性上優于 APB，解決了APB難以做slice/pipeline的痛點，但其工程成本和硬件復雜度也隨之提高。

AHB-Lite

AHB-Lite 是 AMBA AHB 協議的精簡版本，主要用于中等帶寬的外設訪問與配置類場景。

相比完整AHB，AHB-Lite 去掉了多主機仲裁(single master) ，但保留了 AHB 的關鍵特性：

流水化、單周期地址階段 + 數據階段解耦、支持 burst、支持 back-pressure。

在 AHB-Lite 中，每一次訪問由兩部分組成：

? 地址階段(Address Phase) ：由 HADDR、HTRANS、HWRITE 等信號描述

? 數據階段(Data Phase) ：由 HRDATA、HWDATA、HREADY、HRESP 等信號描述

兩個階段是 嚴格對齊但可流水化 的，也就是說：

? 當前周期發送地址

? 下一個周期就可以發送下一次地址

? 數據返回與否由 slave 的 HREADY 控制

這種結構比 APB 靈活，也比 AXI 簡單。

但是，AHB-Lite 也存在一些現實痛點。

HREADY 同時影響控制與數據階段

AHB 最讓工程師頭疼的地方在于 HREADY 信號承擔了兩重語義：

? 表示“本拍的數據是否有效”

? 表示“下一拍的地址/控制階段是否可以推進”

這會帶來典型的工程不優雅行為：上一個數據階段的 ready 會影響當前地址/控制階段。

例如，在寫 SLAVE_A 的數據的下一拍，如果要訪問 SLAVE_B，HREADY 已經切換到 SLAVE_B 上，而 SLAVE_A 的數據階段可能還未完成。

因此在設計 slave 時，通常需要處理兩個 ready 信號：

? 總線側的 HREADY(輸入 ready)，用于控制數據傳輸

? Slave 輸出的 HREADY，用于表明數據已經被接收

主流 FPGA 支持不足

在 FPGA 工程中，AHB 還存在另一個痛點：生態與工具支持有限。

? 主流 FPGA 的生態幾乎都是 AXI 為主

? AHB 不像 APB 那樣簡單，也缺少官方 interconnect IP

? Vivado/Quartus 等工具對 AHB 的參考設計和自動生成支持非常有限

? 很少有工程師愿意在 FPGA 中自己實現一套 AHB 互聯

因此，盡管 AHB 有其優勢，實際使用時需要付出更多工程成本。

AHB 的工程實用性

盡管存在這些痛點，但在 特定規模的配置總線場景 下，AHB-Lite 仍然非常實用：

? 它解決了 APB 難以做 pipeline 的問題

? 它避免了 AXI-Lite 需要手動管理順序語義的麻煩

? 同時，AHB-Lite 的復雜度介于 APB 和 AXI-Lite 之間，既不太弱，也不過于臃腫

因此，對于中等規模的配置通路，AHB-Lite 往往是工程上最折中的選擇。

寫在最后

在實際 SoC、FPGA IP 與外設控制器設計中，配置總線的選擇往往是權衡穩定性、性能與工程成本的折中。

從工程實踐來看：

APB 適合簡單、低速配置場景，資源占用最小，但在系統規模擴大、跨時鐘域或多 slave 情況下容易遇到時序收斂和 slice/pipeline 難題。

AXI-Lite 靈活性高，讀寫通道獨立且可并行，但需要手動管理順序語義，硬件復雜度和接線成本高。

AHB-Lite 在中等規模配置總線中最為折中：它既解決了 APB 難以 pipeline 的痛點，也規避了 AXI-Lite 的順序管理麻煩，同時硬件復雜度適中，但需要處理 HREADY 雙重語義，并且在 FPGA 中缺乏工具支持。