第37章 里程碑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

方泽盯著白板看了十秒钟。

“流水线插空。“他说出了这个设计的本质，“把两个模块的计算流水线咬合在一起，像齿轮一样交替转动。“

“对。“左城点头，“这样做cpu的峰值占用率不会超过百分之七十五，而且不需要额外引入调度器的开销和时延。“

“但矩阵运算拆块有讲究。“陈浩皱著眉想了想，“拆得太细会增加上下文切换的次数，拆得太粗会超出零点三毫秒的窗口。你怎么確定最优的块大小？“

“不需要手动確定。“左城写下一个公式，“信道估计矩阵的维度是已知的，fft的符號周期也是已知的，最优块大小可以直接算出来——是矩阵维度和符號周期的函数。我昨晚推过了，公式在这。“

他把公式写完，退后一步。

陈浩和方泽对视了一眼。

“城哥，你昨晚几点睡的？“陈浩问。

“三点半。“

“难怪。“方泽推了推眼镜，“行，这个方案我来实现。给我两天。“

方泽用了一天半。

五月二十二號下午，联调测试重新跑了一遍。cpu峰值占用率：百分之七十一。解调性能和信道估计精度都没有损失。两个模块的计算流水线像两组咬合的齿轮，精確地交替转动，没有任何衝突。

方泽看著监控屏幕上平稳的cpu曲线，难得地笑了一下。

“漂亮。“

五月二十四號，第一个里程碑的全部交付物准备完毕——可运行的软体版本、测试报告、技术文档，打包成一个加密压缩包，上传到蓝湾通信的项目管理平台。

101看书 读小说选 101 看书网，101??????.??????超流畅 全手打无错站

韩露同步提交了里程碑验收申请和对应的商务文档。

“验收流程一般需要三到五个工作日。“她在群里说，“预计五月底之前会有结果。“

左城回了一个“收到“，然后关掉了工作群。

手机震了一下。张磊发来的消息，不是工作群，是402四个室友的私人群。

“你们听说了吗？马昊走了。“

左城点开消息。

“什么意思？“陈浩问。

“今天去实验室碰到林老师的另一个研究生，他说马昊上个月就办了离校手续，提前毕业了。“

“去哪了？“