1. 时钟约束里绕不开的那道坎logically exclusive与physically exclusive做数字后端或者静态时序分析的朋友迟早会在SDC约束里撞上set_clock_groups这条命令。而一旦用到它就必然要面对两个选项-logically_exclusive和-physically_exclusive。我见过太多项目在这两个选项上翻车——要么约束写得太松该报的时序路径没报流片回来发现功能挂了要么约束写得太紧工具拼命去修一些根本不存在的路径白白浪费几个星期的迭代时间。这篇文章就是想把这两个概念彻底讲透。不管你是刚接触SDC约束的新手还是已经写过几十个模块约束的老手我都建议你花点时间把这块逻辑重新捋一遍。因为在实际项目里时钟mux的约束处理、多时钟域的交互分析、以及CTS阶段的时钟树综合策略全都跟这两个概念直接挂钩。搞不清楚它们你的时序报告就是一本糊涂账。先说清楚这篇文章能给你什么我会从基本概念入手用生活化的类比帮你建立直觉然后深入到SDC命令的具体写法把set_clock_groups的参数选择逻辑拆开揉碎接着用实际项目中的时钟mux场景演示完整的约束编写流程最后整理一份常见问题速查表把我在多个项目里踩过的坑和排查方法都列出来。适合所有需要写SDC约束、做时序分析、或者负责时钟树综合的工程师参考。2. 先把概念掰清楚什么是logically exclusive什么是physically exclusive2.1 从一条真实的时序路径说起假设你的设计里有一个时钟选择器clock mux两个输入时钟分别是CLK_A和CLK_B通过一个选择信号SEL来决定输出CLK_OUT到底跟哪个时钟走。在正常工作模式下SEL要么选A要么选B不可能同时选两个。这意味着CLK_A和CLK_B在逻辑上是互斥的——同一时刻只有一个时钟能到达后续的触发器。这就是logically exclusive的核心含义两个时钟在逻辑功能上不会同时存在。它们可能共享同一段时钟树可能通过mux切换但在任何给定的工作模式下只有一个时钟是活跃的。那physically exclusive又是什么它指的是两个时钟在物理上根本不可能同时出现在同一个时钟网络上。最典型的例子是芯片上的两个完全独立的时钟源比如一个来自晶振的参考时钟和一个来自PLL的输出时钟它们各自驱动不同的时钟树分支物理上没有任何路径能让它们同时到达同一个节点。2.2 用生活类比建立直觉你可以把时钟信号想象成水流。logically exclusive就像是一个三通阀门——你可以让热水流过来也可以让冷水流过来但阀门的设计决定了同一时间只能过一路水。虽然冷热水管都接到了阀门上但最终流向你家水龙头的水要么是热的要么是冷的。physically exclusive则像是两栋完全独立的房子各自有各自的水管系统。你家的水管和邻居家的水管在物理上就没有连通的可能不存在“同时流到同一个水龙头”这种情况。这个类比的关键在于logically exclusive的时钟共享了下游的物理资源时钟树、触发器只是逻辑上不会同时活跃而physically exclusive的时钟连物理资源都不共享。2.3 为什么这个区分如此重要时序分析工具比如PrimeTime、Tempus在默认情况下会检查所有时钟域之间的时序路径。如果你有两个时钟CLK_A和CLK_B工具会去检查从CLK_A驱动的触发器到CLK_B驱动的触发器之间的建立时间和保持时间。但如果这两个时钟是logically exclusive的这些跨时钟域的路径实际上永远不会被激活——因为同一时刻只有一个时钟在工作。工具去检查这些路径要么报出大量虚假的违例要么让你误以为设计有问题。更糟糕的是如果你不告诉工具这两个时钟是互斥的CTS阶段工具会试图去平衡这两个时钟的延迟把本来不需要对齐的时钟树硬生生拉到一起结果就是面积和功耗的浪费甚至可能引入真正的时序问题。所以set_clock_groups这条命令的本质就是告诉时序分析工具这些时钟之间的路径不用检查因为它们不可能同时活跃。3. set_clock_groups的参数选择-logically_exclusive还是-physically_exclusive3.1 命令的基本语法先看set_clock_groups的标准写法set_clock_groups -logically_exclusive \ -group {CLK_A} \ -group {CLK_B}或者set_clock_groups -physically_exclusive \ -group {CLK_A} \ -group {CLK_B}两种写法的结构完全一样区别只在于选项。工具收到这条约束后会把不同group之间的时钟路径全部设为false path不再进行时序检查。3.2 选择逻辑的核心判断标准那到底什么时候用-logically_exclusive什么时候用-physically_exclusive我的判断标准很简单看这两个时钟是否共享下游的物理资源。如果两个时钟通过mux切换后驱动的是同一组触发器、同一段时钟树那就是logically exclusive。因为它们在物理上是可以同时到达同一个节点的只是逻辑上不会所以叫“逻辑互斥”。如果两个时钟从源头上就是独立的各自驱动完全不同的时钟树分支物理上没有任何交汇点那就是physically exclusive。3.3 一个容易混淆的边界情况实际项目中有一种情况特别容易搞混两个时钟来自同一个PLL的不同输出端口分别驱动不同的模块。它们算physically exclusive吗答案是看情况。如果这两个时钟输出在物理上完全独立各自有自己的时钟树那可以算physically exclusive。但如果它们在某个层级汇合了比如都接到了同一个时钟mux的输入端那就变成了logically exclusive。我的一般原则是只要两个时钟有可能在物理上到达同一个节点就用logically_exclusive只有确认物理上完全隔离才用physically_exclusive。注意用错选项的后果不一样。把logically exclusive误判为physically exclusive工具会认为这两个时钟完全无关可能漏掉一些本该检查的路径。反过来把physically exclusive误判为logically exclusive工具会认为它们共享物理资源可能在CTS阶段做出不必要的平衡浪费面积和功耗。3.4 两种约束对CTS的影响差异这个差异很多人没有意识到但它直接影响你的时钟树综合结果。当你用-logically_exclusive时CTS工具知道这两个时钟虽然逻辑互斥但共享下游的时钟树。所以它会去优化共享部分的时钟树确保无论哪个时钟活跃时钟树的质量都能满足要求。这意味着共享路径上的buffer会按照最严格的那个时钟来设计。当你用-physically_exclusive时CTS工具知道这两个时钟完全独立各自优化各自的时钟树互不干扰。这种情况下每个时钟树可以按照自己的需求来设计不需要考虑另一个时钟的影响。这个差异在先进工艺节点下尤其明显。我做过一个项目一开始把两个独立PLL输出的时钟标成了logically exclusive结果CTS工具在共享路径上插了一堆buffer去平衡两个时钟的延迟面积比预期多了15%。后来改成physically exclusive面积立刻降下来了。4. 时钟mux场景下的完整约束实践4.1 典型时钟mux结构分析先看一个最常见的时钟mux场景。设计里有一个2选1的时钟mux输入是CLK_A和CLK_B选择信号是SEL输出是CLK_OUT。CLK_OUT驱动后续的一大片触发器。# 时钟定义 create_clock -name CLK_A -period 10 [get_ports clk_a] create_clock -name CLK_B -period 8 [get_ports clk_b] # 时钟mux的输出 create_clock -name CLK_OUT -period 10 [get_pins mux_inst/Z]这里有个关键点CLK_OUT是通过mux输出的它的周期应该怎么定如果SEL选ACLK_OUT就跟CLK_A同周期如果选B就跟CLK_B同周期。所以CLK_OUT的周期应该取两个输入时钟中最严格的那个也就是最小的周期这样才能保证时序检查不会漏掉。4.2 约束编写步骤第一步定义所有输入时钟。注意这里不需要在mux输出端再create_clock因为mux输出的时钟是从输入端传播过来的。create_clock -name CLK_A -period 10 [get_ports clk_a] create_clock -name CLK_B -period 8 [get_ports clk_b]第二步设置时钟组约束。因为CLK_A和CLK_B通过mux切换逻辑上互斥所以用-logically_exclusive。set_clock_groups -logically_exclusive \ -group {CLK_A} \ -group {CLK_B}第三步处理mux选择信号的时序约束。SEL信号本身也需要满足时序要求它必须在时钟切换之前稳定下来。set_input_delay -clock CLK_A -max 2 [get_ports sel] set_input_delay -clock CLK_B -max 2 [get_ports sel]第四步检查约束是否生效。用report_clock_groups命令确认。report_clock_groups4.3 一个容易忽略的细节mux的glitch问题时钟mux在切换的瞬间可能会产生glitch这个glitch如果被后续的触发器捕获可能导致功能错误。所以在约束里我们通常还需要设置mux选择信号的false path或者multicycle path确保切换过程不会影响功能。# 如果SEL信号在时钟切换期间不稳定需要设置false path set_false_path -from [get_ports sel] -to [get_pins mux_inst/Z]但这条约束要慎用。如果SEL信号确实需要满足时序要求比如在切换前必须稳定几个周期那就不应该设false path而应该设multicycle path。# SEL信号需要在切换前稳定2个周期 set_multicycle_path -setup 2 -from [get_ports sel] -to [get_pins mux_inst/Z]4.4 多级mux的级联处理实际项目中经常遇到多级mux级联的情况。比如第一级mux选CLK_A或CLK_B第二级mux选第一级的输出或CLK_C。这种情况下时钟组约束需要覆盖所有可能的组合。set_clock_groups -logically_exclusive \ -group {CLK_A} \ -group {CLK_B} \ -group {CLK_C}这样写的意思是CLK_A、CLK_B、CLK_C两两之间都是逻辑互斥的。但实际上一级mux的输出和CLK_C之间才是互斥的CLK_A和CLK_B之间也是互斥的。用一条命令覆盖所有组合是最安全的做法虽然可能有些组合实际上并不互斥但多约束总比少约束安全。提示如果时钟数量很多建议用-group把所有互斥的时钟列在一起而不是写多条set_clock_groups。多条命令之间是“与”的关系容易产生冲突。5. 常见问题与排查技巧实录5.1 约束写了但工具不认排查思路这是最常见的问题。你明明写了set_clock_groups但时序报告里还是报出了跨时钟域的路径。排查步骤第一确认时钟名称是否正确。用get_clocks命令检查时钟是否真的存在。get_clocks CLK_A get_clocks CLK_B如果返回空说明时钟名称写错了或者时钟根本没有被创建。第二确认约束是否被正确读取。用report_clock_groups查看当前生效的时钟组约束。report_clock_groups第三检查是否有其他约束覆盖了时钟组约束。比如某条set_false_path或者set_max_delay可能覆盖了set_clock_groups的效果。第四确认约束的加载顺序。set_clock_groups必须在所有时钟定义之后才能生效。如果时钟还没创建就写了时钟组约束工具会忽略它。5.2 常见问题速查表问题现象可能原因排查方法解决方案跨时钟域路径仍然被检查时钟名称错误get_clocks确认修正时钟名称约束不生效加载顺序错误检查SDC文件顺序确保时钟定义在前CTS面积过大误用logically_exclusive检查时钟物理关系改用physically_exclusive时序违例过多缺少时钟组约束report_clock_groups补充set_clock_groupsmux输出时钟周期错误未取最严格周期检查create_clock取最小周期切换glitch导致功能错误缺少SEL约束检查SEL时序设置multicycle path5.3 独家避坑技巧第一个技巧在项目初期就建立时钟架构文档。把所有时钟源、mux结构、时钟域交互关系画成一张图标注清楚哪些是logically exclusive哪些是physically exclusive。这张图在写约束的时候就是你的参考手册在排查问题的时候就是你的地图。第二个技巧用脚本自动生成时钟组约束。如果设计里有几十个时钟手工写set_clock_groups很容易出错。写一个Tcl脚本从时钟架构文档里读取互斥关系自动生成约束命令。这样既减少了人为错误也方便后续维护。第三个技巧在CTS之前做一次约束审查。把所有的set_clock_groups列出来逐条确认选项是否正确。我见过一个项目因为把physically exclusive误写成logically exclusiveCTS工具在共享路径上插了200多个buffer面积直接超标。后来改过来面积降了12%。第四个技巧用report_timing -group分组查看时序报告。把不同时钟组的时序报告分开看可以快速定位哪些时钟域之间的路径被检查了哪些被忽略了。如果发现某个时钟组的报告是空的说明约束可能写得太松了。5.4 一个真实的排查案例去年做一个28nm的项目有个模块的时序一直修不干净。工具报出大量从CLK_A到CLK_B的建立时间违例但这两个时钟明明是互斥的。检查SDC文件发现set_clock_groups写的是set_clock_groups -logically_exclusive \ -group {CLK_A} \ -group {CLK_B}看起来没问题。但用report_clock_groups一查发现CLK_A和CLK_B根本不在同一个时钟组里——因为CLK_B在另一个SDC文件里被重新定义了一次名字变成了CLK_B_div。两个SDC文件加载顺序不同导致时钟组约束引用了错误的时钟名。解决方法很简单统一时钟命名确保所有SDC文件引用的是同一个时钟对象。但这个问题的排查花了整整两天因为工具不会报错只是默默地忽略了约束。注意SDC文件的加载顺序和时钟命名一致性是时钟组约束失效的两大隐形杀手。建议在项目初期就制定统一的命名规范并用脚本检查所有SDC文件的时钟定义是否一致。6. 从约束到实现CTS阶段的时钟处理策略6.1 CTS工具如何处理时钟组约束CTS工具在读取SDC约束后会根据set_clock_groups的选项来决定时钟树的综合策略。对于-logically_exclusive的时钟组CTS工具知道这些时钟共享下游的时钟树。所以它会识别共享路径和独立路径在共享路径上按照最严格的时钟要求来优化在独立路径上分别优化各自的时钟树确保切换点mux输出的时钟质量满足所有输入时钟的要求对于-physically_exclusive的时钟组CTS工具知道这些时钟完全独立。所以它会把每个时钟当作独立的时钟树来处理不需要考虑时钟之间的平衡各自优化各自的延迟、skew和transition6.2 时钟树综合的关键参数设置在CTS阶段有几个参数跟时钟组约束直接相关# 设置时钟树的target skew set_clock_tree_options -target_skew 0.1 -clock CLK_A set_clock_tree_options -target_skew 0.1 -clock CLK_B # 设置时钟树的target latency set_clock_tree_options -target_latency 1.5 -clock CLK_A set_clock_tree_options -target_latency 1.5 -clock CLK_B # 设置时钟树的buffer列表 set_clock_tree_options -buffer_list {BUF_X4 BUF_X8 BUF_X16}对于logically exclusive的时钟共享路径上的target skew应该取两个时钟中最严格的值。对于physically exclusive的时钟各自设置各自的参数即可。6.3 时钟树平衡的取舍这里有一个经典的取舍问题logically exclusive的时钟共享路径上的时钟树要不要做平衡我的经验是看共享路径的长度和时钟频率差异。如果共享路径很短比如只有几级buffer而且两个时钟的频率差异不大那做平衡的成本很低直接平衡就好。如果共享路径很长或者两个时钟的频率差异很大比如一个100MHz一个800MHz那强行平衡可能导致高频时钟的时钟树被低频时钟拖累反而影响整体性能。这种情况下可以考虑在共享路径上做折中或者把mux往下游移减少共享路径的长度。6.4 一个实用的CTS检查清单在CTS完成后用以下清单检查时钟树质量所有时钟的skew是否满足约束要求共享路径上的时钟树是否按照最严格时钟优化mux输出端的transition是否满足要求时钟树的latency是否在预期范围内是否有意外的时钟树交叉或短路功耗是否在预算范围内7. 写在最后一些个人体会做了这么多年时序约束我最大的体会是set_clock_groups这条命令看起来简单但用对用好真的不容易。它不像create_clock那样直观也不像set_input_delay那样有明确的公式可循。它更多依赖你对设计时钟架构的理解以及对工具行为的预判。我个人的习惯是每做一个新项目第一件事就是把时钟架构图画出来标注清楚每个时钟的来源、去向、以及跟其他时钟的关系。这张图不仅帮我写约束还帮我在review别人的约束时快速发现问题。另外不要怕在约束上花时间。我见过太多项目为了赶进度约束写得马马虎虎结果在时序修复阶段花了十倍的时间去补窟窿。约束写对了后面的CTS和时序修复都会顺畅很多。最后分享一个小技巧如果你不确定某个时钟组应该用logically还是physically先按logically写跑一遍CTS看看面积和功耗是否合理。如果发现工具在共享路径上做了大量不必要的平衡再改成physically。反过来如果先按physically写发现有些路径该检查的没检查再改回logically。这个试错过程虽然多花一点时间但比拍脑袋决定要靠谱得多。