6.2 硬件架构与嵌入式实现

6.2 硬件架构与嵌入式实现

本节摘要：声呐处理是一台"按时完成就有用、完不成等于零"的实时机器：模拟前端把微伏级水听信号放大滤波，ADC 按奈奎斯特定下采样起点，FPGA 扛波束形成与滤波的乘加洪流，DSP 或 CPU 跑检测跟踪与识别，总线与记录系统兜底数据吞吐。本节按信号流向拆解架构，并以算力、时延、功耗三约束做选型对照。

从一根电缆到一幅态势：架构总览

信号在前端的旅程决定成败的底线。水听器输出的有用信号常只有微伏到毫伏量级，而拖曳阵的电缆本身就会拾取干扰，因此前置放大必须尽量靠近基元（湿端放大）、用低噪声器件把信噪比在第一级就保住；随后是抗混叠滤波与 ADC——采样率的下限由最高工作频率决定（数十千赫系统百千赫级采样足够，兆赫级成像系统采样率也要水涨船高），位深决定动态范围（24 位 ADC 让你不必为强信号削顶而牺牲弱信号分辨率）。数字化之后，数据进入"乘加洪流"区：一个 64 元阵、每通道 100 千采样每秒的系统，原始码率近每秒 1.5 亿采样；波束形成对每个方向都要做一遍加权求和，算力需求轻松上到每秒数百亿次浮点运算。这个量级决定了硬件分工：FPGA 用海量并行乘加单元扛第一层（滤波、抽选、波束形成），DSP 或多核处理器扛第二层（检测、跟踪等逻辑复杂的算法），上层 CPU 与图形界面负责态势与人机交互。三层之间靠高速总线衔接，记录与回放系统把原始数据落盘——事后分析与小样本积累（喂给 6.1 的识别学习路线）全靠它。

三约束选型：算力、时延、功耗

硬件选型永远在三面墙之间找平衡。算力墙：流水线最深处的一层决定最小硬件规格，波束形成与匹配滤波的乘加量按"基元数 × 方向数 × 采样率"叠加，选型前先把这笔账算清。时延墙：不同系统的实时定义天差地别——鱼雷自导的判决周期是毫秒级，晚一个决策窗口目标就出波束；反潜警戒的态势更新是秒级，晚几秒只是画面卡顿。时延要求越苛刻，越倾向 FPGA 与专用硬件、越不敢把判决押在通用处理器上。功耗墙：无人平台与声呐浮标的电池以瓦时计，一颗百瓦级的处理板就能决定任务时长；同一种算法在 GPU 上快但在功耗上惨败，在 FPGA 上略慢却能低一个量级地省电。三面墙冲突时的裁决规则也简单：武器与时敏系统以时延为纲，无人平台以功耗为纲，舰载与岸基大系统以算力为纲——纲举目张，选型自然收敛。

算力估算示例（64 元阵，100 kS/s，48 波束，FIR 波束形成 32 阶）：
  每方向乘加率 = 通道数 × 采样率 × 阶数
              = 64 × 100e3 × 32 ≈ 2.05 亿 MAC/s
  全部方向    = 48 × 2.05 亿 ≈ 98.6 亿 MAC/s
  加上匹配滤波与检测预留（约 2 至 3 倍）→ 百亿 MAC/s 量级
  结论: 中型 FPGA（数千 DSP48 级资源）或其等效算力为下限配置
​

模拟与数字的分界线：为什么它总在变

架构里最有戏剧性的变量是模拟/数字分界的位置。早期声呐在前端就完成大量模拟处理（模拟波束形成用相移网络、模拟滤波用 LC 网络），数字机只做后端显示——好处是数字端简单，坏处是模拟网络的精度、温度漂移与体积不可救药。如今分界线一路前移：湿端只留前置放大，数字化越早越好——数字域没有漂移、可以任意重构、校准可以在软件里完成。但前移也有代价：多通道同步采样要求 ADC 严格同源时钟，百千赫级采样率下 64 通道的原始数据率对总线与存储是硬压力，湿端的供电与隔离也要重新设计。当前的技术前沿在湿端继续推进：把 ADC 与光纤传输集成进拖曳阵的每一段模块，让电缆里跑的是数字光信号而非模拟电信号——模拟段被压缩到厘米级，干扰拾取随之骤减。读架构图时先找这条分界线，就能判断这套系统的年代与设计哲学。

挑战清单：工程实现的常见坑

这张表里的每一行都对应真实的返工案例。特别注意自噪声一行：它不是电子问题而是机械与布置问题——再好的前端也救不了装在主机正上方的基阵，这也自然引出下一节的主题：基阵装在哪，比怎么装更重要。

要点速记

• 架构三层分工：FPGA 扛乘加洪流（滤波与波束形成），DSP 扛复杂逻辑（检测跟踪），上层机管态势与人机。
• 三约束裁决：时敏武器以时延为纲，无人平台以功耗为纲，舰载岸基以算力为纲。
• 模拟/数字分界线持续前移，湿端只剩前置放大；分界位置就是设计年代的指纹。
• 通道失配、时钟同步、自噪声是嵌入式三大惯犯；自噪声本质是布置问题，硬件救不了阵位选错。

动手小练习：给流水线排硬件

任务：32 元阵、采样率 50 千赫兹、16 个波束、需要匹配滤波与简单跟踪。第一步算乘加：波束形成约 32 乘 5 万乘 16 等于两千五百多万次乘加每秒，匹配滤波按波形带宽再乘一个系数——总量在十亿次乘加每秒以下。结论：一颗中型 FPGA 甚至高端 DSP 即可扛下，无需上多机系统。第二步看时延：若这是鱼雷自导，判决周期毫秒级，关键路径全部固化进 FPGA；若是测绘后处理，通用机足够。做完你会发现：硬件选型的第一步永远是算乘加与定时延，而不是看产品目录——目录是算完账之后的购物车。

问题：为什么记录与回放系统如此重要

原始数据的回放能力是整个研制体系的"时光机"：算法改进后用历史数据重放即可对比新旧性能，海试疑点可以带回岸上反复复盘，识别学习路线的训练样本全靠日常记录积累。省掉记录系统的项目，等于放弃了用时间换取数据资产的机会——这是最隐蔽的一类省钱反而最贵。

问题：为什么不用 GPU 扛全部处理

GPU 的算力密度确实诱人，但三个现实让它难当主力。功耗：几十到上百瓦的功耗对舰载尚可、对无人平台是灾难。时延确定性：GPU 的批处理吞吐模式在毫秒级硬实时判决面前不够"守时"。环境：水下设备的散热、震动与可靠性门槛，让高功耗高发热的方案天然吃亏。所以主流架构把 GPU 类部件用在非实时 heavy lifting（事后批处理、模型训练），实时链路交给 FPGA 加 DSP 的经典组合——各就各位，而不是堆最时髦的芯片。

一个容易被忽视的指标：启动时间

从按下电源到输出有效态势的时间，常被规格书遗漏却极有战术价值：反潜机的声呐浮标处理终端要求几分钟内可用，潜航器的首部处理链要求出航即就绪。启动时间长的根源多是标定流程（通道校准、阵形初始化）串行执行，解法是并行化与增量校准——又一个"规格书之外才是工程"的例子。