别再乱用create_generated_clock了！用这个真实SOC时钟MUX案例，讲透-combinational和-master

深度解析SOC时钟约束：如何正确使用-combinational与-master_clock参数

在复杂的SOC设计中，时钟网络的结构往往比想象中更为复杂。当设计中出现多个时钟源、时钟多路复用器（MUX）以及分频器时，工程师们常常会遇到一个棘手的问题：如何准确约束这些派生时钟？特别是当面对create_generated_clock命令中的-combinational和-master_clock选项时，很多工程师会感到困惑。这两个看似简单的参数，实际上关系到整个设计的时序分析准确性。

1. 理解时钟网络的基本结构

让我们从一个典型的SOC时钟网络案例开始。假设我们有一个系统，其中包含两个来自PLL的异步时钟源：CLKa（周期10ns）和CLKb（周期13.333ns）。CLKa经过分频后产生CLKr，用于控制通路；同时，CLKa和CLKb通过一个时钟MUX（CLK_MUX）选择输出CLKm，CLKm再经过分频产生CLKd。

这种结构在现代SOC设计中非常常见，但也带来了几个关键问题：

如何正确定义通过MUX的时钟路径？
如何处理分频后的派生时钟？
如何确保时序分析工具能够正确识别所有可能的时钟路径？

2. -combinational参数的核心作用

-combinational参数可能是create_generated_clock命令中最容易被误解的选项之一。它的核心作用是告诉时序分析工具：这个生成的时钟是通过组合逻辑（如MUX）产生的，而不是通过时序元件（如寄存器）产生的。

2.1 为什么PATH R不是时钟路径

考虑CLK_MUX的情况：当选择信号（假设为SEL）变化时，MUX的输出会立即跟随被选中的输入变化。这种组合路径（PATH R）实际上只是一条控制通路，不应该被视为时钟路径。如果不使用-combinational参数，时序分析工具可能会错误地将PATH R也当作合法的时钟路径进行分析，导致时序报告不准确。

# 正确的MUX时钟约束 create_generated_clock -name CLK_m0 [get_pins U_CLKMUX/Z] \ -source [get_pins U_PLL/OUT0] -combinational create_generated_clock -name CLK_m1 [get_pins U_CLKMUX/Z] \ -source [get_pins U_PLL/OUT1] -combinational -add

2.2 组合路径与时序路径的对比

特性	组合路径	时序路径
传播延迟	组合逻辑延迟	时钟到Q延迟
时序分析	需要检查建立/保持时间	通常不直接分析
时钟特性	无时钟特性	有时钟特性
典型元件	MUX, AND/OR门等	寄存器, 分频器等

3. -master_clock参数的必要性

当派生时钟的源时钟不唯一时，-master_clock参数就变得至关重要。它明确指定了派生时钟的"主时钟"，即当时序分析工具需要确定时钟频率时应该参考的时钟。

3.1 源时钟唯一时的情况

对于CLKr这样的派生时钟，由于它只有一个源时钟（CLKa），所以-master_clock参数是可选的：

# 源时钟唯一时，-master_clock可选 create_generated_clock -name CLKr [get_pins U_DIV_r/OUT] \ -source [get_pins U_PLL/OUT0] -divide_by N

3.2 源时钟不唯一时的处理

对于CLKd这样的派生时钟，情况就不同了。因为CLKd可以来自CLK_m0或CLK_m1，如果不指定-master_clock，工具默认只会识别最近定义的源时钟：

# 必须指定-master_clock，因为源时钟不唯一 create_generated_clock -name CLK_d0 [get_pins U_DIV_d/OUT] \ -source [get_pins U_CLKMUX/Z] -divide_by M -master_clock CLK_m0 create_generated_clock -name CLK_d1 [get_pins U_DIV_d/OUT] \ -source [get_pins U_CLKMUX/Z] -divide_by M -master_clock CLK_m1 -add

3.3 常见错误与后果

遗漏-master_clock：当时钟源不唯一时，工具可能只检查部分时钟路径，导致其他路径的时序问题被忽略。
错误指定主时钟：可能导致工具使用错误的时钟频率进行时序分析。
忘记-add选项：当定义多个生成时钟到同一节点时，必须使用-add，否则前一个定义会被覆盖。

4. 完整约束脚本与物理互斥声明

将上述所有部分组合起来，我们得到一个完整的时钟约束脚本：

# 1. 创建基础时钟 create_clock -name CLKa -period 10 [get_pins U_PLL/OUT0] create_clock -name CLKb -period 13.333 [get_pins U_PLL/OUT1] # 2. 定义控制通路的派生时钟 create_generated_clock -name CLKr [get_pins U_DIV_r/OUT] \ -source [get_pins U_PLL/OUT0] -divide_by N # 3. 定义CLK_MUX后的派生时钟 create_generated_clock -name CLK_m0 [get_pins U_CLKMUX/Z] \ -source [get_pins U_PLL/OUT0] -combinational create_generated_clock -name CLK_m1 [get_pins U_CLKMUX/Z] \ -source [get_pins U_PLL/OUT1] -combinational -add # 4. 定义分频后的派生时钟 create_generated_clock -name CLK_d0 [get_pins U_DIV_d/OUT] \ -source [get_pins U_CLKMUX/Z] -divide_by M -master_clock CLK_m0 create_generated_clock -name CLK_d1 [get_pins U_DIV_d/OUT] \ -source [get_pins U_CLKMUX/Z] -divide_by M -master_clock CLK_m1 -add # 5. 声明物理互斥关系 set_clock_groups -physically_exclusive \ -group {CLK_m0 CLK_d0} \ -group {CLK_m1 CLK_d1}

4.1 物理互斥的重要性

set_clock_groups -physically_exclusive声明非常重要，它告诉时序分析工具这些时钟组之间是物理互斥的（即同一时间只有一个组是活动的）。这可以：

避免工具分析不存在的跨时钟域路径
减少不必要的时序分析工作量
提高时序收敛的效率

5. 实际工程中的经验分享

在实际项目中，时钟约束错误是导致芯片功能故障的常见原因之一。以下是几个值得注意的经验点：

MUX选择信号的约束：虽然我们关注的是时钟路径，但MUX的选择信号也需要正确的时序约束，确保它在时钟边沿之前稳定。
时钟切换的glitch处理：在真实的时钟MUX中，需要特别注意时钟切换时可能产生的glitch。这通常需要在RTL级别处理。
分频系数的选择：在约束中指定的分频系数应该是最小值（对应最高频率），这样工具会检查最恶劣的建立时间情况。而保持时间与频率无关，所以不需要特别考虑。
验证约束的正确性：可以通过以下方法验证：
- 使用report_clocks命令检查所有定义的时钟
- 使用report_clock_network检查时钟传播路径
- 检查时序报告中是否包含了所有预期的时钟路径
不同工具的处理差异：虽然SDC是行业标准，但不同工具对某些复杂时钟场景的处理可能略有差异。在项目初期就应该验证约束在所有工具中的行为是否一致。