“本文闡述了一套模塊化嵌入式基礎設施的設計框架。通過標準化電源管理、可擴展固件架構和硬件接口優化，解決了高密度設備群的能效瓶頸、系統可靠性及跨平臺兼容性難題”

Part 1：目標

我打算開啟一個系列，介紹過去一年多我在不同項目中逐步搭建的嵌入式平臺。長久以來，我一直在籌備多個大型嵌入式硬件項目：包含25 Gbps誤碼率測試儀、48+2端口1/10千兆以太網交換機和2 GHz示波器，同時通過幾個小型項目（如觸發交叉開關、14+1端口1/10G交換機等）作為技術鋪墊（其中部分已完成）。

本系列是這一系列項目的導覽，因此不會有過多技術細節，主要闡述設計思路與背景，并簡述當前進度。

技術挑戰概覽

這些項目具有諸多共性：均采用1U機架式設計，支持SSH或SCPI協議實現IP管理，前面板配有數量不等的功能端口（依設備類型而變），后面板需提供電源接口、管理網口、調試/配置用串行控制臺，并可能配備參考時鐘和觸發同步等輔助接口。

內部架構層面，每個設備需搭載大容量FPGA處理高速數據路徑和輸入/輸出，配合運行管理接口的微控制器，兩者間需建立通信機制。此外，多電源域管理、復位信號調度等問題亟需通過膠合邏輯實現集中控制。

整套系統的供電方案尚待確定。

Part 2：電源

挑戰場景

初期我設計的微型USB 2.0供電FPGA/MCU開發板功率極低，運行時觸感冰涼。但當面對如48端口以太網交換機這類設備時，即便采用最高效設計方案，其功耗也必然遠超無源USB電源適配器的2.5W上限。現測試中的觸發交叉開關原型功耗已近10W，預計整機交換機功耗將達30W（僅四張12端口BaseT線卡即消耗此值，尚未計入FPGA交換引擎與管理系統的額外損耗）。

以往設計中我曾采用5/12V直流圓筒插座，但其存在易松脫的惱人問題，高功率場景下更顯局限。

直接市電輸入雖為選項，但其涉及安全隱患（若計劃量產還需應對合規認證），故未列為首選方案。

當下流行的USB PD協議雖可實現智能供電，但需為每臺設備配備專用適配器。考慮到實驗室供電容量有限，若能多設備共享集中式供電平臺顯然更具優勢。

計劃

借鑒數據中心/電信領域廣泛應用的48V直流供電架構，我最終選擇此方案：通過六針Molex Mini-Fit Jr接口傳輸+48V直流電（負極接地），既可利用市售電源模塊，亦為后期部署機架級直流母線系統預留升級空間。

由于多數DC-DC模塊難以直接處理48V高壓輸入，我專門設計了可復用的中間總線轉換器（IBC），將Mini-Fit Jr輸入的48V降至12V（通過八針接口輸出）。此IBC還額外提供持續工作的3.3V待機電源軌，用于監控/管理單元與多路I2C傳感器的供電。

當前進展

初代IBC雖在修正設計審查遺漏的布線錯誤后實現功能，但其待機功耗達3W（輕載效率堪憂）。

現已投板生產的第二代IBC版圖面積縮減40%，待機功耗有望降至0.5W，大幅優化低負載效率表現。

Part 3：監控單元

挑戰場景

當前多數項目需管理多路電源軌。以觸發交叉開關為例，其包含10個獨立可控的電源域（未計入48V輸入、經π型濾波器隔離的模擬電源軌，以及由處理器固件自主調控的動態電壓核心）。

這些電源軌之間存在時序約束需求，且手工焊接的原型板存在焊點缺陷導致短路的真實風險，因此放任各電源域無序上電不可行。

量產級解決方案通常采用專用監控芯片，或通過硬連線方式將穩壓器的PGOOD與ENABLE信號級聯。

但在原型機或小批量設備中，此方案存在局限性：調試階段可能發現新的時序需求，需臨時改動設計。飛線修補雖可行卻繁瑣，因此我更傾向通過軟件實現靈活調控。

計劃

經多輪迭代，選定STM32L431作為監控單元。該芯片當前批量采購價約3美元（封裝不同略有浮動），雖非最廉價方案，但相較Kintex-7或UltraScale+等高端FPGA，其成本在系統BOM中占比微乎其微。其性能參數（80 MHz Cortex-M4內核、256 kB閃存、64 kB SRAM）足以支撐雙鏡像+引導程序的可靠固件更新架構。關鍵優勢在于豐富的封裝選項（32-QFN/48-QFN/100-BGA），可實現不同電源域數量的硬件平臺間固件無縫移植。

監控單元核心職責包括：

? 提供軟開關控制功能

? 執行電源軌啟動/關斷時序控制

? 通過內部ADC與溫度傳感器實現系統健康監測

? 通過I2C與IBC通信獲取輸入電源狀態

擴展功能涵蓋故障處理機制：當檢測到穩壓器PGOOD信號異常（可能指示短路或穩壓故障）、ADC讀數超閾值、溫度越限或輸入電源中斷時，系統將觸發緊急硬關斷（防止損壞擴散）或有序軟關斷（斷電前保留易失性狀態）。

