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

Part 1：目標(biāo)

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

本系列是這一系列項(xiàng)目的導(dǎo)覽，因此不會(huì)有過多技術(shù)細(xì)節(jié)，主要闡述設(shè)計(jì)思路與背景，并簡述當(dāng)前進(jìn)度。

技術(shù)挑戰(zhàn)概覽

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

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

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

Part 2：電源

挑戰(zhàn)場景

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

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

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

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

計(jì)劃

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

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

當(dāng)前進(jìn)展

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

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

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

挑戰(zhàn)場景

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

這些電源軌之間存在時(shí)序約束需求，且手工焊接的原型板存在焊點(diǎn)缺陷導(dǎo)致短路的真實(shí)風(fēng)險(xiǎn)，因此放任各電源域無序上電不可行。

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

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

計(jì)劃

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

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

? 提供軟開關(guān)控制功能

? 執(zhí)行電源軌啟動(dòng)/關(guān)斷時(shí)序控制

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

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

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

當(dāng)前進(jìn)展

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

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

Part 4：管理

挑戰(zhàn)場景

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

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

計(jì)劃

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

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

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

當(dāng)前進(jìn)展

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

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

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

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

Part 5：FPGA-MCU 橋接

挑戰(zhàn)場景

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

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

計(jì)劃

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

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

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

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

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

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

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

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

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

當(dāng)前進(jìn)展

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

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

? 外設(shè)端無緩存污染風(fēng)險(xiǎn)

? 原生支持背壓機(jī)制

? 可生成自由運(yùn)行時(shí)鐘供PLL鎖定

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

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

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

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

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