嵌入式基础构架 from andrew@labs

“本文阐述了一套模块化嵌入式基础设施的设计框架。通过标准化电源管理、可扩展固件架构和硬件接口优化，解决了高密度设备群的能效瓶颈、系统可靠性及跨平台兼容性难题”

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