第4章 动态优先级仲裁：让总线学会“看人下菜碟”

静态优先级仲裁，说白了就是给每个主设备发一张“永久VIP卡”。高优先级的设备永远插队，低优先级的设备可能永远等不到服务。我在项目中遇到过这种情况：一个低速传感器接口因为优先级太低，在极端负载下数据包连续丢失，导致整个系统报警。嗯，这就是静态仲裁的硬伤。

动态优先级仲裁，就是让总线学会“看人下菜碟”。它会根据每个请求者的历史行为、等待时间、当前负载，动态调整优先级。你想想看，这就像银行柜台不再只看客户等级，还会看谁排得最久、谁的业务最紧急。

4.1 为什么需要动态优先级？

先看一个真实场景。一个SoC芯片里，CPU、GPU、DMA、USB控制器、以太网MAC，五个主设备共享一条AXI总线。静态仲裁下，CPU永远是最高优先级。但问题来了：

• CPU突发访问时：DMA的批量传输被频繁打断，吞吐量下降30%
• GPU渲染帧时：USB的实时音频流出现断断续续的卡顿
• 以太网收包时：低优先级的传感器数据被饿死，系统误报故障

我当年调试一个车载摄像头系统，就踩过这个坑。摄像头数据通过DMA写入DDR，但CPU的中断服务程序总是抢总线。结果呢？摄像头帧率从30fps掉到12fps，图像直接撕裂。后来换成动态优先级仲裁，问题才解决。

4.2 基于历史负载的优先级调整

这种方法的核心是：记录每个主设备在过去一段时间内的总线占用情况，然后动态调整其优先级。

具体怎么做？我习惯用一个滑动窗口计数器。每个主设备都有一个N拍的历史窗口，记录它在过去N个时钟周期里是否占用了总线。窗口里“1”越多，说明它最近越活跃，优先级就应该适当降低。

4.2.1 滑动窗口算法

// 伪代码：滑动窗口历史负载计算
#define WINDOW_SIZE 16  // 16拍历史窗口

typedef struct {
    unsigned int history;      // 16位移位寄存器
    unsigned int load_count;   // 窗口内"1"的个数
    unsigned int base_prio;    // 基础优先级（静态配置）
    unsigned int dynamic_prio; // 动态调整后的优先级
} master_t;

// 每个时钟周期更新
void update_history(master_t *m, int granted) {
    // 左移一位，新结果写入最低位
    m->history = (m->history << 1) | (granted ? 1 : 0);
    
    // 重新计算负载计数
    m->load_count = count_ones(m->history);
    
    // 动态优先级 = 基础优先级 + 负载惩罚
    // 负载越高，优先级越低（数值越大优先级越低）
    m->dynamic_prio = m->base_prio + (m->load_count >> 2);
}

你看，这个算法很简单。基础优先级由系统架构师在设计时配置，比如CPU是0，GPU是1，DMA是2。然后根据历史负载，每4次总线占用就加1级惩罚。这样，一个频繁抢总线的CPU，它的动态优先级会逐渐升高（数值变大，优先级降低），给其他设备让出机会。

4.3 老化（Aging）算法：防止饿死

老化算法，说白了就是“等得越久，优先级越高”。它专门解决低优先级设备被饿死的问题。

为什么需要老化？你想想看，即使有动态优先级调整，如果系统持续有高优先级请求，低优先级设备还是可能永远拿不到总线。老化算法给每个等待的请求者加一个“等待计时器”，等待时间越长，优先级就越高，直到最终获得服务。

4.3.1 经典老化算法实现

// 伪代码：老化优先级计算
#define AGING_THRESHOLD 100  // 老化阈值（时钟周期）
#define AGING_STEP      10   // 每等待10拍优先级提升1级

typedef struct {
    unsigned int wait_cycles;  // 当前请求已等待的时钟周期数
    unsigned int base_prio;    // 基础优先级
    unsigned int aging_prio;   // 老化后的优先级
    int          request_active; // 是否有未完成的请求
} requestor_t;

