2026年了，FPGA工程师做DDR4读写测试，发现多端口仲裁带宽分配不均，除了轮询还有哪些公平性调度算法能落地？

轮询饿死视频端口这事太典型了，本质是它把四个口当成了平等流量，可视频是持续高带宽的流，其它三个口是突发型，你用固定轮询，视频每次只拿1/4，但它的需求可能是1/2。落地最简单的改法是加权轮询WRR，给视频口设大权重，比如8:2:2:2，RTL里就是个计数器加比较器的事，不需要改仲裁状态机太多。你先按这个调，大概率帧率就上来了。面试官问起来，你就说关键不是算法名字，而是你意识到带宽需求要按流量特征建模，而不是拍脑袋给优先级。你仿真时记得把视频口的平均带宽和最大等待延迟都拉出来看，光看吞吐会骗人。你现在用的DDR4是几颗die，Bank-group数量多少？这个会影响你权重能不能兑现。

说个跟轮询不一样的思路：差额轮询DRR，它比WRR好在不用预先给死权重，而是每个口维护一个信用额度，每次服务时给额度加上该口的配额，然后按额度高低决定谁先发。视频口配额设大，它每次都能攒够额度连续发好几笔，其它口攒得慢但不会被饿死，因为额度会一直累加，总有轮到的时候。RTL实现就是每个口一个累加器加一个比较器，状态机比轮询稍复杂一点，但也就多几十行。你视频拼接场景有个坑：DRR的公平是长期统计意义上的，短期看视频口可能还是偶尔等很久，所以一般要配合一个紧急度信号，比如视频口FIFO水位超过80%就直接插队一次，这个叫紧急度优先跟DRR的混合调度，工程上很常用。你仿真对比时别只看平均延迟，要盯最大延迟和抖动，视频卡顿是峰值延迟超了阈值，不是平均值的问题。面试官如果追问权重怎么定，你就说按各端口的实测带宽需求占比来初设，再根据丢帧率迭代，没有一步到位的公式。你那边四个口除了视频，另外三个是CPU还是网络？流量特性不同，配额设计差别挺大的。

别急着换算法，先搞清楚饿死的根因是仲裁粒度还是DDR效率。很多人一上来就怪轮询不公平，其实轮询本身是公平的，问题是它把DDR的访问请求拆得太碎：视频口每轮只发一笔64B，DDR要频繁切换行和Bank-group，效率掉到只有峰值的一半，实际带宽根本不够。这时候你换WRR或DRR，如果还是每轮只发一小笔，照样饿死。所以工程上更常见的做法是加大仲裁粒度，比如轮询时一次服务连续发4笔或8笔，让视频口每次拿到一个burst，DDR的行命中率就上去了。这个叫burst-oriented arbitration，比纠结WRR还是DRR更先要解决。你面试时能讲到这一层，比背算法名字强多了。具体到DDR4，还要考虑Bank-group并行度：你把视频口的连续8笔尽量散到不同的Bank-group里，这样DDR可以并行预充电，延迟能降不少。落地RTL的话，仲裁状态机里加一个count寄存器，每轮服务完清掉，视频口配额大就count设大；另外可以把紧急度做成动态的，视频FIFO水位超阈值时把它的count临时翻倍，这个实现成本很低，就是多一个比较器和MUX。仿真波形对比你重点抓两件事：一是DDR总带宽利用率，二是视频口每帧读取完成的时间戳抖动。前者衡量你的仲裁是否浪费了DDR能力，后者直接对应掉帧。我见过有人调了三天权重没用，最后发现是写侧命令和读侧命令没有分开仲裁，读被写堵死了，这种DDR控制器架构层面的坑比调度算法更隐蔽。你如果面试被问权重怎么动态调，可以说按帧率反馈做闭环，掉帧就加权重，稳了就减一点，类似AIMD，虽然听起来土，但工程上真的有效。你目前DDR控制器的读和写是分开的队列还是共用的？如果是共用的，那饿死可能不只是仲裁的问题。

面试官问这个，其实不是考你背算法名字，是想看你会不会把「带宽分配」和「延迟抖动」分开看。轮询饿死视频口，根子往往是仲裁粒度太细，DDR4 每次切换行开销大。先试试把每轮服务改成连续发 4~8 笔，让视频口拿到完整 burst，很多时候不用换算法就解决了。