當前進展

監控單元已以多種形態應用于多個原型系統，但現有代碼需重構為可復用的模塊化架構。未來新建項目時僅需配置GPIO映射關系與時序規則即可快速部署。相關專題文章將在后續發布。

長期規劃中，該單元還將接管風扇控制等獨立于主固件的系統健康管理功能。

Part 4：管理

挑戰場景

所有設備均需網絡管理或數據傳輸能力。常規方案是在FPGA旁部署運行Linux的Cortex-A片上系統，或采用Zynq等FPGA+SoC集成平臺。

但嵌入式Linux生態復雜臃腫，因此我正探索更輕量化的替代方案。

計劃

我傾向于構建控制平面與數據平面完全分離的架構：微控制器（MCU）專注控制邏輯，FPGA處理數據流。

在MCU側，我推崇基于Cortex-M內核的極簡事件循環架構：僅保留關鍵實時中斷服務例程（無法卸載至FPGA的部分），摒棄實時操作系統（RTOS）、動態內存分配等冗余設計。

當前行業趨勢偏向"低成本快速開發"導向，鮮有符合此類極簡設計需求的現成方案。經調研發現，現有TCP/IP協議棧、SSH服務實現等均無法滿足需求，故決定自主開發。

當前進展

已構建基于STM32H735微控制器的全靜態內存分配TCP/IP協議棧（當前僅支持IPv4，IPv6支持待后續開發），配套SSH服務端實現支持AES-GCM加密與curve25519密鑰交換（可選FPGA加速）。受限于應用場景，該協議棧僅作服務端使用（無外發連接功能），并剔除了IP分片等低頻特性。

該方案資源占用極低：觸發交叉開關的恢復鏡像（含SSH服務、SFTP固件更新器及底層驅動）在-Os優化下僅占用82 KB閃存空間，SRAM消耗114 KB（主要用于套接字緩沖區）。

主應用固件在-O3優化下體積增至161 KB閃存/124 KB SRAM，但已集成硬件驅動、IP協議棧、SSH管理終端、串口控制臺、SFTP更新器、SCPI服務端、DHCP客戶端、SNTP客戶端等完整功能集。

FPGA側已實現部分TCP/IP卸載功能以應對高帶寬數據流，但當前實現仍顯冗余，需進一步優化精簡。

Part 5：FPGA-MCU 橋接

挑戰場景

主控MCU需與FPGA建立通信通道。

早期平臺采用SPI協議，但其速率受限且需通過特殊功能寄存器（SFR）指令訪問FPGA寄存器，操作繁瑣。隨著原型迭代，通信架構逐步優化。

計劃

首先將內部管理總線從嵌套式case語句結構升級為標準總線協議。選擇AMBA APB協議因其具備AXI橋接能力，同時兼具低資源占用與性能適配優勢。最終目標是將MCU與APB總線直接內存映射，實現如同訪問片上外設般的便捷性。

觸發交叉開關項目中曾嘗試采用STM32H7的OCTOSPI接口（四線SPI模式測試），結果證明此決策存在嚴重設計缺陷。

OCTOSPI 雖支持內存映射，但受芯片勘誤與架構限制導致實際應用困難：

? 無法禁用32字節預取緩沖區，導致任意APB讀取可能觸發相鄰地址訪問

? 預取地址范圍的數據緩存在OCTOSPI外設中（無視Cortex-M7 MPU緩存配置）

? 副作用寄存器讀取可能因地址鄰近觸發誤操作

? 輪詢邏輯易陷入死循環（緩存數據未刷新實際狀態）

此外，該接口缺乏背壓機制，無法在事務延遲時暫停傳輸，需依賴固定時鐘周期與實時性約束。

經此教訓，設計轉向測試FMC（靈活存儲控制器）作為替代方案。

當前進展

FMC方案除需占用較多引腳（約27個，具體取決于模式與地址空間配置）外，完美滿足需求：

? 支持設備模式內存映射（強序非緩存訪問）

? 外設端無緩存污染風險

? 原生支持背壓機制

? 可生成自由運行時鐘供PLL鎖定

唯一未原生支持的功能是APB PSLVERR總線錯誤回傳，但可通過GPIO中斷模擬等效處理。

當前測試發現讀突發末尾存在2個冗余時鐘周期（硅片勘誤所致），FPGA端可忽略此問題（輕微性能損耗）。雖STM32H735支持275 MHz時鐘，現基于Spartan-7測試125 MHz，未來UltraScale+平臺可輕松實現目標250 MHz運行頻率。

待完整封裝與深度驗證后，將發布詳細技術文檔。目前雙向橋接（STM32 AXI至FPGA APB）已穩定運行。

未來探索方向包括優化突發傳輸效率：盡管STM32端AXI總線為32位寬，嘗試64位傳輸仍被拆分為兩次32位FMC訪問。需進一步研究編譯器生成的指令碼以尋求優化空間。

轉載自 Andew Zoneberg's blog，License 為 CC BY-SA 4.0