1. 从一个真实的时序违例说起如果你做过稍微复杂一点的数字后端或者FPGA时序收敛大概率遇到过这种场景综合工具报告里突然冒出一堆跨时钟域的违例路径的起点和终点明明来自同一个物理时钟源工具却把它们当成异步时钟处理报出巨大的skew或者反过来两个本该异步的时钟被工具当成同步关系拼命去修setup/hold结果怎么修都修不干净。这类问题的根源十有八九出在时钟约束里对logically exclusive和physically exclusive这两个概念的理解和写法上。这两个词在SDCSynopsys Design Constraints里对应的核心命令就是set_clock_groups配合-logically_exclusive和-physically_exclusive两个选项。别看命令简单真正把它用对、用准需要对时钟树结构、时钟选择逻辑clock mux、以及工具如何推导时钟关系有清晰的认识。我见过太多项目因为这两个选项用反了导致时序分析结果完全失真要么过度约束浪费面积和功耗要么欠约束放过真正的违例。这篇内容面向的是已经接触过SDC约束、做过时序收敛的工程师也适合正在从RTL转向约束设计的朋友。我会从这两个概念的本质区别讲起结合clock mux的实际电路结构把set_clock_groups的写法、常见误用、以及和set_false_path、create_generated_clock的配合关系讲透。核心关键词包括logically exclusive、physically exclusive、时钟约束、set_clock_groups、SDC以及时钟mux约束。读完之后你应该能独立判断一个时钟关系到底该用哪种约束并且知道工具在背后是怎么处理的。2. logically exclusive与physically exclusive的本质区别2.1 先搞清楚exclusive到底在说什么exclusive这个词在时钟约束语境下说的是两个时钟不会同时存在或者不会同时有效。注意这里的关键是同时。时序分析工具在默认情况下会把设计里所有时钟两两之间都建立分析关系除非你明确告诉它某些时钟之间不需要分析。set_clock_groups就是干这个的——它把一组时钟声明为互斥工具就不会去分析跨这些时钟组的路径。那logically和physically的区别在哪简单说physically exclusive两个时钟在物理上就不可能同时到达同一个点。最典型的就是clock mux的两个输入——mux同一时刻只选通一路另一路物理上被切断两个时钟不可能同时驱动下游。logically exclusive两个时钟在物理上可能同时存在但在逻辑功能上被设计成不会同时有效。比如通过某个配置寄存器控制的工作模式切换模式A用时钟A模式B用时钟B硬件上两路时钟都连着但功能上互斥。这个区别直接决定了工具的分析策略。physically exclusive的情况下工具可以更激进地优化因为它知道物理上不存在同时性logically exclusive则需要更谨慎因为物理连接是存在的只是功能上不共存。2.2 一个clock mux电路把问题讲清楚我们来看一个最经典的例子。假设有一个2选1的时钟mux// 时钟mux的典型RTL结构 module clk_mux ( input wire clk_a, input wire clk_b, input wire sel, output wire clk_out ); assign clk_out sel ? clk_b : clk_a; endmodule在这个结构里clk_a和clk_b通过mux汇聚到clk_out。同一时刻sel要么是0要么是1所以clk_out要么跟随clk_a要么跟随clk_b绝不可能同时是两者。这就是physically exclusive的典型场景——物理上mux只让一路通过。对应的SDC写法create_clock -name clk_a -period 10 [get_ports clk_a] create_clock -name clk_b -period 8 [get_ports clk_b] set_clock_groups -physically_exclusive \ -group {clk_a} \ -group {clk_b}这样工具就知道clk_a和clk_b之间的跨时钟路径不需要分析因为它们物理上不会同时到达mux输出。那什么时候用logically exclusive考虑另一种情况设计里有两个时钟clk_fast和clk_slow它们分别来自不同的PLL但通过一个软件可配置的寄存器来选择当前系统用哪个。硬件上两路时钟都连到了选择逻辑但功能上系统只会工作在其中一个时钟下。这时候两路时钟物理上可能同时存在两个PLL都在跑但逻辑上互斥。这种情况就该用-logically_exclusive。2.3 工具内部是怎么处理这两种约束的理解工具的处理机制能帮你判断约束写得对不对。当时序分析工具比如PrimeTime、Tempus读取到set_clock_groups时它会在时钟关系矩阵里把对应时钟对标记为不分析。但两种exclusive的处理深度不同对于physically exclusive工具在时钟树传播阶段就可以做剪枝。因为物理上不可能同时到达工具在计算到达时间arrival time时不需要考虑另一路时钟的影响时钟树的公共路径common path计算也更简单。这带来的直接好处是工具不会去修那些根本不存在的跨时钟路径省下大量优化资源。对于logically exclusive工具在时钟传播时仍然认为两路时钟都可能存在只是在建立时序分析关系时把它们标记为互斥。也就是说时钟树还是要完整传播只是在做setup/hold检查时跳过这些时钟对。这意味着logically exclusive的约束下工具对时钟树的理解更保守但对功能互斥的路径做了正确的排除。这个差异在实际项目里非常关键。我遇到过有人把本该physically exclusive的clock mux写成了logically exclusive结果工具在时钟树综合CTS阶段仍然把两路时钟都当有效时钟来平衡导致时钟树做得又大又复杂功耗和面积都上去了。反过来把logically exclusive写成physically exclusive工具可能会过度剪枝漏掉一些本该分析的路径。3. set_clock_groups的正确写法与常见误用3.1 命令语法与参数详解set_clock_groups的基本语法是这样的set_clock_groups [-name group_name] \ -physically_exclusive | -logically_exclusive | -asynchronous \ -group {clock_list_1} \ -group {clock_list_2} \ [-group {clock_list_3} ...]三个互斥类型选项的含义选项含义典型场景-physically_exclusive物理上不可能同时存在clock mux、时钟切换电路-logically_exclusive逻辑功能上互斥物理上可能共存模式选择、功能配置切换-asynchronous异步时钟无固定相位关系不同晶振源、跨芯片时钟这里有个容易混淆的点-asynchronous和-logically_exclusive看起来都是不分析但语义不同。asynchronous强调的是时钟之间没有确定的相位/频率关系工具完全不做时序分析logically_exclusive强调的是功能互斥工具知道它们不会同时有效但时钟本身可能是同源或有确定关系的。-group参数可以指定多个组任意两个不同组之间的时钟都被声明为互斥。同一个组内的时钟之间仍然会做分析。这个设计很巧妙——它允许你把内部需要互相分析的时钟放在一组把组间互斥的关系一次性声明。3.2 一个多时钟组的实战写法假设一个设计里有这样的时钟结构一个主时钟clk_main经过分频产生clk_div2和clk_div4另外有一个测试时钟clk_test通过mux接入。clk_main、clk_div2、clk_div4之间需要正常分析同源clk_test和它们物理互斥。create_clock -name clk_main -period 10 [get_ports clk_main] create_generated_clock -name clk_div2 -source [get_ports clk_main] \ -divide_by 2 [get_pins div2_reg/Q] create_generated_clock -name clk_div4 -source [get_ports clk_main] \ -divide_by 4 [get_pins div4_reg/Q] create_clock -name clk_test -period 20 [get_ports clk_test] # 主时钟域内部正常分析测试时钟与主时钟域物理互斥 set_clock_groups -physically_exclusive \ -group {clk_main clk_div2 clk_div4} \ -group {clk_test}注意这里把clk_main、clk_div2、clk_div4放在同一个group里它们之间的路径仍然会被分析。只有跨到clk_test的路径才被排除。这种写法比逐个写set_false_path清晰得多也不容易漏。3.3 最常见的三个误用误用一把physically exclusive写成asynchronous。这是最普遍的。很多人觉得反正都是不分析用哪个都一样。但实际上asynchronous会让工具完全放弃这两个时钟之间的任何关系推导包括时钟树的公共路径优化。而physically exclusive保留了工具对物理结构的理解能做出更优的时钟树。在clock mux场景下用asynchronous是明显的过度约束。误用二group划分错误导致漏约束。我见过一个项目工程师把clk_a和clk_b分别放在两个group里声明physically exclusive但忘了clk_a的分频时钟clk_a_div也应该在clk_a这一组。结果clk_a_div和clk_b之间的路径没有被排除工具报了一堆假违例。正确的做法是把同源的所有时钟都归到同一组。误用三和set_false_path混用产生冲突。有些约束文件里既有set_clock_groups又有针对同一对时钟的set_false_path。这两者语义上有重叠工具处理时可能产生优先级问题。一般来说set_clock_groups的优先级更高但混用会让约束难以维护。建议统一用set_clock_groups来管理时钟组关系set_false_path只用于具体的路径例外。提示写完set_clock_groups后一定要用report_clock_groups或者等价的报告命令检查一遍确认每个时钟都被正确归类没有遗漏也没有多余。4. 时钟mux约束的完整设计流程4.1 从RTL结构识别约束需求约束不是拍脑袋写的得从RTL结构推导出来。拿到一个设计先找所有的时钟选择逻辑。常见的时钟mux结构有三种第一种是纯组合mux就是前面例子里的assign clk_out sel ? clk_b : clk_a。这种最直接两路输入物理互斥。第二种是带glitch-free保护的时钟切换电路通常用两个寄存器在时钟的下降沿采样选择信号避免切换时产生毛刺。这种结构下两路时钟在切换瞬间可能有短暂的共存但稳态下仍然是互斥的。约束上一般还是按physically exclusive处理但要确认切换逻辑本身有时序保证。第三种是级联mux多个mux串起来形成时钟树。这种要逐级分析把最终到达同一节点的所有时钟源都找出来理清它们之间的互斥关系。识别完之后画一张时钟关系图哪些时钟同源需要分析哪些互斥需要排除哪些是异步的。这张图是写约束的依据。4.2 约束文件的组织与顺序SDC约束是有顺序要求的。create_clock和create_generated_clock必须在前set_clock_groups在后因为后者引用的是前者的时钟名。一个推荐的顺序# 1. 创建所有主时钟 create_clock -name clk_a -period 10 [get_ports clk_a] create_clock -name clk_b -period 8 [get_ports clk_b] # 2. 创建生成时钟 create_generated_clock -name clk_a_div2 -source [get_ports clk_a] \ -divide_by 2 [get_pins div_reg/Q] # 3. 声明时钟组关系 set_clock_groups -physically_exclusive \ -group {clk_a clk_a_div2} \ -group {clk_b} # 4. 其他时序例外 set_false_path -from [get_ports rst_n] -to [all_registers]这个顺序不是随便定的。如果set_clock_groups写在create_generated_clock之前工具会报找不到时钟名的错误。另外如果一个时钟既在set_clock_groups里出现又被set_false_path引用要确保两者的意图一致不要互相矛盾。4.3 验证约束是否生效的方法写完约束不能就完事了得验证。我常用的验证手段有这么几个第一用report_clock_groups看工具实际识别到的时钟组关系。这个报告会列出每个时钟属于哪个组以及组间的互斥类型。如果发现某个时钟没出现在任何组里或者组关系和你预期的不一样说明约束有问题。第二用report_timing检查具体的跨时钟路径。挑几条你预期应该被排除的路径看工具是否真的不分析了。如果还在报违例说明约束没生效。第三对比约束前后的时序报告。加上set_clock_groups之后跨时钟路径的违例应该消失同时钟域内的路径分析不受影响。如果同源时钟之间的路径也消失了说明group划分错了把不该互斥的时钟放到不同组了。第四在时钟树综合CTS阶段观察时钟树的结构。physically exclusive的约束下工具应该只对实际有效的时钟路径做平衡不会去平衡那些物理上不可能同时存在的分支。如果发现时钟树里出现了不该有的平衡分支回头检查约束类型是不是写错了。5. 与set_false_path、create_generated_clock的配合5.1 为什么set_clock_groups优于set_false_path很多人习惯用set_false_path来切断跨时钟路径比如set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b] set_false_path -from [get_clocks clk_b] -to [get_clocks clk_a]这样写能工作但有几个问题。首先它是双向的你得写两条容易漏。其次它不表达时钟之间的互斥语义工具只知道这两条路径不分析不知道这两个时钟物理互斥。在做时钟树优化时工具不会利用这个信息。第三当设计里有多个时钟时set_false_path的组合会爆炸维护成本高。set_clock_groups一次性声明组间互斥语义清晰工具能利用互斥信息做更优的优化。所以在时钟组关系这种全局性约束上优先用set_clock_groups。5.2 generated clock在exclusive场景下的处理生成时钟generated clock的处理要特别小心。假设clk_a经过分频产生clk_a_divclk_b经过分频产生clk_b_div而clk_a和clk_b物理互斥。那么clk_a_div和clk_b_div之间也是物理互斥的应该一起放进对应的groupset_clock_groups -physically_exclusive \ -group {clk_a clk_a_div} \ -group {clk_b clk_b_div}如果只写了clk_a和clk_b互斥忘了生成时钟工具仍然会分析clk_a_div和clk_b_div之间的路径产生假违例。这是实际项目里非常高频的坑。还有一种情况生成时钟的源时钟本身在互斥组里。比如clk_a_div的源是clk_a而clk_a和clk_b互斥。这时候clk_a_div和clk_b之间也应该互斥。工具通常能通过源时钟关系推导出来但为了保险显式写进group更稳妥。5.3 一个容易忽略的细节时钟的传播与互斥的交互这里有个深层次的机制值得说清楚。当时钟通过mux传播时工具需要知道mux的选择信号。如果选择信号是静态配置的比如上电时固定的工具可以确定只有一路时钟有效这时候physically exclusive的约束和实际情况完全吻合。但如果选择信号是动态切换的工具在分析时会假设最坏情况两路时钟都可能有效。在动态切换的场景下physically exclusive的约束仍然成立因为同一时刻只有一路有效。但工具在做时钟树平衡时可能需要考虑切换瞬间的时序。这时候约束的写法要结合具体的切换协议来定。如果切换是glitch-free的且切换过程中有时钟停振保护那physically exclusive没问题。如果切换是异步的、没有保护可能需要额外的约束来覆盖切换窗口。这个细节在大多数项目里不会成为问题但在高速设计或者对时钟切换有严格要求的场景下必须考虑清楚。6. 实操中踩过的坑与排查思路6.1 假违例排查从报告反推约束问题有一次我接手一个项目时序报告里有一堆跨时钟违例路径起点是clk_a域终点是clk_b域但这两个时钟明明来自同一个mux。检查约束文件发现写了set_clock_groups -asynchronous但group划分有问题——clk_a的分频时钟clk_a_div没有被包含进去。排查过程是这样的先用report_clock_groups看工具识别的组关系发现clk_a_div不在任何组里。然后用report_timing -from clk_a_div -to clk_b确认确实有路径被分析。修复方法就是把clk_a_div加进clk_a那一组。改完之后违例消失。这个坑的教训是生成时钟一定要跟着源时钟一起进组。每次写完set_clock_groups都要检查一遍所有生成时钟是否都被覆盖。6.2 过度约束导致面积膨胀的案例另一个项目工程师把本该physically exclusive的clock mux写成了-asynchronous。结果工具在CTS阶段把两路时钟都当成有效时钟来平衡时钟树里出现了大量冗余的buffer面积比预期大了15%功耗也上去了。排查方法对比CTS前后的时钟树报告看时钟树的分支结构。如果发现物理上不可能同时存在的分支都被平衡了说明约束类型用错了。改成-physically_exclusive之后工具正确剪枝面积恢复正常。这个案例说明exclusive类型的选择不只是分析不分析的问题还直接影响物理实现的质量。physically exclusive给工具的信息更多优化空间更大。6.3 约束顺序错误导致的静默失败最隐蔽的坑是约束顺序错误。有一次约束文件里set_clock_groups写在了create_generated_clock之前工具没有报错但生成时钟没有被正确归类。因为工具读取set_clock_groups时生成时钟还不存在所以那个时钟名被忽略了。这种静默失败最危险因为工具不报错你以为约束生效了实际上没有。排查方法是写完约束后用report_clock_groups确认每个时钟都在预期的组里。如果某个时钟消失了检查它的创建语句是不是在set_clock_groups之后。注意不同工具对约束顺序的容忍度不同。有些工具会自动重排有些不会。为了可移植性始终按创建时钟→创建生成时钟→声明时钟组→其他例外的顺序写。6.4 多时钟域交叉时的group划分策略当一个设计里有多个时钟域且它们之间的互斥关系不是简单的两两互斥时group划分需要仔细设计。比如有clk_a、clk_b、clk_c三个时钟clk_a和clk_b物理互斥clk_b和clk_c物理互斥但clk_a和clk_c可能同时存在。这种情况下不能简单地把三个时钟分成三组声明两两互斥因为那会错误地排除clk_a和clk_c之间的分析。正确的做法是分两条set_clock_groupsset_clock_groups -physically_exclusive -group {clk_a} -group {clk_b} set_clock_groups -physically_exclusive -group {clk_b} -group {clk_c}这样clk_a和clk_c之间的路径仍然会被分析符合实际。这个细节在复杂SoC设计里很常见group划分错了会导致漏约束或过度约束。7. 写在最后的一点个人体会关于logically exclusive和physically exclusive我最大的体会是约束的本质是把设计意图翻译给工具听。工具不知道你的mux是干什么的不知道你的模式切换逻辑它只能根据你写的约束来推导时钟关系。所以约束写得准不准取决于你对设计意图的理解够不够深。我的习惯是每做一个新项目先把时钟结构图画出来标清楚每个时钟的来源、频率、以及和其他时钟的关系。然后对照这张图写约束写完再用报告验证。这个流程看起来多花时间但能避免后期大量的调试。另外SDC约束不是写完就一劳永逸的。设计改了时钟结构变了约束也要跟着更新。我见过太多项目因为约束没跟上设计变更导致时序分析结果和实际不符。把约束文件当成设计的一部分来维护而不是一次性的脚本这个观念很重要。最后分享一个小技巧在约束文件里给每个set_clock_groups加上-name参数起一个有意义的名字比如-name mux_ab_exclusive。这样在报告里能一眼看出这条约束是干什么的调试的时候省很多事。
SDC时钟约束：logically exclusive与physically exclusive的本质区别与实战
1. 从一个真实的时序违例说起如果你做过稍微复杂一点的数字后端或者FPGA时序收敛大概率遇到过这种场景综合工具报告里突然冒出一堆跨时钟域的违例路径的起点和终点明明来自同一个物理时钟源工具却把它们当成异步时钟处理报出巨大的skew或者反过来两个本该异步的时钟被工具当成同步关系拼命去修setup/hold结果怎么修都修不干净。这类问题的根源十有八九出在时钟约束里对logically exclusive和physically exclusive这两个概念的理解和写法上。这两个词在SDCSynopsys Design Constraints里对应的核心命令就是set_clock_groups配合-logically_exclusive和-physically_exclusive两个选项。别看命令简单真正把它用对、用准需要对时钟树结构、时钟选择逻辑clock mux、以及工具如何推导时钟关系有清晰的认识。我见过太多项目因为这两个选项用反了导致时序分析结果完全失真要么过度约束浪费面积和功耗要么欠约束放过真正的违例。这篇内容面向的是已经接触过SDC约束、做过时序收敛的工程师也适合正在从RTL转向约束设计的朋友。我会从这两个概念的本质区别讲起结合clock mux的实际电路结构把set_clock_groups的写法、常见误用、以及和set_false_path、create_generated_clock的配合关系讲透。核心关键词包括logically exclusive、physically exclusive、时钟约束、set_clock_groups、SDC以及时钟mux约束。读完之后你应该能独立判断一个时钟关系到底该用哪种约束并且知道工具在背后是怎么处理的。2. logically exclusive与physically exclusive的本质区别2.1 先搞清楚exclusive到底在说什么exclusive这个词在时钟约束语境下说的是两个时钟不会同时存在或者不会同时有效。注意这里的关键是同时。时序分析工具在默认情况下会把设计里所有时钟两两之间都建立分析关系除非你明确告诉它某些时钟之间不需要分析。set_clock_groups就是干这个的——它把一组时钟声明为互斥工具就不会去分析跨这些时钟组的路径。那logically和physically的区别在哪简单说physically exclusive两个时钟在物理上就不可能同时到达同一个点。最典型的就是clock mux的两个输入——mux同一时刻只选通一路另一路物理上被切断两个时钟不可能同时驱动下游。logically exclusive两个时钟在物理上可能同时存在但在逻辑功能上被设计成不会同时有效。比如通过某个配置寄存器控制的工作模式切换模式A用时钟A模式B用时钟B硬件上两路时钟都连着但功能上互斥。这个区别直接决定了工具的分析策略。physically exclusive的情况下工具可以更激进地优化因为它知道物理上不存在同时性logically exclusive则需要更谨慎因为物理连接是存在的只是功能上不共存。2.2 一个clock mux电路把问题讲清楚我们来看一个最经典的例子。假设有一个2选1的时钟mux// 时钟mux的典型RTL结构 module clk_mux ( input wire clk_a, input wire clk_b, input wire sel, output wire clk_out ); assign clk_out sel ? clk_b : clk_a; endmodule在这个结构里clk_a和clk_b通过mux汇聚到clk_out。同一时刻sel要么是0要么是1所以clk_out要么跟随clk_a要么跟随clk_b绝不可能同时是两者。这就是physically exclusive的典型场景——物理上mux只让一路通过。对应的SDC写法create_clock -name clk_a -period 10 [get_ports clk_a] create_clock -name clk_b -period 8 [get_ports clk_b] set_clock_groups -physically_exclusive \ -group {clk_a} \ -group {clk_b}这样工具就知道clk_a和clk_b之间的跨时钟路径不需要分析因为它们物理上不会同时到达mux输出。那什么时候用logically exclusive考虑另一种情况设计里有两个时钟clk_fast和clk_slow它们分别来自不同的PLL但通过一个软件可配置的寄存器来选择当前系统用哪个。硬件上两路时钟都连到了选择逻辑但功能上系统只会工作在其中一个时钟下。这时候两路时钟物理上可能同时存在两个PLL都在跑但逻辑上互斥。这种情况就该用-logically_exclusive。2.3 工具内部是怎么处理这两种约束的理解工具的处理机制能帮你判断约束写得对不对。当时序分析工具比如PrimeTime、Tempus读取到set_clock_groups时它会在时钟关系矩阵里把对应时钟对标记为不分析。但两种exclusive的处理深度不同对于physically exclusive工具在时钟树传播阶段就可以做剪枝。因为物理上不可能同时到达工具在计算到达时间arrival time时不需要考虑另一路时钟的影响时钟树的公共路径common path计算也更简单。这带来的直接好处是工具不会去修那些根本不存在的跨时钟路径省下大量优化资源。对于logically exclusive工具在时钟传播时仍然认为两路时钟都可能存在只是在建立时序分析关系时把它们标记为互斥。也就是说时钟树还是要完整传播只是在做setup/hold检查时跳过这些时钟对。这意味着logically exclusive的约束下工具对时钟树的理解更保守但对功能互斥的路径做了正确的排除。这个差异在实际项目里非常关键。我遇到过有人把本该physically exclusive的clock mux写成了logically exclusive结果工具在时钟树综合CTS阶段仍然把两路时钟都当有效时钟来平衡导致时钟树做得又大又复杂功耗和面积都上去了。反过来把logically exclusive写成physically exclusive工具可能会过度剪枝漏掉一些本该分析的路径。3. set_clock_groups的正确写法与常见误用3.1 命令语法与参数详解set_clock_groups的基本语法是这样的set_clock_groups [-name group_name] \ -physically_exclusive | -logically_exclusive | -asynchronous \ -group {clock_list_1} \ -group {clock_list_2} \ [-group {clock_list_3} ...]三个互斥类型选项的含义选项含义典型场景-physically_exclusive物理上不可能同时存在clock mux、时钟切换电路-logically_exclusive逻辑功能上互斥物理上可能共存模式选择、功能配置切换-asynchronous异步时钟无固定相位关系不同晶振源、跨芯片时钟这里有个容易混淆的点-asynchronous和-logically_exclusive看起来都是不分析但语义不同。asynchronous强调的是时钟之间没有确定的相位/频率关系工具完全不做时序分析logically_exclusive强调的是功能互斥工具知道它们不会同时有效但时钟本身可能是同源或有确定关系的。-group参数可以指定多个组任意两个不同组之间的时钟都被声明为互斥。同一个组内的时钟之间仍然会做分析。这个设计很巧妙——它允许你把内部需要互相分析的时钟放在一组把组间互斥的关系一次性声明。3.2 一个多时钟组的实战写法假设一个设计里有这样的时钟结构一个主时钟clk_main经过分频产生clk_div2和clk_div4另外有一个测试时钟clk_test通过mux接入。clk_main、clk_div2、clk_div4之间需要正常分析同源clk_test和它们物理互斥。create_clock -name clk_main -period 10 [get_ports clk_main] create_generated_clock -name clk_div2 -source [get_ports clk_main] \ -divide_by 2 [get_pins div2_reg/Q] create_generated_clock -name clk_div4 -source [get_ports clk_main] \ -divide_by 4 [get_pins div4_reg/Q] create_clock -name clk_test -period 20 [get_ports clk_test] # 主时钟域内部正常分析测试时钟与主时钟域物理互斥 set_clock_groups -physically_exclusive \ -group {clk_main clk_div2 clk_div4} \ -group {clk_test}注意这里把clk_main、clk_div2、clk_div4放在同一个group里它们之间的路径仍然会被分析。只有跨到clk_test的路径才被排除。这种写法比逐个写set_false_path清晰得多也不容易漏。3.3 最常见的三个误用误用一把physically exclusive写成asynchronous。这是最普遍的。很多人觉得反正都是不分析用哪个都一样。但实际上asynchronous会让工具完全放弃这两个时钟之间的任何关系推导包括时钟树的公共路径优化。而physically exclusive保留了工具对物理结构的理解能做出更优的时钟树。在clock mux场景下用asynchronous是明显的过度约束。误用二group划分错误导致漏约束。我见过一个项目工程师把clk_a和clk_b分别放在两个group里声明physically exclusive但忘了clk_a的分频时钟clk_a_div也应该在clk_a这一组。结果clk_a_div和clk_b之间的路径没有被排除工具报了一堆假违例。正确的做法是把同源的所有时钟都归到同一组。误用三和set_false_path混用产生冲突。有些约束文件里既有set_clock_groups又有针对同一对时钟的set_false_path。这两者语义上有重叠工具处理时可能产生优先级问题。一般来说set_clock_groups的优先级更高但混用会让约束难以维护。建议统一用set_clock_groups来管理时钟组关系set_false_path只用于具体的路径例外。提示写完set_clock_groups后一定要用report_clock_groups或者等价的报告命令检查一遍确认每个时钟都被正确归类没有遗漏也没有多余。4. 时钟mux约束的完整设计流程4.1 从RTL结构识别约束需求约束不是拍脑袋写的得从RTL结构推导出来。拿到一个设计先找所有的时钟选择逻辑。常见的时钟mux结构有三种第一种是纯组合mux就是前面例子里的assign clk_out sel ? clk_b : clk_a。这种最直接两路输入物理互斥。第二种是带glitch-free保护的时钟切换电路通常用两个寄存器在时钟的下降沿采样选择信号避免切换时产生毛刺。这种结构下两路时钟在切换瞬间可能有短暂的共存但稳态下仍然是互斥的。约束上一般还是按physically exclusive处理但要确认切换逻辑本身有时序保证。第三种是级联mux多个mux串起来形成时钟树。这种要逐级分析把最终到达同一节点的所有时钟源都找出来理清它们之间的互斥关系。识别完之后画一张时钟关系图哪些时钟同源需要分析哪些互斥需要排除哪些是异步的。这张图是写约束的依据。4.2 约束文件的组织与顺序SDC约束是有顺序要求的。create_clock和create_generated_clock必须在前set_clock_groups在后因为后者引用的是前者的时钟名。一个推荐的顺序# 1. 创建所有主时钟 create_clock -name clk_a -period 10 [get_ports clk_a] create_clock -name clk_b -period 8 [get_ports clk_b] # 2. 创建生成时钟 create_generated_clock -name clk_a_div2 -source [get_ports clk_a] \ -divide_by 2 [get_pins div_reg/Q] # 3. 声明时钟组关系 set_clock_groups -physically_exclusive \ -group {clk_a clk_a_div2} \ -group {clk_b} # 4. 其他时序例外 set_false_path -from [get_ports rst_n] -to [all_registers]这个顺序不是随便定的。如果set_clock_groups写在create_generated_clock之前工具会报找不到时钟名的错误。另外如果一个时钟既在set_clock_groups里出现又被set_false_path引用要确保两者的意图一致不要互相矛盾。4.3 验证约束是否生效的方法写完约束不能就完事了得验证。我常用的验证手段有这么几个第一用report_clock_groups看工具实际识别到的时钟组关系。这个报告会列出每个时钟属于哪个组以及组间的互斥类型。如果发现某个时钟没出现在任何组里或者组关系和你预期的不一样说明约束有问题。第二用report_timing检查具体的跨时钟路径。挑几条你预期应该被排除的路径看工具是否真的不分析了。如果还在报违例说明约束没生效。第三对比约束前后的时序报告。加上set_clock_groups之后跨时钟路径的违例应该消失同时钟域内的路径分析不受影响。如果同源时钟之间的路径也消失了说明group划分错了把不该互斥的时钟放到不同组了。第四在时钟树综合CTS阶段观察时钟树的结构。physically exclusive的约束下工具应该只对实际有效的时钟路径做平衡不会去平衡那些物理上不可能同时存在的分支。如果发现时钟树里出现了不该有的平衡分支回头检查约束类型是不是写错了。5. 与set_false_path、create_generated_clock的配合5.1 为什么set_clock_groups优于set_false_path很多人习惯用set_false_path来切断跨时钟路径比如set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b] set_false_path -from [get_clocks clk_b] -to [get_clocks clk_a]这样写能工作但有几个问题。首先它是双向的你得写两条容易漏。其次它不表达时钟之间的互斥语义工具只知道这两条路径不分析不知道这两个时钟物理互斥。在做时钟树优化时工具不会利用这个信息。第三当设计里有多个时钟时set_false_path的组合会爆炸维护成本高。set_clock_groups一次性声明组间互斥语义清晰工具能利用互斥信息做更优的优化。所以在时钟组关系这种全局性约束上优先用set_clock_groups。5.2 generated clock在exclusive场景下的处理生成时钟generated clock的处理要特别小心。假设clk_a经过分频产生clk_a_divclk_b经过分频产生clk_b_div而clk_a和clk_b物理互斥。那么clk_a_div和clk_b_div之间也是物理互斥的应该一起放进对应的groupset_clock_groups -physically_exclusive \ -group {clk_a clk_a_div} \ -group {clk_b clk_b_div}如果只写了clk_a和clk_b互斥忘了生成时钟工具仍然会分析clk_a_div和clk_b_div之间的路径产生假违例。这是实际项目里非常高频的坑。还有一种情况生成时钟的源时钟本身在互斥组里。比如clk_a_div的源是clk_a而clk_a和clk_b互斥。这时候clk_a_div和clk_b之间也应该互斥。工具通常能通过源时钟关系推导出来但为了保险显式写进group更稳妥。5.3 一个容易忽略的细节时钟的传播与互斥的交互这里有个深层次的机制值得说清楚。当时钟通过mux传播时工具需要知道mux的选择信号。如果选择信号是静态配置的比如上电时固定的工具可以确定只有一路时钟有效这时候physically exclusive的约束和实际情况完全吻合。但如果选择信号是动态切换的工具在分析时会假设最坏情况两路时钟都可能有效。在动态切换的场景下physically exclusive的约束仍然成立因为同一时刻只有一路有效。但工具在做时钟树平衡时可能需要考虑切换瞬间的时序。这时候约束的写法要结合具体的切换协议来定。如果切换是glitch-free的且切换过程中有时钟停振保护那physically exclusive没问题。如果切换是异步的、没有保护可能需要额外的约束来覆盖切换窗口。这个细节在大多数项目里不会成为问题但在高速设计或者对时钟切换有严格要求的场景下必须考虑清楚。6. 实操中踩过的坑与排查思路6.1 假违例排查从报告反推约束问题有一次我接手一个项目时序报告里有一堆跨时钟违例路径起点是clk_a域终点是clk_b域但这两个时钟明明来自同一个mux。检查约束文件发现写了set_clock_groups -asynchronous但group划分有问题——clk_a的分频时钟clk_a_div没有被包含进去。排查过程是这样的先用report_clock_groups看工具识别的组关系发现clk_a_div不在任何组里。然后用report_timing -from clk_a_div -to clk_b确认确实有路径被分析。修复方法就是把clk_a_div加进clk_a那一组。改完之后违例消失。这个坑的教训是生成时钟一定要跟着源时钟一起进组。每次写完set_clock_groups都要检查一遍所有生成时钟是否都被覆盖。6.2 过度约束导致面积膨胀的案例另一个项目工程师把本该physically exclusive的clock mux写成了-asynchronous。结果工具在CTS阶段把两路时钟都当成有效时钟来平衡时钟树里出现了大量冗余的buffer面积比预期大了15%功耗也上去了。排查方法对比CTS前后的时钟树报告看时钟树的分支结构。如果发现物理上不可能同时存在的分支都被平衡了说明约束类型用错了。改成-physically_exclusive之后工具正确剪枝面积恢复正常。这个案例说明exclusive类型的选择不只是分析不分析的问题还直接影响物理实现的质量。physically exclusive给工具的信息更多优化空间更大。6.3 约束顺序错误导致的静默失败最隐蔽的坑是约束顺序错误。有一次约束文件里set_clock_groups写在了create_generated_clock之前工具没有报错但生成时钟没有被正确归类。因为工具读取set_clock_groups时生成时钟还不存在所以那个时钟名被忽略了。这种静默失败最危险因为工具不报错你以为约束生效了实际上没有。排查方法是写完约束后用report_clock_groups确认每个时钟都在预期的组里。如果某个时钟消失了检查它的创建语句是不是在set_clock_groups之后。注意不同工具对约束顺序的容忍度不同。有些工具会自动重排有些不会。为了可移植性始终按创建时钟→创建生成时钟→声明时钟组→其他例外的顺序写。6.4 多时钟域交叉时的group划分策略当一个设计里有多个时钟域且它们之间的互斥关系不是简单的两两互斥时group划分需要仔细设计。比如有clk_a、clk_b、clk_c三个时钟clk_a和clk_b物理互斥clk_b和clk_c物理互斥但clk_a和clk_c可能同时存在。这种情况下不能简单地把三个时钟分成三组声明两两互斥因为那会错误地排除clk_a和clk_c之间的分析。正确的做法是分两条set_clock_groupsset_clock_groups -physically_exclusive -group {clk_a} -group {clk_b} set_clock_groups -physically_exclusive -group {clk_b} -group {clk_c}这样clk_a和clk_c之间的路径仍然会被分析符合实际。这个细节在复杂SoC设计里很常见group划分错了会导致漏约束或过度约束。7. 写在最后的一点个人体会关于logically exclusive和physically exclusive我最大的体会是约束的本质是把设计意图翻译给工具听。工具不知道你的mux是干什么的不知道你的模式切换逻辑它只能根据你写的约束来推导时钟关系。所以约束写得准不准取决于你对设计意图的理解够不够深。我的习惯是每做一个新项目先把时钟结构图画出来标清楚每个时钟的来源、频率、以及和其他时钟的关系。然后对照这张图写约束写完再用报告验证。这个流程看起来多花时间但能避免后期大量的调试。另外SDC约束不是写完就一劳永逸的。设计改了时钟结构变了约束也要跟着更新。我见过太多项目因为约束没跟上设计变更导致时序分析结果和实际不符。把约束文件当成设计的一部分来维护而不是一次性的脚本这个观念很重要。最后分享一个小技巧在约束文件里给每个set_clock_groups加上-name参数起一个有意义的名字比如-name mux_ab_exclusive。这样在报告里能一眼看出这条约束是干什么的调试的时候省很多事。
