2. 通路架构：5G NR基带处理链路的模块划分与数据流

好，咱们进入正题。这一章我打算聊聊5G NR基带处理链路到底长什么样。说白了，就是数据从天线口进来，经过哪些模块，最后变成我们能理解的比特流。反过来，发数据也是一样的道理。

我刚开始接触5G基带时，第一反应是——这玩意儿也太复杂了吧！模块多得让人眼花缭乱。但干久了你会发现，其实核心就那么几个大块，每个块都有自己的脾气。

2.1 整体架构概览

先看一张我画的整体架构图。这张图我改了好几版，最后觉得这样画最清晰。

这张图里，我特意标出了五个延迟关键点——L1到L5。为什么标它们？因为我在实际项目中吃过亏。有一次，我们团队设计的接收链路，均衡器那块延迟爆表，结果整个链路的吞吐量死活上不去。后来一查，是均衡器的矩阵求逆模块没做好流水线。

2.2 接收链路模块详解

接收链路，说白了就是把天线收到的模拟信号，一步步变成我们能处理的比特。我按数据流的方向，一个一个说。

2.2.1 RF前端与ADC

这是第一关。RF前端负责把天线信号下变频到基带，然后ADC把它变成数字信号。

嗯，这里有个坑。ADC的采样率直接决定了后续FFT的点数和处理延迟。我记得有个项目，为了省功耗，选了低采样率的ADC，结果带宽不够，高频子载波全丢了。后来只能换芯片，周期硬生生拖了两周。

2.2.2 CP移除与FFT

CP（循环前缀）移除其实很简单，就是把每个OFDM符号前面的保护间隔扔掉。但要注意时序——CP长度在不同子载波间隔下是不一样的。

FFT是这里的大头。5G NR支持多种FFT点数，从128点到4096点都有。你想想看，4096点FFT，如果时钟跑500MHz，一次变换大概要8微秒。这个延迟在低时延场景下，已经相当可观了。

// 伪代码：FFT处理流程
// 假设N=2048点FFT，时钟频率491.52MHz
for (int i = 0; i < N; i++) {
    // 从FIFO读取时域数据
    sample_in[i] = read_from_fifo();
}
// 启动FFT核
fft_core_start(N);
// 等待完成（约N/2个时钟周期）
wait_for_done();
// 输出频域数据
for (int i = 0; i < N; i++) {
    sample_out[i] = read_from_fft_core();
}

2.2.3 信道估计

信道估计，说白了就是猜一猜信号在空气中经历了什么。5G NR用的是DMRS（解调参考信号）来做估计。

我个人习惯把信道估计分成两步：先做LS估计（最小二乘），再做插值。LS估计简单粗暴，但噪声大。插值可以用线性、高斯或者MMSE。MMSE效果最好，但计算量也最大。

我曾经在一个项目中，信道估计用了MMSE，结果延迟超标。后来改成线性插值，性能只差了0.3dB，但延迟降了40%。这就是工程上的取舍。

2.2.4 均衡器

均衡器是接收链路里最「重」的模块。它的任务是把信道的影响抵消掉。

对于MIMO系统，均衡器要做矩阵运算。比如4x4 MIMO，每次要算一个4x4矩阵的逆。你想想看，如果子载波有1200个，每个都要算一次矩阵逆，这计算量有多大？

均衡器类型	计算复杂度	延迟（典型值）	适用场景
ZF（迫零）	O(N³)	低	高信噪比
MMSE	O(N³)	中	一般场景
ML（最大似然）	O(2^N)	高	小规模MIMO

我建议，如果延迟预算紧张，优先用MMSE。ZF虽然简单，但噪声放大问题很头疼。

2.2.5 解调与译码

最后一步。解调就是把QAM符号变成软比特（LLR），译码则是LDPC或Polar码的解码。

LDPC译码是这里的延迟大户。一次迭代要多久？取决于迭代次数和并行度。我见过一个设计，8次迭代跑了15微秒，这已经算快的了。

2.3 发送链路模块详解

发送链路是接收的逆过程，但有些细节不一样。

2.3.1 编码与调制

发送端先做信道编码（LDPC或Polar），然后调制成QAM符号。这里要注意码率匹配——5G NR支持很多种码率，从1/3到8/9都有。

我建议在RTL设计时，把编码器做成可配置的。因为不同业务场景需要的码率不一样。eMBB用高码率，URLLC用低码率。你写死一个值，后面改起来很痛苦。

2.3.2 预编码

预编码是MIMO系统的关键。它根据信道状态信息（CSI），对发送信号做加权，让信号在空间上「定向」发射。

预编码矩阵的计算，通常是在MAC层完成的。物理层只负责查表。但要注意——查表也有延迟。如果表太大，查一次要好几个时钟周期。

2.3.3 资源映射与IFFT

资源映射就是把数据放到正确的RE（资源元素）上。5G NR的时频资源网格很灵活，有RB（资源块）的概念。

IFFT是FFT的逆过程，延迟特性类似。但要注意，IFFT的输出要加CP，这个操作虽然简单，但时序要卡准。

2.4 数据流与控制流的交互

最后聊聊数据流和控制流怎么配合。说白了，数据流是「干活」的，控制流是「指挥」的。

MAC调度器每1ms（一个时隙）发一次调度指令。指令内容包括：用哪个RB、什么调制方式、多少层MIMO等等。物理层收到指令后，开始处理数据。

这里有个关键问题——调度指令的到达时间和数据到达时间必须对齐。如果指令来晚了，数据就得等，延迟就上去了。

好了，这一章的内容就到这。模块划分和数据流是理解延迟的基础，下一章我们会深入每个模块的延迟建模方法。

---