我做过类似的四端口视频拼接，轮询饿死这个问题，当时先量化了每个端口的实际需求，发现视频口要占 55% 带宽，而轮询只给 25%，那必然掉帧。后来改用 WRR，权重设成 6:2:2:2，RTL 里就是一个计数器加比较器，状态机改动很小。但有个坑：DDR4 的 Bank-group 并行度会影响权重兑现，如果视频口的连续请求都挤在同一个 bank-group，就算给了大权重，DDR 内部还是要串行预充电，实际带宽上不去。所以我把视频口的 burst 打散，让连续 8 笔地址尽量分布在 4 个 bank-group 里，这样行命中率明显改善。仿真时我对比了平均延迟和最大延迟，WRR 的平均延迟好看，但视频口偶尔还是会等很久，于是又加了个紧急度信号，视频口 FIFO 水位超过 80% 就直接插队一次。这个混合方案在工程上很常见，面试时能讲出「权重设置要结合 DDR 物理特性」这个层次，比单纯背 DRR 公式强多了。你现在用的 DDR4 是几颗 die，bank-group 数量是多少？

其实还有个思路：时间片轮询，但把时间片设成跟视频帧周期对齐。比如视频是 60fps，每帧 16.6ms，你就把仲裁周期设成 16.6ms 的整数分之一，视频口在每帧内保证拿到固定比例的带宽，其他口在剩余时间片里抢。这个做法在视频拼接场景特别好用，因为帧率是硬约束，只要每帧内视频口的总服务时间够，就不卡顿。RTL 实现就是一个大计数器，每到一个时间片就把对应端口的门控打开，其他口用普通轮询抢剩下的。缺点是时间片切换有边界延迟，但视频口可以靠 FIFO 吸收。面试官如果追问时间片怎么选，你就说按视频口的最小可接受带宽反推，比如需要 50% 带宽，时间片就设成 50% 对 50%，再留点余量。这个方案比 WRR 更直观，但灵活性差一点，权重改了要重新算时间片。

说个踩过的坑：一开始我迷信 DRR，觉得它公平性好，RTL 写完了仿真也过了，上板才发现视频口还是偶尔卡一下。后来查出来是 DRR 的额度累加在极端情况下会让视频口等很久，因为其他口虽然攒得慢，但一旦攒够就能插队。后来我在 DRR 基础上加了个「最长等待时间」计数器，每个口从上次被服务开始计时，超过 100us 就强制提升优先级。这个叫 delay-based scheduling，比单纯看水位更稳，因为水位只反映瞬时压力，而等待时间反映了公平性。工程上建议把轮询、WRR、DRR 各写一个模块，用参数切换，仿真时用不同的地址分布和 burst 长度去压测，看哪种在目标和场景下 P95 延迟最低。面试时如果能说出「调度算法没有银弹，要按流量特征和 DDR 物理特性组合使用」，基本就过关了。

直接说结论：先别换算法，把仲裁粒度从 64B 提到 256B，让视频口每次拿到连续 4 笔，DDR4 的行命中率能提升 30% 以上。如果还不够，再上 WRR，权重按实测带宽需求设，比如视频 60%、其他三个口各 13% 左右。RTL 里权重就是几个比较器，不复杂。但注意，WRR 的公平是长期统计的，短期视频口可能还是等，所以建议在视频口 FIFO 快满时加一个紧急度旁路，直接让它插队。仿真时别只看平均吞吐，要画最大等待延迟的波形，视频卡顿是峰值超阈值，不是平均值的问题。面试官如果问权重怎么定，就说按各端口实测带宽占比来，别拍脑袋。

2026 年工程上其实很少用纯学术那套 DRR/WRR 了，更多是「多级调度」：第一级按端口分组，视频口单独一个队列，其他口合并成一个组；第二级组内用轮询，组间用加权。这样视频口天然拿到 50% 带宽，其他口内部再公平竞争。RTL 实现就是两个仲裁器级联，面积增加不大。你仿真时可以对比单级 WRR 和多级调度的最大延迟，后者在视频口 FIFO 深度有限时更稳，因为视频口的服务间隔更均匀。面试官如果问为什么，你就说多级调度减少了端口间的耦合，避免一个口突发吃满所有带宽。

面试被问到这个，其实核心考点是「你懂不懂带宽分配和延迟的权衡」。轮询是公平但低效，优先级是高效但可能饿死，WRR 和 DRR 是在两者之间找平衡。建议你准备一张表，横向对比四种算法的吞吐、最大延迟、实现复杂度，再结合 DDR4 的 bank-group 特性说一句「调度要跟物理层配合」。面试官追问时，你可以举视频拼接的例子：视频口需要持续高带宽，但能容忍一定延迟；其他口是突发型，对延迟敏感但带宽需求低。所以用 WRR 给视频口大权重，再给其他口加一个「最长等待时间」上限，超过就临时提权。这个方案在工程上很稳，面试官会觉得你有实战经验。