2. 静态调度原理：编译时调度、静态优先级分配、无冲突数据路径
静态调度，说白了就是“在程序还没跑的时候，就把活儿排好”。
我刚开始接触数据流调度时，总觉得动态调度更灵活——运行时看情况分配资源，多聪明啊。直到我在一个边缘设备项目里，被动态调度的开销狠狠教训了一回。那时候我才明白，对于固定数据流图，编译时就把调度方案定死，才是真正的降维打击。
2.1 编译时调度：把决策提前到编译期
静态调度的核心思想很简单：既然数据流图是固定的，那调度方案也是固定的。编译器在生成代码时，就为每个算子分配好执行时间片和计算单元。
核心优势：运行时零调度开销。没有任务队列、没有优先级仲裁、没有上下文切换——这些在静态调度里统统不存在。
我记得有一次优化一个视频处理管线，动态调度下每帧有 3%~5% 的 CPU 时间花在调度器本身。改成静态调度后，这部分直接归零。你想想看，对于 30fps 的实时流，这 3% 可能就是丢帧与流畅的差别。
编译时调度通常分三步走：
- 数据流图分析：遍历整个计算图，标记每个算子的依赖关系
- 拓扑排序：生成一个无环的执行顺序
- 时间槽分配：为每个算子分配固定的启动时间
举个简单的例子，假设我们有三个算子 A、B、C，其中 B 依赖 A 的输出，C 依赖 B 的输出：
// 编译时生成的静态调度表
// 时间单位：时钟周期
// 假设每个算子执行耗时 2 个周期
时间槽 0-1: 算子 A (PE0)
时间槽 2-3: 算子 B (PE0)
时间槽 4-5: 算子 C (PE0)
// 如果有多核 PE1 可用，可以并行：
时间槽 0-1: 算子 A (PE0), 算子 D (PE1) // D 与 A 无依赖
时间槽 2-3: 算子 B (PE0), 算子 E (PE1)
我的习惯：在编译时调度中，我会额外生成一个“调度有效性检查表”。这个表在运行时几乎不消耗资源，但能在硬件故障时快速定位问题。曾经有一次，就是因为这个检查表，我在十分钟内找到了一个隐蔽的时序违规。
2.2 静态优先级分配：谁先跑，谁后跑
静态优先级分配，是编译时调度的“进阶玩法”。
当多个算子可以并行执行，但计算资源有限时，就需要决定谁先占用资源。静态优先级分配在编译期就排好这个顺序，运行时直接按优先级表执行。
我常用的优先级分配策略有这三种：
| 策略 | 原则 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 最长路径优先 | 关键路径上的算子优先级最高 | 延迟敏感型应用 | 曾经忽略了分支路径，导致非关键路径饿死 |
| 最短执行时间优先 | 执行快的算子先跑 | 吞吐量优先场景 | 小算子频繁抢占，大算子迟迟得不到执行 |
| 数据依赖深度优先 | 依赖链更深的算子优先 | 流水线密集型应用 | 这个策略我目前用得最顺手，很少出问题 |
嗯，这里要注意：静态优先级一旦定下来，运行时就不能改了。所以优先级分配必须考虑最坏情况。我曾经在一个项目中，按平均执行时间分配优先级，结果某个算子在输入数据波动时执行时间翻倍，直接把整个流水线堵死了。
避坑指南：我曾经在静态优先级分配时，只考虑了算子的计算时间，忽略了数据搬移时间。结果编译出来的调度表在仿真时完美运行，上板实测却频繁超时。后来我把数据搬移也建模成“隐式算子”，才解决了这个问题。
2.3 无冲突数据路径：让数据流畅通无阻
无冲突数据路径，是静态调度能跑起来的“物理基础”。
说白了，就是保证每个数据在传输过程中，不会与其他数据争抢总线、端口或缓冲区。静态调度之所以高效，就是因为它提前规划好了每条数据的“专属通道”。
我一般从三个层面来保证无冲突：
- 时间分片：不同数据流使用不同的时间窗口访问共享资源。比如总线在周期 0-1 给流 A 用，周期 2-3 给流 B 用。
- 空间隔离：为每个数据流分配独立的存储和通道。比如流 A 用 FIFO0，流 B 用 FIFO1，物理上就不打架。
- 路径规划：在编译时计算每条数据的传输路径，确保不会出现环路或交叉。
下面这张图展示了无冲突数据路径的核心逻辑：
你可能会问：这三种策略怎么选？我的经验是：
- 资源紧张时，优先用时间分片。虽然会增加延迟，但硬件成本最低。
- 延迟敏感时，优先用空间隔离。多花点存储资源，换确定性延迟。
- 拓扑复杂时，路径规划是必须的。我见过一个项目，就是因为没做路径规划，数据在片上网络里绕了 7 个路由节点才到目的地，延迟直接爆炸。
核心结论：静态调度 + 无冲突数据路径 = 确定性执行。这在实时系统和安全关键系统中是刚需。你想想看，如果自动驾驶的感知管线因为调度冲突而延迟了 1 毫秒，那可能就是生与死的区别。
2.4 静态调度的局限性
说了这么多好处，我也得泼点冷水。静态调度不是万能的。
我遇到过最头疼的情况是输入数据量不确定。比如一个算子处理一帧图像，有时需要 5ms，有时需要 50ms。静态调度按最坏情况分配时间槽，资源利用率就上不去。按平均情况分配，又可能超时。
解决办法？我一般用混合调度：主体用静态调度保证确定性，在少数不确定的算子上留一个“弹性窗口”。这个窗口在编译时预留，运行时如果不需要就跳过，需要时自动填充。
个人经验：弹性窗口的大小，我一般取算子最大执行时间的 20%。太小了不够用，太大了浪费资源。这个比例是我在三个不同项目里试出来的，你可以作为起点，再根据实际数据调整。
静态调度还有一个坑：编译时间可能很长。对于包含上千个算子的数据流图，编译时调度器可能需要跑几分钟甚至几小时。我记得有一次优化一个 5000 节点的图，调度器跑了 40 分钟。嗯，这时候就需要调度算法本身做优化了——比如用启发式搜索代替穷举。
但话说回来，编译时间长一点，换来运行时的高效和确定，在很多场景下是值得的。尤其是那些一次编译、反复运行的生产环境。