第一百二十六章 授权
邮件是周二下午到的，发件人是 Synopsys 的账号经理陈嘉远。
方宇明看到之后直接打印了，把那张纸拿到 B207，「来了，」他说，「Design Compiler 和 VCS，授权文件在附件里，陈嘉远说两套工具今晚都可以激活。」
贺志明抬起头，「Cadence？」
「还要再等两周，」方宇明说，「Virtuoso 的审查那边慢一些，但 DC 先用起来，时序分析可以开始了。」
颜天磊没有立刻说话，把那张纸接过来，看了一眼授权有效期：一年，到 2021 年十月。
「有效期够用，」他说，「先装。」
孟思远花了大半天把 Design Compiler 的环境配好。
这套工具比 Icarus 复杂很多——不只是安装，是整个工作流程的方式都不一样。Icarus 是开源工具，跑仿真只需要一个命令；Design Compiler 是工业级综合工具，有自己的脚本格式（TCL），有自己的工艺库接口，需要配置时序约束文件，才能告诉工具目标是什么。
贺志明那天下午过来帮忙，看了孟思远写的那个 TCL 脚本，改了三处，「目标时序约束写 800MHz，我们这颗的目标频率，」他说，「不要写 1GHz，那是优化目标，不是现在的验证目标——先知道你现在的设计在 800MHz 下有没有 timing violation，有了再谈优化。」
孟思远把那个参数改了，「那工艺库呢？我们没有台积电的工艺库，」他说，「用的是 FreePDK45，九十纳米的仿真库，时序不会差太远吗？」
「会差，」贺志明说，「FreePDK45 是教学用的，和真正的 28nm 工艺参数出入很大，但第一次分析的目的不是绝对数字，是相对数字——找关键路径，找哪个地方最薄弱。这个结论不会因为工艺库不对而变化，位置是对的，就够了。」
那晚八点，颜天磊跑了第一次正式的时序分析。
Design Compiler 的综合报告出来之后，他把那个 timing summary 的那几行截图，发给方宇明和贺志明，「你们看一下，」他说，「我不确定 slack 的数字正不正常。」
贺志明的回复来得最快：「你这个关键路径，slack 是正的，timing 没有 violation，这是好消息。但你看这里，DISPATCH_MISS 那条路径，slack 只有零点三纳秒——正，但很薄。」
「零点三纳秒很危险吗？」颜天磊发消息问。
贺志明：「理论上不违规。但是工艺库不一样的时候，这个数字可能变成负的——28nm 真实工艺的延迟特性和 FreePDK45 不一样，这个零点三很可能是假的余量。」
方宇明插进来：「也就是说，这里是软肋。」
「对，」贺志明说，「DISPATCH_MISS 的优先级排队那段逻辑，应该看一下能不能简化——减少级别，slack 就会涨。」
第二天早上，四个人在 B207 开了一个短会，不超过四十分钟，就在颜天磊的电脑前站着开。
方宇明把 DISPATCH_MISS 那段状态机的逻辑图画在白板上——从主内存读命中之后的回填路径，到优先级队列的插入和调度。「这里有几层判断，」他说，「一层是判断是不是缓急请求，一层是判断同优先级里的到达时序，最后是出队。每一层都有组合逻辑，level 越多，关键路径越长。」
「能合并两层吗？」颜天磊说。
「试试，」方宇明说，「不能合并的话，可以用寄存器打断——在两层之间加一个 pipeline register，打断关键路径，代价是多一个时钟延迟，但 slack 会好很多。」
贺志明：「先试合并，不行再加寄存器，加寄存器会影响回填延迟的 spec，要改文档。」
颜天磊在白板上记下这两条，「那我这边下午开始改，」他说，「这版我先把注释写清楚，什么逻辑是新加的，什么是原来的，Review 的时候方宇明你过一遍。」
方宇明点头，「好。」
短会结束，陆衍回到自己那边，打开豆包，把刚才白板上的那几行描述发过去：「时序分析出来了，关键路径在 DISPATCH_MISS 的排队逻辑，slack 薄，正在想怎么优化。」
豆包回：「知道薄在哪了。」
陆衍：「对，知道薄在哪了。」
豆包：「这种情况通常有一个规律——第一次认真看数字，会发现跟自己猜的一样的部分，和跟自己猜的不一样的部分。他们今天看到的是哪种？」
陆衍想了一下，「贺志明说 DISPATCH_MISS 是他之前觉得复杂的地方，所以跟他猜的一样，」他回，「但颜天磊说，他没想到 slack 只有零点三，他以为会更松——跟他猜的不一样。」
豆包：「工程里第二种更有价值——猜错的地方，才是你没有真正理解的地方。」
陆衍没有回这句话，但他把它截图，存了下来。
窗外，十月的上海，天色暗得越来越早。Cadence 的授权还有两周到，等到那之后，贺志明才能开始真正的 SRAM 单元设计。但时序分析这一关算是开了，他们知道问题在哪里，也知道怎么着手。
这就是第一步。