void aging_update(requestor_t *r) {
    if (r->request_active) {
        // 有请求在等待，计时器递增
        r->wait_cycles++;
        
        // 老化优先级 = 基础优先级 - 等待时间/步长
        // 等待越久，数值越小，优先级越高
        r->aging_prio = r->base_prio - (r->wait_cycles / AGING_STEP);
        
        // 防止优先级溢出（变成负数）
        if (r->aging_prio > r->base_prio) {
            r->aging_prio = 0;  // 最高优先级
        }
    } else {
        // 没有请求，重置计时器
        r->wait_cycles = 0;
        r->aging_prio = r->base_prio;
    }
}

// 仲裁时，选择aging_prio最小的请求者
int arbiter_select(requestor_t reqs[], int count) {
    int min_prio = MAX_PRIO;
    int selected = -1;
    
    for (int i = 0; i < count; i++) {
        if (reqs[i].request_active && reqs[i].aging_prio < min_prio) {
            min_prio = reqs[i].aging_prio;
            selected = i;
        }
    }
    return selected;
}

这里有个关键点：基础优先级数值越小，优先级越高。老化算法让等待时间越长，优先级数值越小，最终可能超过所有高优先级设备。我曾经在一个多核处理器项目中，用这个算法解决了某个核心长期拿不到L2缓存的问题。

4.4 动态优先级 vs 静态优先级：对比分析

对比维度	静态优先级	动态优先级（历史负载）	动态优先级（老化）
公平性	差，低优先级可能饿死	中等，高负载设备会被压制	好，等待时间决定优先级
实时性	好，高优先级响应快	中等，优先级会波动	中等，老化可能延迟紧急请求
吞吐量	高，但可能不均衡	高，负载均衡好	中等，老化过程有开销
硬件开销	低，几个比较器即可	中等，需要移位寄存器和计数器	中等，需要计时器和减法器
适用场景	硬实时系统，优先级明确	多媒体、数据流处理	通用计算、多任务系统

我个人习惯：混合使用。基础优先级用静态配置保证实时性，老化算法防止饿死，历史负载调整做负载均衡。三个机制配合，基本能覆盖大部分场景。

4.5 动态优先级仲裁器架构

下面这张图是我在实际项目中用过的动态优先级仲裁器架构。它把历史负载和老化算法融合在一起。

这个架构里，每个请求者都经过两条路径：历史负载路径和老化路径。历史负载路径计算“你最近是不是太贪心了”，老化路径计算“你等了多久了”。两条路径的结果在优先级合成模块里合并，最终交给仲裁器做选择。

4.6 实战中的调优参数

动态优先级仲裁不是配好参数就能跑。我总结了一套调优流程：

1. 确定基础优先级：根据系统实时性要求，给每个主设备分配静态优先级。硬实时设备（如中断控制器）给最高优先级。
2. 设置老化阈值：我一般从100个时钟周期开始试。如果低优先级设备仍然饿死，就减小阈值；如果高优先级设备抖动太大，就增大阈值。
3. 调整老化步长：步长决定了“等多久优先级提升一级”。步长太小，优先级变化太频繁；步长太大，老化效果不明显。我习惯用10-20拍。
4. 配置历史窗口：窗口大小影响负载评估的灵敏度。窗口太大，对突发不敏感；窗口太小，优先级抖动大。16或32是个不错的起点。
5. 验证极端场景：构造所有设备同时请求、某个设备持续请求、设备请求频率突变等场景，观察仲裁行为是否符合预期。

4.7 一个真实案例

最后分享一个我调过的案例。一个AI加速芯片，内部有4个DMA引擎、2个CPU集群、1个视频编解码器，共享一条AXI4总线。最初用静态优先级，CPU总是最高优先级。结果视频编解码器在4K编码时频繁掉帧。

我做了三件事：

• 给视频编解码器一个较高的基础优先级（保证实时性）
• 给DMA引擎启用老化算法（防止批量传输被饿死）
• 给CPU集群启用历史负载调整（CPU忙时自动降权）

调完之后，视频编码稳定在30fps，DMA传输吞吐量提升40%，CPU的响应延迟只增加了不到5%。嗯，这就是动态优先级仲裁的魅力。