第55章 落地

  左城和方泽花了整整一周，把调度器的代码从头到尾重写了一遍。不是改算法——算法不用动——而是改每一行代码的实现方式，让它在有限的內存空间里儘可能高效地运行。

  七天后重新上板。峰值內存占用——一点七八兆。稳了。系统运行了十二个小时，没有崩溃，没有溢出，调度器的响应时间和仿真结果完全吻合。

  方泽靠在椅背上长出了一口气。他的眼镜片上有两个明显的指印——这一周他推眼镜的频率比平时高了三倍。

  “这种活儿比写算法累多了。“他难得抱怨了一句。

  “算法是创造，工程优化是雕刻。“左城说，“两种累法。“

  但这只是第一个模块。

  接下来的三周里，同样的问题在其他三个模块上依次出现。自適应参数共享引擎的內存问题更严重——环形缓衝区在dsp上的对齐要求和仿真环境不同，导致实际占用比预期多了百分之三十。波束协同控制器的问题不在內存，在时序——fpga的时钟频率和仿真的理想时钟有微小的偏差，导致分层精度切换的判断逻辑偶尔会错过一个时钟周期，造成波束指向的瞬间抖动。

  频谱感知前端反而是最顺利的——因为这个模块的嵌入式优化在架构设计阶段就已经做到位了，定点化、dma流水线、候选循环频率预筛选，每一步都是针对真实硬体设计的，上板后只做了几处寄存器配置的小修改就跑通了。

  “之前砍的那三刀没白砍。“刘伟感慨了一句。

  六月底，四个模块全部完成了上板移植和初步联调。

  左城在白板上更新了进度，第一里程碑的八月节点，目前来看可以按时达成。但中间还有一个关键步骤没有完成：四个模块之间的联合测试。

  单独跑每个模块都没问题，但四个模块同时运行在一块板卡上、共享同一块內存、爭抢同一个总线带宽的时候，会不会出新的问题？

  左城知道答案：一定会！联调的bug永远比单模块测试多，而且往往更隱蔽、更难復现。这是工程开发的铁律。

  七月初他召开了一次內部会议，把联调计划从头到尾过了一遍。

  “联调分三轮。“他在白板上画了一个时间轴，“第一轮：双模块联调，两两配对测试兼容性，预计一周。第二轮：三模块联调，重点测试资源竞爭和时序衝突，预计一周半。第三轮：全链路联调，四个模块加上鼎新的终端协同接口一起跑，预计两周。三轮做完，八月交样机。“