1. 先搞清楚CTS和Func模式SDC到底在解决什么问题做数字后端的人都有一个共识CTSClock Tree Synthesis时钟树综合是整个物理设计流程里最容易被低估、又最容易翻车的一环。很多同学在跑place的时候一切正常一到CTS就各种时序崩溃、skew超标、hold违例多到修不完最后排查下来问题往往不在CTS本身而是CTS用的SDC约束没搞对尤其是Func模式功能模式和Test模式测试模式之间切换的时候出了岔子。Innovus作为Cadence家的主力布局布线工具CTS的实现方式和传统流程相比有它的独到之处但核心逻辑仍然逃不开一套东西你给工具什么样的时钟约束它就给你长出什么样的时钟树。你给它一个不合理的uncertainty它就给你做出过分悲观的树你给它漏了generated clock它就能把分频路径做成灾难现场。这篇文章我用自己的实操经验把Innovus里CTS和Func模式SDC切换这件事拆成五个关键步骤来聊。每个步骤都会讲清楚原理、操作方法、以及我踩过的坑。适合正在做数字后端项目、准备数字后端面试、或者刚接触Innovus想系统掌握CTS流程的朋友。先明确一个概念所谓Func模式SDC是指芯片在正常工作状态下需要满足的时序约束。与之相对的还有测试模式如scan、shift、capture模式的SDC。两者的时钟设置、约束对象、时序例外都可能有很大差异而CTS需要在一组明确的约束下构建时钟树。如果在多模式场景下没有正确切换SDC就会出现CTS用Test模式建树Func模式去验收的错位情况结果自然是两者都不讨好。接下来进入正题。2. 理解Innovus多模式环境为什么CTS一定要绑定Func模式2.1 多模式分析的基本逻辑Innovus底下跑时序分析依赖的是一个叫分析视图Analysis View的机制。每个视图由三件套组成约束文件SDC、延迟文件如SPEF或Lib、工艺库Liberty。不同的工作模式——Func、Scan、Shift、Capture——各有一套自己的三件套组合。Innovus根据这些视图在底层构建一张带时序弧timing arc的时序图。CTS要做的事情是在这张时序图上找出所有需要做平衡的时钟路径然后插入buffer和inverter把同一个时钟域内的skew压到目标范围内。这里就必须强调为什么要用Func模式做CTS。时钟树综合最关心的是芯片正常工作时的时钟行为Func模式下的时钟频率最高、约束最严格时钟树需要在这种最苛刻的条件下满足时序。而Test模式下的时钟往往是从外部直接灌进来的频率低、时序要求宽松用它来指导建树树的形态和buffer的插入位置就会偏向Test模式的需求。等回到Func模式验证的时候关键路径可能已经因为时钟偏移变大而出现setup违例。2.2 Innovus里的模式切换不是换文件这么简单很多人以为在Innovus里切换SDC就是重新读一个文件的事情。实际操作里远没那么简单因为Innovus在CTS前后对时序库的加载、时钟树的抽象、以及优化引擎的目标设置都不一样。最典型的一个坑CTS之前跑place_opt的时序分析工具处理的是理想时钟ideal clock——时钟树还没生成工具默认时钟到达每个触发器的时间是相同的所以这时分析的本质上只是数据路径上的逻辑延迟。CTS做完之后时钟变成了实际时钟propagated clock这个时候分析才会把真实的clock skew和insertion delay算进去。如果你在CTS完成后才去切换SDC等于让工具在已经建好的树上用一套新的约束去分析一旦Func模式和之前建树时的约束有差异轻则大量违例重则时钟树结构需要推翻重建。所以切换动作必须在CTS启动前完成而不是事后补救。3. 核心实操CTS与Func模式SDC切换的五大关键步骤3.1 第一步Func模式SDC的预处理与质量检查这一步是所有工作的地基。拿到Func模式SDC之后别着急加载到Innovus里跑先做三件整理工作第一件把时钟定义理顺。create_clock定义的主时钟源头对不对create_generated_clock定义的分频和倍频路径全不全master clock的对应关系是否一致。我最常遇到的问题就是设计里有个通过寄存器分频产生的时钟前端给的SDC里只定义了分频后的generated clock却遗漏了分频寄存器本身的约束关系导致CTS时工具找不到这条时钟的起点最终建出来的树从根上就是歪的。第二件检查set_clock_uncertainty、set_clock_transition、set_clock_latency这三类约束是否合理。很多前端工程师习惯给出非常保守的uncertainty这在STA阶段问题不大但在CTS阶段会造成过度设计——工具为了满足过分悲观的setup约束会插入大量buffer时钟树的delay和功耗都上去了后期修hold的负担也成倍增加。第三件检查时序例外false_path、multicycle_path有没有在CTS阶段被正确识别。CTS工具在优化时依托这些例外判断哪些路径不需要做时序收敛如果漏了关键路径的false_path声明工具会花大量资源去平衡一条实际根本不需要约束的路径。做完这三件事我的习惯是用Innovus里的report_analysis_views和check_timing命令先跑一遍确认当前加载的视图组合没有悬空的约束引用。check_timing报出的warning基本都要看过一遍禁止直接跳过。3.2 第二步正确构建CTS Spec文件CTS Spec文件是整个时钟树综合的施工图纸。Innovus的CTS读取spec文件中的条目确定哪些时钟需要建树、目标latency和skew是多少、可以插入什么类型和尺寸的buffer、哪些区域禁止插入单元。构建spec文件时我最注意的参数有三个第一个是Target Skew。这个值不要直接照搬参考流程里的默认值。合理的做法是先估算当前最高频时钟的时钟周期比如Func模式下CPU时钟是500MHz周期2ns那么target skew设在50ps到100ps是一个比较合理的起点。如果设计里有很多高频时钟就需要根据时钟域的敏感度分别设置而不是所有时钟一刀切。第二个是Target Latency。这个参数是把双刃剑。设得太大工具会插很多buffer去匹配延迟设得太小工具可能选不到合适的插入点。我的经验是把target latency设定为预期实际插入延迟的1.2到1.5倍给工具留一些优化余地。当然这需要看你所用工艺节点的buffer本征延迟不同工艺节点差异很大。第三个是NDRNon-Default Rules的设定。在先进工艺下时钟树走线和普通信号走线通常采用不同的布线规则比如使用double width和double spacing来降低串扰和IR drop。CTS spec里需要为时钟网络指定专门的NDR规则名字并且确认这个规则在Innovus的tech LEF里已经定义好了。如果规则名写错Innovus常常不给明显报错而是直接用默认规则布线等你看到clock net的走线宽度不对时CTS早已跑完。构建spec文件通常有两种方式手动编写或者在Innovus里用create_clock_tree_spec命令生成模板后修改。我更推荐先用命令生成一个包含完整语法的模板文件再在这个基础上改动这样不容易漏掉必须的语法段落。3.3 第三步确认Func模式分析视图完成模式锁定这一步是整个流程里最核心的切换动作。操作逻辑是在Innovus里创建或确认一个名为func的analysis view将Func模式的SDC绑定到这个view上然后把当前工具的active view设置成这个func view。具体命令层面的常见做法是这样先用create_analysis_view命令创建视图并绑定SDC、Liberty和延迟文件。如果你的设计里使用了统一的MMMCMulti-Mode Multi-Corner文件那么views在配置阶段就已经定义好了这里只需要用set_analysis_view确认当前生效的view列表。关键是确认当前Innovus里的active analysis view确实是func模式。这一点可以用report_analysis_views命令打印当前视图信息来验证。我强烈建议在CTS执行的每一步之前都确认一下这个状态防止在调试过程中误操作把view切到别的模式去了。如果是通过MMMC文件配置的还需确认每个view下绑定的SDC是最新版本。我遇过一次非常隐蔽的问题MMMC文件里Func视图绑定的SDC路径写的是某个旧版本文件的相对路径我后来更新了SDC文件但忘了改MMMC文件里的路径引用导致Innovus加载的还是旧约束。这种错误查起来极耗时间所以养成每次改动后都检查MMMC文件内容的好习惯。在这个阶段还要做一件事确保时序库和物理库的版本匹配。Innovus在多模式切换过程中如果某个corner对应的库文件缺失或者版本不匹配工具会直接跳过该corner的时序检查。有时这在place阶段不会暴露但CTS一旦启动就会在校验阶段卡住。3.4 第四步用Func模式约束驱动CTS执行一切就绪之后正式执行CTS。在Innovus里执行CTS的方式有很多种传统流程里常用clockDesign命令也可以跑更自动化的ccopt_designCCopt流程。无论用哪一种核心机制是一样的工具基于当前active view里的时钟约束生成时钟树并做插入延迟和skew的平衡。我个人的偏好是在做复杂的先进工艺项目时尽量走CCopt流程因为它在处理片上变异和高级节点效应时明显比传统CTS更从容。但在使用CCopt时有一个需要注意的地方CCopt对SDC中时钟定义的完整性要求更高它会自动为每个定义的时钟生成时钟树并且不支持在CTS阶段对某些时钟做skip处理。如果你的设计里存在一些不需要综合的时钟比如某些模拟IP提供的慢速时钟要在SDC里用set_dont_touch_network或者通过spec文件明确排除避免CCopt对这些时钟做无谓的处理。执行CTS的过程中推荐打开Innovus的时序报告日志级别让工具在迭代过程中输出每一步的skew和latency数值。这样可以在CTS跑完之前就发现一些明显异常而不必等到CTS完成之后看最终报告才反应过来。CTS执行的这个阶段还有一件事值得做——定期使用dbGet命令检查时钟树上的单元数量和总buffer面积。如果发现某个时钟域的buffer数量异常庞大大概率是约束设置导致工具在做无意义的平衡优化需要及时终止CTS去检查约束。3.5 第五步CTS后的Func模式时序验证与残留问题处理CTS完成的标志不只是工具跑完没有报错更重要的是要回到Func模式的时序视角独立验证时钟树的质量。验证的第一步是看CTS报告里的核心指标每个时钟域的插入延迟insertion delay、全局skew、局部skew。所谓局部skew指的是在时序关系上有相互约束的寄存器组之间的skew这个值才是真正影响setup和hold的。有时候全局skew看着不大但某个关键同步单元组之间的局部skew很糟糕这同样会导致时序违例。第二步是跑setup和hold的时序分析对比CTS前后的数据。Setup在CTS之后会普遍变差因为clock skew变成了实际值Hold则可能剧烈恶化因为插入延迟使得数据到达时间和时钟到达时间的关系发生了重排。这一步如果发现hold违例太多先别急着修返回去检查建树时的uncertainty设置是否合理。如果CTS约束偏乐观hold违例就会成片出现。第三步非常关键把Test模式SDC切换回来跑一遍Test模式的时序检查确保CTS建出来的树在Test模式下也能满足要求。这一步是很多后端工程师会略过的但恰恰是CTS与Func模式SDC切换这个主题最容易出错的地方。因为CTS是服务于Func模式的建出来的树天然倾向于Func模式的需求Test模式下某些时钟的走线路径可能过长导致shift频率上不去。如果Test模式验证发现时序违例可以分两种策略去处理如果违例只在个别路径用post-CTS ECO的方式插入buffer修复如果违例广泛存在可能需要回到CTS spec里调整约束甚至调整建树策略。我个人经验是大部分项目能在第一条路径上收敛真正需要重做CTS的情况并不多见。4. 实战中的那些坑模式切换与CTS的排查记录4.1 坑一时钟门控单元被优化掉了有次做项目Func模式SDC里有一个由时钟门控ICG单元控制的子时钟域。CTS跑完之后发现这个子时钟域的skew异常大。排查了很久最后发现原因是在place阶段工具把这个ICG单元当作普通逻辑单元做了优化导致它在时钟树上的位置偏离了预期。这个问题的根源在于SDC里没有用set_clock_gating_check或者没有显式声明ICG单元是时钟网络的一部分。Innovus在place阶段无法自动识别所有ICG单元的时钟属性必须通过约束告诉它。后来我在SDC里为所有ICG单元所在的时钟网络添加了相应的约束声明CTS结果就恢复正常了。4.2 坑二切换SDC后忘了更新延迟注释做多模式切换时一个非常隐蔽的坑是Func和Test模式使用了不同的SDC但延迟注释SPEF还是CTS之前生成的。特别是当你把Test模式SDC切回来做验证的时候SPEF里记录的时钟树延迟信息可能是基于Func模式约束生成的这会让Test模式的时序分析产生错误结果。正确做法是每次切换SDC模式后重新对当前模式下的时钟树做一次延迟提取例如使用extractRC确保SPEF是匹配当前分析模式的。这样一个操作习惯能避免掉大量看起来玄学的时序问题。4.3 坑三target skew设置在CTS前后不一致还有一次很有意思的排查经历CTS结束之后setup时序收敛得不错但hold违例特别多。怎么调都降不下来最后把CTS的log翻出来发现CTS报告里的skew是80ps而我设的target skew是100ps。表面看是符合的但问题在于CTS之后我又跑了一遍时序优化optDesign这一步重新做了部分单元的尺寸调整改变了负载实际skew被拉到了150ps。这个案例的教训是CTS只是把skew优化到一个目标区间后续的优化步骤仍有可能改变时钟树上的负载分布。所以预留足够的时序裕量很重要CTS阶段的skew目标应该比后端签核目标更严格一些而不是刚好卡在边界上。4.4 常用排查命令速查场景推荐命令或操作查看内容确认当前分析模式report_analysis_views当前加载的view、SDC、库文件检查时钟定义是否完整report_clocks主时钟、generated clock的属性和关系检查CTS spec设置report_clock_tree_spec当前spec中各时钟域的约束参数查看CTS结果质量report_clock_tree_settings 或 report_ccopt_clock_treesskew、latency、buffer数量单独检查某个时钟域clock_tree -list / ccopt_report_clock_tree特定时钟域的树结构详情确认SDC版本report_constraints -all当前SDC的所有约束条目这张表是我自己在项目里经常用的供参考。需要提醒的是Innovus版本之间命令名可能有细微差别使用前先help一下对应命令确认本版本的语法。5. 从模式切换延伸开去CTS前后的工具链协同5.1 与Formality/LEC的一致性检查CTS做完之后网表里已经插入了大量buffer和inverter逻辑等价性检查LEC是必须要做的一道关卡。做LEC的时候需要把CTS之前的网表作为referenceCTS之后的网表作为implementation并且确保SDC里对时钟网络的约束描述与网表里实际的时钟连接一致。这里有个和模式切换相关的细节LEC过程中工具需要识别哪些单元是CTS工具新插入的时钟缓冲器。如果Func模式和Test模式的SDC对时钟网络的定义有差异可能影响LEC工具对这些缓冲器的识别导致误报不等价。解决办法是在做LEC之前专门为CTS后的网表生成一份一致的约束定义保持两个模式下时钟结构的统一描述。5.2 与功耗分析工具的衔接模式切换不仅影响时序也影响功耗分析。CTS做完之后时钟网络的电容显著增加动态功耗的计算需要基于真实的时钟树结构。在做功耗分析时同样需要注意分析模式与CTS建树所用的模式保持一致。特别是clock gating这种功耗优化手段不同模式下ICG单元的开关行为差异很大。Func模式下ICG使能信号大部分时间是活跃的Test模式下则可能完全不同。如果功耗分析时用了不匹配的模式得到的结果对电源网络的评估会有明显偏差。5.3 签核前的最终模式核查走到签核之前我的习惯是把所有模式的分析视图全部列出来逐一核对SDC版本、库文件版本、SPEF版本做一次彻底的三对照。很多项目在最后阶段被拒都是因为某个模式的SPEF过期或者某个corner的约束文件版本混乱。对照表可以用版本控制系统的提交记录来辅助检查。SDC文件每次有改动都会在提交记录里留下痕迹对照一下修改时间和CTS执行时间能迅速发现是否存在CTS用了旧约束的情况。6. 写在后端茶桌边的话做到今天我对CTS和模式切换这件事最大的体会是工具本身只是执行的机器真正的核心在于工程师对约束的理解深度。你对Func模式SDC里每一条约束的理解决定了你能否在CTS之前就预判到可能出现的问题。再分享一个小技巧作为收尾——每次执行CTS之前我都习惯在Innovus里把整个设计的状态做一次snapshot保存如使用saveDesign或checkpoint并将当前的view和SDC信息记录到一个文本文件里。这样万一CTS跑出异常结果需要回溯可以快速对比到底是约束变了还是CTS本身出了问题而不是两眼一抹黑地从零开始排查。CTS和SDC模式切换这套东西看起来技术门槛高实际上只要你理清了为什么CTS必须绑定Func模式切换的本质是什么这两个核心问题后续所有的操作细节就都顺理成章了。希望这篇分享对正在做Innovus数字后端、或者在准备数字后端相关岗位面试的朋友有帮助也欢迎在实际项目中遇到有意思案例的朋友一起交流探讨。
