数字通信系统基础回顾：基带信号处理流程与关键性能指标
各位同学，欢迎来到第二讲。今天咱们聊聊数字通信系统的“地基”——基带信号处理。说实话，很多做算法加速的工程师，往往只盯着自己的模块，对整体流程缺乏感觉。我个人习惯是，先画一张大图，把发射机和接收机的关键环节串起来，这样后面做硬件架构时，才知道每个模块的“脾气”和“瓶颈”。
核心观点：基带处理是通信算法的“心脏”。编码、调制、OFDM、MIMO这四个环节，决定了系统的吞吐率、延迟和功耗。硬件加速器设计，本质上就是在这三个指标之间找平衡。
1. 基带信号处理流程：从比特到波形的“变形记”
我们先看发射端。原始数据进来，是一串二进制比特。它要经过四道工序，才能变成适合无线传输的波形。我当年做第一个OFDM项目时，总觉得这流程太啰嗦，后来被现实狠狠教育了一顿——每个环节都有它的物理意义，跳不过去。
1.1 编码：给数据穿上“防弹衣”
编码分两类：信源编码和信道编码。信源编码负责压缩，比如去掉冗余信息。信道编码则相反——它故意加入冗余，用来对抗信道噪声。你想想看，这就像寄快递，信源编码是把东西塞进小盒子，信道编码是给盒子裹上泡沫塑料。
我在项目中遇到过最头疼的事，就是LDPC码的译码器设计。它的吞吐率要求动辄几十Gbps，但迭代译码的延迟又很敏感。嗯，这里要注意：编码增益每提高0.5dB，硬件面积可能翻倍。所以别盲目追求高性能编码，要看系统整体预算。
避坑指南：我曾经在某个5G基站项目中，为了追求极致编码增益，选了复杂度极高的Turbo码。结果FPGA资源爆了，功耗也压不住。后来换成LDPC，虽然增益低了0.3dB，但硬件实现简单得多。记住：工程不是学术，平衡才是王道。
1.2 调制：把比特“画”到星座图上
调制就是把比特映射到复数符号上。QPSK、16QAM、64QAM……阶数越高，每个符号携带的比特越多，但抗噪声能力也越差。说白了，这就是个“速度与激情”的博弈。
我建议你记住一个经验公式：调制阶数每翻一倍，接收机灵敏度大约要恶化3dB。所以自适应调制编码（AMC）在硬件里很常见——信道好时用256QAM，差时切回QPSK。
1.3 OFDM：把宽带变窄带
OFDM的核心思想，是把高速数据流分成N路低速子载波。这样做的好处是：每个子载波上的符号周期变长，对抗多径衰落的能力就强了。你想想看，一条大河分成N条小溪，每条小溪的波浪自然就平缓了。
OFDM的硬件实现，关键在FFT/IFFT模块。我记得第一次做OFDM接收机时，FFT的点数选错了，导致子载波间隔不对，整个系统都解不出来。后来才明白：FFT点数 = 系统带宽 / 子载波间隔，这个关系必须算清楚。
注意：OFDM对频偏和相位噪声极其敏感。我曾经在实测中，因为本地振荡器的相位噪声超标，导致EVM（误差矢量幅度）直接爆表。硬件设计时，一定要给PLL留够裕量。
1.4 MIMO：空间维度“薅羊毛”
MIMO利用多根天线，在空间维度上并行传输数据。说白了，就是“多开几条车道”。2x2 MIMO理论上能翻倍吞吐率，4x4 MIMO能翻四倍。但代价呢？接收机的检测算法复杂度呈指数增长。
常见的MIMO检测算法有：ZF（迫零）、MMSE（最小均方误差）、ML（最大似然）。ML性能最好，但复杂度高得吓人。我在项目中通常用MMSE，再配合迭代检测，性能和复杂度都能接受。
2. 关键性能指标：吞吐率、延迟、功耗的“不可能三角”
做硬件加速器，天天跟这三个指标打交道。它们之间互相制约，就像三角形的三个角——你优化一个，另外两个可能变差。我习惯用一张表来对比不同设计选择的权衡。
| 指标 | 定义 | 典型值（5G基站） | 硬件设计影响 |
|---|---|---|---|
| 吞吐率 | 单位时间处理的数据量 | 10~20 Gbps | 决定并行度、时钟频率 |
| 延迟 | 从输入到输出的时间 | < 1 ms（URLLC场景） | 决定流水线深度、缓存大小 |
| 功耗 | 单位时间消耗的能量 | < 20 W（小基站） | 决定工艺节点、电压频率 |
2.1 吞吐率：越快越好？不一定
吞吐率是硬指标。但你要明白，峰值吞吐率和实际吞吐率是两码事。我见过不少方案，宣传时吹得天花乱坠，实际跑起来因为调度开销、缓存瓶颈，吞吐率直接腰斩。
硬件设计时，我建议用“流水线平衡”的思路：每个模块的处理速度要匹配，别让某个模块成为瓶颈。比如FFT模块能跑2 Gbps，但后面的MIMO检测只能跑1 Gbps，那整体吞吐率就被卡死在1 Gbps。
2.2 延迟：毫秒级的“生死时速”
延迟在URLLC（超可靠低延迟通信）场景里是生命线。自动驾驶、远程手术，延迟超过1毫秒就可能出事故。硬件加速器设计时，延迟主要来自：处理延迟 + 排队延迟 + 传输延迟。
我曾经优化过一个OFDM接收机，把延迟从2.3ms降到了0.8ms。怎么做到的？把原本串行的FFT和信道估计改成并行流水线，再减少中间缓存。说白了，就是用面积换时间。
关键洞察：延迟优化有个“三七定律”——30%的优化来自算法改进，70%来自硬件架构。别指望换个算法就能解决延迟问题，老老实实优化流水线和缓存才是正道。
2.3 功耗：热得能煎鸡蛋？
功耗是硬件设计的“隐形杀手”。我记得有一次，芯片流片回来，一上电温度直接飙到85度，散热片都压不住。后来一查，是MIMO检测模块的乘法器阵列功耗超标。
降低功耗的常用手段：门控时钟、电压频率调节、数据复用。我个人习惯是在设计初期就做功耗估算，别等到流片了才发现问题。工具方面，PrimeTime PX和SpyGlass Power都挺好用。
3. 硬件加速器设计的“黄金法则”
讲了这么多，总结三条我自己的经验法则：
- 先算账，后动手：拿到一个算法，先估算它的计算量、存储需求、数据流模式。算清楚了再决定用FPGA还是ASIC。
- 流水线是灵魂：好的流水线设计，能让吞吐率翻倍、延迟减半。我见过太多人一上来就堆并行，结果面积爆炸、时序收敛不了。
- 别忘了验证：硬件加速器最怕“功能正确但性能不达标”。我建议用“性能模型先行”的方法，先搭一个C/C++的性能模型，跑通了再写RTL。
小技巧：做硬件加速器时，多用“乒乓缓存”结构。它能有效隐藏数据搬移的延迟，让处理单元一直忙个不停。我几乎所有项目里都会用这个结构，百试百灵。
好了，这一讲就到这里。基带信号处理流程和关键指标，是后面所有章节的基础。你把这些搞清楚了，后面学OFDM加速器、MIMO检测器时，就会轻松很多。记住：硬件设计不是堆资源，而是找平衡。