1. 延迟概述：5G基带数据通路的基本概念与延迟定义

1.1 什么是基带数据通路？

先问大家一个问题：你手机里发的微信消息，从按下发送键到对方收到，中间到底经历了什么？

嗯，这个问题其实挺复杂的。但作为基带工程师，我们关心的核心路径，就是基带数据通路。

说白了，基带数据通路就是一条从MAC层到天线口的数字信号处理流水线。我习惯把它想象成一条高速公路——数据包从入口进来，经过编码、调制、层映射、资源映射、OFDM生成，最后从出口出去。

我在项目中遇到过不少新人，一上来就盯着某个模块的微架构优化，结果发现整个通路的瓶颈根本不在那里。所以，理解整条通路的结构，比死磕某个细节更重要。

1.2 延迟的组成：到底哪些环节在“吃”时间？

一条典型的5G下行数据通路，延迟可以拆成这几块：

• 处理延迟：DSP算法、编解码、FFT/IFFT的计算时间
• 存储延迟：数据在FIFO、Buffer、DDR中的排队和读写时间
• 传输延迟：数据在总线（如AXI）、片间接口（如CPRI/eCPRI）上的搬运时间
• 调度等待延迟：等待调度器分配时频资源的排队时间

你想想看，一个5G的slot是0.5ms（子载波间隔30kHz时）。如果处理延迟占了0.3ms，那留给传输和调度的余量就非常紧张了。

我记得有一次做系统联调，发现某个链路的延迟总是超标。查来查去，最后发现是DDR访问的bank冲突导致读延迟增加了30%。这种问题，光看RTL仿真根本看不出来，必须做全链路的延迟分析。

1.3 延迟的度量：用什么尺子量？

在5G基带设计中，我们常用的延迟度量单位是：

度量单位	典型值	适用场景
时钟周期	1~10 cycle	RTL微架构级分析
微秒 (μs)	10~100 μs	模块级处理延迟
毫秒 (ms)	0.5~4 ms	Slot级/子帧级延迟
TTI (传输时间间隔)	0.125~1 ms	系统级调度延迟

我个人习惯在做RTL设计时，先用时钟周期来卡每个模块的流水线级数。等系统集成后，再用微秒级来验证整条通路是否满足3GPP的时序要求。

1.4 延迟的“天花板”：3GPP给了什么约束？

3GPP对5G NR的用户面延迟有明确要求：

• eMBB场景：单向延迟 ≤ 4 ms
• URLLC场景：单向延迟 ≤ 0.5 ms（甚至更低）

这意味着什么？

对于URLLC，从数据到达L1到天线口发射，总共只有0.5ms。如果基带处理占了0.3ms，那留给射频和空口的余量就只有0.2ms了。说实话，这个余量非常紧张。

我曾经参与过一个URLLC项目，为了把处理延迟从0.35ms压到0.25ms，我们改了三次微架构：第一次优化了LDPC编码器的流水线，第二次把资源映射从串行改成了并行，第三次干脆把部分处理逻辑从软件搬到了硬件。

1.5 延迟分析的核心逻辑：一张图说清楚

下面这张图，是我自己总结的延迟分析框架。每次开始一个新项目，我都会先画出这张图，然后逐段分析。

这张图里，我特意把延迟分成了四段。每一段都有不同的优化手段。比如处理延迟靠微架构和算法优化，存储延迟靠减少buffer深度和优化DDR访问模式，传输延迟靠提高总线带宽和降低协议开销。

1.6 一个真实案例：0.5ms的“生死线”

最后分享一个我亲身经历的故事。

有一款5G小基站芯片，目标延迟是0.5ms。第一次流片回来后，实测延迟是0.72ms。整整多了0.22ms。

我们花了两个月做延迟分析，最后发现三个主要问题：

1. LDPC编码器的流水线深度太大，占了0.15ms
2. DDR访问因为bank冲突，额外多了0.05ms
3. 调度器的软件任务切换开销，占了0.02ms

后来我们做了三件事：把LDPC编码器从5级流水改成3级（面积增加了15%，但延迟降了0.08ms）；优化了DDR的地址映射策略；把调度器的关键路径从软件改成了硬件状态机。

最终，延迟降到了0.48ms。嗯，刚好卡在生死线上。

所以，延迟分析这件事，真的不能等到流片回来再做。从架构设计阶段就要开始算，每个模块都要有明确的延迟预算。