第37章 里程碑

  五月二十號，距离第一个里程碑验收还有五天。

  陈浩的信號接收与解调模块已经在嵌入式平台上跑通了，但方泽在做系统级联调的时候发现了一个问题——解调模块和左城的信道估计模块同时运行时，cpu占用率会飆到百分之九十二，留给波束管理接口和系统进程的算力几乎为零。

  “不是代码写得不好，是两个模块抢资源。“方泽凌晨两点在工作群里发了一条长消息，附了一张cpu占用率的实时曲线图，“解调模块的fft运算和信道估计模块的矩阵运算都是计算密集型任务，它们的峰值负载恰好在同一个时间窗口內叠加。单独跑都没问题，一联调就炸。“

  左城看到消息的时候是凌晨两点十分。他刚从办公室回到宿舍，准备洗漱睡觉。

  看完方泽的分析，他的困意瞬间消失了。

  这个问题在pc端不存在——pc端的cpu性能有足够的余量同时承载两个模块的峰值。但嵌入式平台的arm处理器性能有限，算力是硬约束，不可能靠升级硬体解决。

  “明天早上八点碰头。“左城在群里回了一句，“陈浩、方泽，你们俩今晚先各自想想方案，明天一起討论。“

  陈浩秒回了一个“好“。方泽回了句“我已经在想了“。

  第二天早上，三个人在办公室白板前站了两个小时。

  陈浩的方案是降低解调模块的fft精度——用更短的fft长度来减少计算量。但这样做会牺牲解调性能，蓝湾通信的验收指標里对误码率有明確要求，降精度可能过不了。

  方泽的方案是做任务调度——让两个模块的峰值负载错开，用一个时分復用的调度器交替分配cpu资源。思路可行，但调度器本身的开销和时延引入需要精確控制，实现难度不小。

  左城站在白板前，盯著方泽画的调度示意图，脑子里那枚融合叶片的“手感“又开始发热了。

  “方泽的思路对，但不需要通用调度器。“他拿起笔，在白板上画了一条时间轴，“解调模块的fft运算有固定的周期性——每个符號周期执行一次，执行时间可预测。信道估计模块的矩阵运算也是周期性的，但周期更长。两个周期之间存在一个天然的空隙——fft结束之后、下一个符號周期开始之前，有大约零点三毫秒的空閒窗口。“

  他在时间轴上標出了那个空隙。

  “把信道估计的矩阵运算拆成小块，每块的计算量控制在零点三毫秒以內，塞进fft的间隙里执行。不需要调度器，靠的是两个模块自身的时序配合——解调模块执行完一个fft就发一个信號量，信道估计模块收到信號量就开始执行一个小块，执行完就释放cpu。“