3. 延迟来源：处理延迟、传输延迟与排队延迟的成因分析
各位做基带的朋友，咱们今天聊聊延迟的三个核心来源。说实话，很多刚入行的工程师喜欢把延迟笼统地归为「处理慢」或者「网不好」。但真正做系统优化时，你会发现——延迟的根因必须拆开看。处理延迟、传输延迟、排队延迟，这三兄弟的脾气秉性完全不同，优化手段也天差地别。
我个人习惯是，拿到一个延迟超标的问题，先问三个问题：
是算不过来？是搬不动？还是堵住了？
这三个问题，正好对应我们今天要讲的三种延迟。
3.1 处理延迟：算力与算法的博弈
处理延迟，说白了就是数据在计算单元里「排队等算」的时间。从LDPC译码到FFT变换，从信道估计到MIMO检测，每一个算法模块都在消耗时钟周期。
处理延迟的公式很简单：
处理延迟 = 处理数据量 / 处理吞吐率但实际项目中，这个公式背后藏着很多坑。我遇到过最典型的情况——某次5G小站开发，PDSCH译码延迟总是超标。查来查去，发现是LDPC译码器的迭代次数设成了固定值。其实大部分子帧在8次迭代时就已经收敛了，但我们傻傻地跑了15次。白白多了近一倍的延迟。
处理延迟的成因可以归纳为以下几点：
- 算法复杂度： 比如MIMO检测的ML算法 vs MMSE算法，延迟差距可能在10倍以上
- 硬件并行度： 同样的FFT，用串行架构和流水线架构，延迟天差地别
- 时钟频率： 这个不用多说，频率越高，处理越快，但功耗也上去了
- 数据依赖： 有些模块必须等前一级算完才能开始，这就是典型的「气泡」
我记得有一次做RTL设计评审，一个同事把译码器的输入缓冲设计成了乒乓结构。理论上吞吐率翻倍了，但延迟反而增加了——因为乒乓切换引入了额外的等待周期。嗯，这里要注意：吞吐率和延迟不是一回事，优化时别搞混了。
3.2 传输延迟：数据搬移的物理代价
传输延迟，就是数据从一个模块搬到另一个模块所花的时间。你想想看，在5G基带里，数据量动辄几百Mbps甚至Gbps级别，这些数据要在DDR、片上SRAM、加速器之间来回穿梭。
传输延迟的构成：
传输延迟 = 传输距离 / 传输速率 + 协议开销这里的「传输距离」不是物理距离，而是逻辑距离——数据经过了多少级总线、多少层协议栈。
我在项目中遇到过最典型的传输延迟问题，是AXI总线上的读延迟。某个加速器需要从DDR读取配置参数，每次读请求都要经过：
加速器 → AXI Interconnect → DDR控制器 → DDR颗粒 → 原路返回。
这一来一回，光总线延迟就占了200多个时钟周期。如果配置参数是频繁读取的，这个延迟会直接拖垮整个流水线。
| 传输场景 | 典型延迟 | 瓶颈点 |
|---|---|---|
| 片上SRAM读写 | 2-5 时钟周期 | 地址译码、读写冲突 |
| AXI总线传输 | 10-50 时钟周期 | 仲裁、握手、乱序重排 |
| DDR读写 | 50-200 时钟周期 | 行激活、列选、预充电 |
| 片间SerDes | 微秒级 | 串行化、编码、同步 |
传输延迟的优化思路，我个人总结为三个字：近、快、少。
近——把数据放在离计算单元最近的地方；
快——用更高速的总线或接口；
少——减少不必要的搬移，能复用就复用。
3.3 排队延迟：资源争抢的连锁反应
排队延迟，是最容易被忽视的延迟来源。为什么？因为它在系统不忙的时候几乎不存在，一旦系统负载上来，排队延迟会像滚雪球一样越滚越大。
排队延迟的本质是资源争抢。多个数据流同时请求同一个资源（比如DDR带宽、译码器、总线），就必然有人要排队。
用排队论的话来说，排队延迟 = 服务时间 × 队列长度。但实际系统中，队列长度是动态变化的，而且受流量突发性的影响很大。
我记得有一次做系统联调，单用户测试时延迟完全达标，但一加用户就超标。查了三天，发现是共享的LDPC译码器成了瓶颈。多个HARQ进程同时请求译码，队列深度不够，导致大量请求被阻塞。
- 多个CCE共享同一个DDR通道
- 多个HARQ进程竞争译码器
- 上行和下行数据争抢总线
- 控制信道和数据信道共享加速器
排队延迟的成因分析，我建议从三个维度入手：
- 服务速率： 资源本身能处理多快？比如译码器的吞吐率
- 到达速率： 请求来的有多快？比如每秒多少个HARQ进程请求
- 服务策略： 是先到先服务？还是优先级调度？
你想想看，如果到达速率超过服务速率，队列就会无限增长。这就是所谓的「拥塞崩溃」。5G基带里，这种情况通常发生在峰值速率场景下。
3.4 三种延迟的关联与权衡
这三种延迟不是孤立的。它们之间会相互影响，甚至相互放大。
举个例子：
处理延迟大了 → 数据在模块内停留时间变长 → 占用了更多的缓冲资源 → 导致其他数据流排队 → 排队延迟增加 → 系统整体延迟飙升。
反过来也一样：
传输延迟大了 → 数据到达计算单元的时间变晚 → 计算单元空闲等待 → 处理效率下降 → 等效处理延迟增加。
所以，优化延迟不能只盯着一个点。我个人的做法是：
先做延迟分解，搞清楚每种延迟占多少比例；
再做瓶颈定位，找到占比最大的那个；
最后做针对性优化，但要注意不要引发新的瓶颈。
- 用性能计数器统计每个模块的延迟
- 画出延迟瀑布图，看哪一级贡献最大
- 针对最大贡献级，判断是处理、传输还是排队问题
- 制定优化方案，并评估对其他延迟的影响
好了，关于延迟来源的分析就到这里。三种延迟的成因和优化思路，其实都离不开一个核心——理解你的系统到底在等什么。是等算完？等搬完？还是等轮到？搞清楚这个，优化方向就清晰了。