第4章硬件平台迁移策略

4、硬件平台迁移策略：从DSP+FPGA到SoC（ARM+DSP+NPU）的演进，硬件加速器设计思路

说实话，做基带迁移这件事，我最早接触是在4G时代末期。那时候我们团队还在用DSP+FPGA的老路子，每次迭代都像在刀尖上跳舞。后来5G标准一出来，我一看那带宽和时延要求，心里就明白——这条路走不通了。

SoC方案，说白了就是把ARM、DSP、NPU这些家伙揉到一起。你想想看，一个芯片里既要跑控制面，又要跑数据面，还得做AI推理。这活儿怎么分？我个人的习惯是：先搞清楚每个模块的“脾气”，再决定谁干什么。

4.1 为什么必须迁移？

先说说痛点。DSP+FPGA的方案，我在项目中遇到过最大的坑就是——灵活性太差。FPGA虽然快，但改一次逻辑要重新综合布线，少说半天。5G的波形、帧结构、MIMO层数说变就变，你总不能每次都换板子吧？

另一个问题是功耗。我记得有一次做64天线Massive MIMO原型机，FPGA的功耗直接飙到30W+，散热片烫得能煎鸡蛋。SoC方案呢？ARM负责调度，DSP做信号处理，NPU做AI加速，各司其职，功耗能降一半。

  核心迁移思路： 把“硬连线”的FPGA逻辑，拆成“软硬协同”的SoC任务。能软件跑的别用硬件，能硬件加速的别用CPU轮询。

4.2 SoC架构怎么分？

我一般把SoC里的任务分成三层：

控制面（ARM）：负责协议栈、调度、配置。说白了就是“大脑”，不干重活，但得聪明。
数据面（DSP）：负责FFT、信道估计、均衡这些数学活。DSP的SIMD指令集干这个最拿手。
加速面（NPU/硬件加速器）：负责AI检测、波束赋形、干扰消除。这些活儿用NPU跑，比DSP快一个数量级。

举个例子。5G的PDSCH解调，以前在FPGA里要写几百行Verilog。现在呢？ARM把调度信息配好，DSP做信道估计，NPU做MIMO检测。嗯，这里要注意——数据流不能乱。我见过有人把NPU当DSP用，结果延迟反而上去了。

4.3 硬件加速器设计思路

硬件加速器，说白了就是“专用计算单元”。但怎么设计？我总结了几条经验：

找热点：先profile你的算法，看哪段代码最耗时。我在项目中遇到过，一个LDPC译码占了40%的CPU时间。那好，这个必须上加速器。
定粒度：加速器不能太粗也不能太细。太粗（比如整个物理层）不灵活，太细（比如一个加法器）没意义。我建议以“功能模块”为单位，比如FFT、矩阵求逆、CRC校验。
留接口：加速器一定要有寄存器配置接口。为什么？因为5G的参数是动态的，你总不能每次改个带宽就重新综合吧？

我的小技巧： 加速器设计时，先写一个C模型，验证功能正确。再用HLS（高层次综合）转成RTL。这样迭代快，不容易出bug。

4.4 一个实际案例：FFT加速器

拿FFT举例。5G的OFDM符号长度从128到4096不等。DSP做FFT，一次要几百个cycle。硬件加速器呢？我设计过一个流水线结构的FFT，能做到每个cycle出一个点。

代码示例（伪代码，描述加速器控制逻辑）：

// FFT加速器配置寄存器
#define FFT_CTRL      0x00  // 控制寄存器
#define FFT_LEN       0x04  // FFT长度（128/256/.../4096）
#define FFT_SRC_ADDR  0x08  // 源数据地址
#define FFT_DST_ADDR  0x0C  // 目的数据地址
#define FFT_START     0x10  // 启动位

// ARM侧驱动代码
void fft_accelerator_run(uint32_t *src, uint32_t *dst, int len) {
    // 配置参数
    *(volatile uint32_t*)(FFT_BASE + FFT_LEN) = len;
    *(volatile uint32_t*)(FFT_BASE + FFT_SRC_ADDR) = (uint32_t)src;
    *(volatile uint32_t*)(FFT_BASE + FFT_DST_ADDR) = (uint32_t)dst;
    
    // 启动加速器
    *(volatile uint32_t*)(FFT_BASE + FFT_CTRL) = 0x01;
    
    // 等待完成（轮询或中断）
    while(*(volatile uint32_t*)(FFT_BASE + FFT_START) & 0x01);
}

你看，ARM只需要写几个寄存器，剩下的活加速器自己干。这样ARM就能腾出手来做调度，系统吞吐量翻倍。

4.5 避坑指南

我曾经踩过的坑：

数据一致性：DSP和NPU共享内存时，一定要加cache一致性协议。否则你算出来的结果可能是错的。
中断风暴：加速器完成一次任务就发一次中断，ARM会被淹死。我建议用“批处理模式”，攒够一批再通知ARM。
带宽瓶颈：加速器算得再快，数据搬不进来也没用。设计时一定要算好DDR带宽，必要时加local memory。

4.6 知识体系总览

下面这张图，是我自己总结的迁移策略框架。你看一眼，心里就有数了。

4.7 总结

从DSP+FPGA到SoC，说白了就是一次“分权”的过程。ARM管大局，DSP干重活，NPU搞AI。硬件加速器呢？就是那个“特种兵”，专啃硬骨头。

我个人觉得，迁移成功的关键不在于技术多牛，而在于分工是否清晰。你想想看，如果ARM去算FFT，NPU去跑协议栈，那不乱套了吗？

最后说一句：别想着一步到位。先拿一个模块（比如FFT加速器）做试点，跑通了再铺开。我在项目中就是这么干的，稳得很。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

4、硬件平台迁移策略：从DSP+FPGA到SoC（ARM+DSP+NPU）的演进，硬件加速器设计思路

4.1 为什么必须迁移？

4.2 SoC架构怎么分？

4.3 硬件加速器设计思路

4.4 一个实际案例：FFT加速器

4.5 避坑指南

4.6 知识体系总览

4.7 总结