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

Part 1：目標

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

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

技術挑戰(zhàn)概覽

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

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

整套系統(tǒng)的供電方案尚待確定。

Part 2：電源

挑戰(zhàn)場景

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

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

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

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

計劃

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

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

當前進展

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

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

Part 3：監(jiān)控單元

挑戰(zhàn)場景

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

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

量產(chǎn)級解決方案通常采用專用監(jiān)控芯片，或通過硬連線方式將穩(wěn)壓器的PGOOD與ENABLE信號級聯(lián)。

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

計劃

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

監(jiān)控單元核心職責包括：

? 提供軟開關控制功能

? 執(zhí)行電源軌啟動/關斷時序控制

? 通過內(nèi)部ADC與溫度傳感器實現(xiàn)系統(tǒng)健康監(jiān)測

? 通過I2C與IBC通信獲取輸入電源狀態(tài)

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

當前進展

監(jiān)控單元已以多種形態(tài)應用于多個原型系統(tǒng)，但現(xiàn)有代碼需重構(gòu)為可復用的模塊化架構(gòu)。未來新建項目時僅需配置GPIO映射關系與時序規(guī)則即可快速部署。相關專題文章將在后續(xù)發(fā)布。

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

Part 4：管理

挑戰(zhàn)場景

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

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

計劃

我傾向于構(gòu)建控制平面與數(shù)據(jù)平面完全分離的架構(gòu)：微控制器（MCU）專注控制邏輯，F(xiàn)PGA處理數(shù)據(jù)流。

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

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

當前進展

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

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

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

FPGA側(cè)已實現(xiàn)部分TCP/IP卸載功能以應對高帶寬數(shù)據(jù)流，但當前實現(xiàn)仍顯冗余，需進一步優(yōu)化精簡。

Part 5：FPGA-MCU 橋接

挑戰(zhàn)場景

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

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

計劃

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

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

OCTOSPI 雖支持內(nèi)存映射，但受芯片勘誤與架構(gòu)限制導致實際應用困難：

? 無法禁用32字節(jié)預取緩沖區(qū)，導致任意APB讀取可能觸發(fā)相鄰地址訪問

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

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

? 輪詢邏輯易陷入死循環(huán)（緩存數(shù)據(jù)未刷新實際狀態(tài)）

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

經(jīng)此教訓，設計轉(zhuǎn)向測試FMC（靈活存儲控制器）作為替代方案。

當前進展

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

? 支持設備模式內(nèi)存映射（強序非緩存訪問）

? 外設端無緩存污染風險

? 原生支持背壓機制

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

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

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

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

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

轉(zhuǎn)載自 Andew Zoneberg's blog，License 為 CC BY-SA 4.0