1. 项目概述时钟域隔离不是“加个约束就完事”而是数字电路稳定运行的底层防线在FPGA和ASIC后端实现流程中set_clock_groups这条Tcl命令出现的频率极高但真正能说清楚它和create_clock、Logically Exclusive、Physically Exclusive之间逻辑关系的人远比天天在综合/布局布线日志里看到它报错的人少得多。我带过十几届数字前端实习生90%以上第一次遇到跨时钟域CDC问题时第一反应是去查异步FIFO怎么写却从没想过——为什么综合工具会把两个明明不相关的时钟路径标成“unconstrained”为什么时序报告里突然冒出一堆“clock skew too large”的警告而你的RTL里根本没做任何时钟分频或门控答案往往就藏在这条看似简单的约束命令背后。它不是锦上添花的可选项而是决定芯片能否流片成功的硬性门槛。本文聚焦于一个真实场景当你用create_clock定义了多个主时钟比如50MHz系统时钟、125MHz PCIe参考时钟、24MHz USB PHY时钟又引入了由PLL输出的衍生时钟如100MHz DDR控制器时钟、300MHz Video像素时钟这些时钟之间既不驱动同一组寄存器也不共享任何物理布线资源但工具默认仍会尝试计算它们之间的时序路径——这不仅浪费数小时的STA运行时间更会导致虚假违例false path掩盖真正危险的CDC毛刺风险。这时候set_clock_groups就成了你手里的“时钟域隔离手术刀”。它不改变电路功能但彻底重定义了静态时序分析STA的搜索空间。本文将完全基于实际项目经验展开不讲抽象理论只拆解每一步操作背后的物理意义、典型误用场景、以及我踩过的三个致命坑——比如某次因漏加 -physically_exclusive 导致后仿波形中出现亚稳态传播返工重跑PR花了整整四天。2. 核心设计思路与方案选型为什么必须区分Logically vs Physically Exclusive2.1 本质差异逻辑隔离 ≠ 物理隔离混淆二者等于埋下时序炸弹很多工程师把-logically_exclusive和-physically_exclusive当作同义词交替使用这是最危险的认知偏差。它们解决的是两类完全不同的问题根源在于STA工具对“时钟关系”的建模方式不同。Logically Exclusive 的核心语义是“这两个时钟永远不会同时有效”。典型场景是多路复用的时钟选择器clock mux。例如一个SoC通过寄存器配置选择由内部RC振荡器1MHz或外部晶振24MHz作为系统主时钟。在任意时刻只有一个时钟信号被使能并驱动后续逻辑。此时工具需要知道当A时钟有效时B时钟路径上的所有触发器都处于“冻结”状态其Q端输出不会变化因此A到B、B到A的任何路径都不构成有效时序路径。关键点在于这两个时钟可能共用同一段全局时钟网络比如都走同一个BUFG物理上完全重叠但逻辑上互斥。工具据此会自动将所有跨时钟路径标记为false path并跳过相关建立/保持检查。Physically Exclusive 的核心语义是“这两个时钟在物理布线上完全隔离永不相交”。典型场景是独立的IP模块自带专用时钟源。例如一个视频处理子系统使用独立的27MHz HDMI时钟其所有寄存器都由专用BUFGCE驱动而主CPU系统使用100MHz时钟走另一组BUFG。这两组时钟网络在FPGA的时钟树结构中属于完全不同的根节点root node物理布线资源如时钟布线通道、缓冲器零共享。此时工具需要知道不仅逻辑上不交互物理上也绝无可能产生耦合噪声或skew干扰。因此除了标记false path工具还会彻底禁用对这两组时钟之间任何路径的时序分析甚至不生成相关路径报告。这直接节省了30%-50%的STA运行时间在大型设计中尤为关键。提示一个常见错误是对两个物理上完全独立的时钟如PCIe REFCLK和USB PHY CLK仅使用-logically_exclusive。工具虽会忽略路径但仍会为每个时钟单独构建完整的时钟树模型并尝试计算它们之间的潜在交互——这在物理上不可能发生纯属算力浪费。正确做法是优先用-physically_exclusive仅在时钟存在物理共享但逻辑互斥时才用-logically_exclusive。2.2 为什么不能只靠create_clock约束链的完整性陷阱create_clock是时序约束的起点但它只完成“定义”动作不涉及“关系声明”。你可以用它创建十个时钟但工具默认认为它们全部“可能相互影响”。这就像给十个人发了十把钥匙却不告诉保安哪些钥匙能开同一扇门——保安只能挨个试效率极低且结果不可靠。举个具体例子某AI加速卡设计中我们定义了以下四个时钟create_clock -name sys_clk -period 10.0 [get_ports sys_clk_p] create_clock -name ddr_clk -period 2.5 [get_ports ddr_clk_p] create_clock -name video_clk -period 3.7037 [get_ports video_clk_p] create_clock -name pcie_refclk -period 8.0 [get_ports pcie_refclk_p]仅执行这些命令后Vivado STA引擎会默认尝试分析sys_clk → ddr_clk、video_clk → pcie_refclk等所有6×530种组合的路径。但实际上sys_clk和ddr_clk属于同一时钟域DDR控制器由sys_clk派生通过MMCM生成应做时钟不确定性set_clock_uncertainty约束video_clk和pcie_refclk来自不同板级晶振物理引脚隔离PCB走线间距20mil全程无共享电源/地平面——这是典型的Physically Exclusive场景sys_clk和video_clk虽物理隔离但存在软件配置的时钟切换逻辑如DisplayPort模式切换时关闭video_clk属于Logically Exclusive。若不加 set_clock_groups工具会报告数百条video_clk → sys_clk的保持时间违例hold violation而这些路径在硬件上根本不存在。工程师可能误以为是布局布线问题反复调整placement最终发现只是约束缺失。因此create_clock 是“画圆”set_clock_groups 是“划界”二者缺一不可共同构成完整的时序约束链。2.3 方案选型决策树三步锁定最优约束类型面对一组新时钟如何快速判断该用哪种exclusive我总结了一套现场可用的三步决策法已在五个量产项目中验证有效第一步查物理连接Physical Inspection打开FPGA器件手册的Clocking Resources章节定位每个时钟使用的BUFG/BUFH/PLLE2/MMCM资源ID。例如Xilinx UltraScale中BUFGCE_X0Y0和BUFGCE_X1Y5属于不同时钟区域clock region其下游布线资源天然隔离。若两个时钟的根缓冲器ID完全不同且无任何跨区域时钟布线如HROW连接则直接进入Physically Exclusive分支。第二步看控制逻辑Logic Tracing在RTL中搜索时钟使能信号clock enable、复位同步器reset synchronizer、时钟选择器clock mux。若存在类似assign clk_out (sel 2b01) ? clk_a : clk_b;的代码且sel由寄存器配置说明两个时钟逻辑上不能同时有效。此时需确认是否存在某个时刻clk_a和clk_b同时为高电平若严格互斥即sel信号变化时必有至少一个周期的无效状态则适用Logically Exclusive。第三步验功能需求Functional Verification调出仿真波形观察两个时钟在全激励下的活动窗口。重点检查是否存在任何测试用例让两个时钟同时处于活跃期active cycle若存在它们驱动的寄存器是否有数据交互如FIFO读写指针若无交互且无同时活跃期则两种exclusive皆可但Physically Exclusive优先性能更好若有同时活跃期但无数据通路如两个独立ADC采样则必须用-asynchronous异步约束本文暂不展开。注意某次在调试一个工业相机接口时我们误判cam_clk和sys_clk为Logically Exclusive因为文档写着“相机模块可软件关闭”。但仿真发现关闭指令发出后cam_clk需要3个周期才能真正停振在此期间sys_clk仍在运行且两者通过AXI总线存在地址译码交互。最终改用-asynchronous约束并增加两级同步器才解决亚稳态问题。这个教训说明功能验证永远是约束决策的最终仲裁者文档和推测不可替代实测波形。3. 核心细节解析与实操要点参数、语法与不可见的陷阱3.1 set_clock_groups 命令的完整语法骨架与参数深意set_clock_groups的基础语法看似简单但每个参数都承载着严格的物理含义。其标准形式为set_clock_groups -group {clock_list_1} -group {clock_list_2} [options]其中clock_list_N是用{}包裹的时钟名列表支持通配符如*ddr*但严禁使用正则表达式Vivado不支持。关键选项如下-logically_exclusive声明组间逻辑互斥。工具将所有跨组路径设为false path并禁用建立/保持检查。-physically_exclusive声明组间物理隔离。除上述效果外工具还会• 不生成跨组路径的时序报告Report Timing不显示• 不计算跨组时钟树的skew和latency• 在布局布线阶段避免将跨组寄存器放置在同一SLRSuper Logic Region内UltraScale特有优化。-asynchronous声明组间异步。这是最严格的约束工具会• 将所有跨组路径标记为false path• 强制要求在跨组数据路径上插入同步器synchronizer• 若未检测到同步器报告CDC违规需配合report_cdc命令。-exclusive已废弃等价于-logically_exclusive但Vivado 2022.1后警告弃用必须改用明确语义的选项。提示-group参数支持多个例如-group {a b} -group {c} -group {d e f}表示a/b互斥于c也互斥于d/e/f但c与d/e/f之间不自动互斥——必须显式声明。我曾因漏写-group {c} -group {d}导致c和d间的路径未被约束引发后仿失败。3.2 create_clock 的隐含陷阱周期、波形与源点选择create_clock虽是基础命令但参数设置错误会直接导致set_clock_groups失效。三大高频陷阱如下陷阱一周期精度丢失Period Precision-period 10.0看似精确但Vivado内部以皮秒ps为单位存储。若实际时钟周期为9.999ns如100.01MHz写成-period 10.0会引入0.01ns误差。在高速设计中这可能导致时序余量slack计算偏差达±5%。正确做法是使用精确值-period 9.999或-[expr 1000/100.01]Tcl表达式计算。我们在PCIe Gen3设计中因周期值取整导致pcie_refclk的建立时间余量虚高0.12ns流片后在高温下出现丢包。陷阱二波形定义缺失Waveform Definition默认create_clock假设50%占空比方波-waveform {0 5}for 10ns period。但某些IP核如MIPI D-PHY输出非对称时钟。若不指定波形工具会错误计算建立/保持时间窗口。例如一个上升沿敏感的寄存器若时钟高电平仅占30%则实际建立时间窗口比默认值短。必须显式添加-waveformcreate_clock -name dphy_clk -period 1.6 -waveform {0 0.48} [get_ports dphy_clk]此处{0 0.48}表示上升沿在0ps下降沿在480ps占空比30%确保时序分析匹配真实电气特性。陷阱三源点Source Point选择错误create_clock的[get_ports ...]应指向时钟输入端口而非内部生成点。例如若ddr_clk由MMCM输出错误写法# 错误指向内部net工具无法关联到物理引脚 create_clock -name ddr_clk -period 2.5 [get_nets ddr_clk_mmcm_out]正确写法必须绑定到顶层端口# 正确绑定到物理引脚工具可提取IO延迟 create_clock -name ddr_clk -period 2.5 [get_ports ddr_clk_p]否则set_clock_groups中的时钟组将无法被STA引擎正确识别约束形同虚设。3.3 实操中的“隐形”依赖约束顺序与Tcl脚本组织Vivado的约束解析是顺序敏感的。set_clock_groups必须在所有相关时钟被create_clock定义之后执行否则工具报错ERROR: [Common 17-69] Command failed: Cannot find clock xxx。但这只是表象深层依赖在于时钟树构建时机。在完整约束脚本中我强制遵循以下四层结构已在三个千万门级项目中验证# 第一层I/O约束必须最先 set_property PACKAGE_PIN Y12 [get_ports sys_clk_p] set_property IOSTANDARD LVDS [get_ports sys_clk_p] # 第二层时钟定义create_clock紧随I/O后 create_clock -name sys_clk -period 10.0 [get_ports sys_clk_p] create_clock -name ddr_clk -period 2.5 [get_ports ddr_clk_p] # 第三层时钟关系set_clock_groups必须在此层 set_clock_groups -physically_exclusive -group {sys_clk} -group {ddr_clk} set_clock_groups -logically_exclusive -group {video_clk} -group {sys_clk} # 第四层时序例外set_false_path, set_max_delay等最后 set_false_path -from [get_clocks sys_clk] -to [get_clocks video_clk]若将第三层提前到第二层之前即使时钟名存在工具也会因时钟树未初始化而忽略约束。更隐蔽的问题是当使用Tcl变量动态生成时钟名时必须确保变量在create_clock前已赋值。例如# 危险变量未定义 set clk_name ddr_clk set_clock_groups -group {$clk_name} -group {sys_clk} ... # 正确先定义再使用 set ddr_clk_name ddr_clk create_clock -name $ddr_clk_name -period 2.5 [get_ports ddr_clk_p] set_clock_groups -group {$ddr_clk_name} -group {sys_clk} ...Tcl的变量替换发生在命令执行时而非脚本解析时此细节常被忽略。4. 实操过程与核心环节实现从零开始构建可靠时钟约束4.1 全流程实操步骤以双摄像头系统为例我们以一个实际的双摄像头采集系统Dual-Camera Capture System为例完整演示从时钟定义到约束验证的七步法。该系统包含主控时钟sys_clk100MHz、左摄像头时钟cam_l_clk27MHz、右摄像头时钟cam_r_clk27MHz、以及图像处理时钟proc_clk150MHz。所有时钟均由独立晶振提供物理隔离。步骤1物理资源核查耗时5分钟查阅Xilinx Kintex-7 datasheet DS182确认sys_clk使用BUFGCE_X0Y12cam_l_clk使用BUFGCE_X2Y3cam_r_clk使用BUFGCE_X2Y4proc_clk使用BUFGCE_X1Y8四者根缓冲器ID完全不同且位于不同时钟区域Clock Region满足Physically Exclusive前提。步骤2RTL时钟实例化检查耗时10分钟在Verilog中确认cam_l_clk和cam_r_clk无任何逻辑交互各自独立的AXI Stream接口proc_clk与sys_clk通过AXI Interconnect连接存在地址译码但无数据通路图像数据走专用DMA所有时钟均无mux逻辑无软件切换故排除Logically Exclusive。步骤3编写基础时钟约束Tcl脚本 core_clocks.xdc# I/O约束省略具体pin仅示意 set_property PACKAGE_PIN E18 [get_ports sys_clk_p] set_property PACKAGE_PIN G17 [get_ports cam_l_clk_p] set_property PACKAGE_PIN F17 [get_ports cam_r_clk_p] set_property PACKAGE_PIN D18 [get_ports proc_clk_p] # 创建时钟精确周期绑定端口 create_clock -name sys_clk -period 10.000 -waveform {0 5} [get_ports sys_clk_p] create_clock -name cam_l_clk -period 37.037 -waveform {0 18.5185} [get_ports cam_l_clk_p] create_clock -name cam_r_clk -period 37.037 -waveform {0 18.5185} [get_ports cam_r_clk_p] create_clock -name proc_clk -period 6.6667 -waveform {0 3.3333} [get_ports proc_clk_p]步骤4定义时钟组关系核心约束# 组1主控与图像处理时钟物理隔离但存在AXI控制通路需-asynchronous set_clock_groups -asynchronous -group {sys_clk} -group {proc_clk} # 组2左右摄像头时钟物理隔离无任何交互-physically_exclusive set_clock_groups -physically_exclusive -group {cam_l_clk} -group {cam_r_clk} # 组3摄像头与时钟组1全部物理隔离 set_clock_groups -physically_exclusive -group {cam_l_clk} -group {sys_clk proc_clk} set_clock_groups -physically_exclusive -group {cam_r_clk} -group {sys_clk proc_clk}注意-group {sys_clk proc_clk}是合法的表示将两个时钟视为同一组与cam_l_clk整体互斥。步骤5约束加载与初步验证在Vivado Tcl Console中执行read_xdc ./constraints/core_clocks.xdc link_design -part xck70t-fbg484-2 report_clock_networks检查输出中是否列出所有四个时钟且Relationships列显示Asynchronous或Physically Exclusive。若显示None说明约束未生效。步骤6深度时序验证关键运行完整STArun_timing_summary report_timing_summary -file timing_pre_constraint.rpt对比约束前后的报告约束前Total number of paths analyzed 500,000含大量cam_l_clk → cam_r_clk路径约束后该数字应降至 200,000且cam_l_clk → cam_r_clk路径消失关键指标WNS (Worst Negative Slack)应显著改善通常提升0.3-0.8ns。步骤7CDC专项检查终极验证report_cdc -details -file cdc_report.rpt检查报告中Asynchronous Clock Groups部分是否列出sys_clk/proc_clk对Synchronizer Check是否通过Status: PASS若有FAIL需在跨时钟路径上手动插入两级DFF同步器。实测心得某次在步骤6中发现WNS未改善排查发现cam_l_clk的端口名在XDC中写为cam_l_clk_p但在RTL中定义为cam_l_clk漏了_p后缀。工具创建时钟失败但未报错导致约束失效。因此每次修改XDC后务必执行report_clocks确认所有时钟已成功创建。4.2 参数计算与选择周期、波形与物理隔离的量化依据所有约束参数必须有物理依据而非凭经验猜测。以下是关键参数的计算方法周期Period计算直接使用频率倒数但需考虑测量精度。例如标称27MHz晶振实测为27.0005MHz则set period_ps [expr 1000000000 / 27.0005] # 37036.78 ps ≈ 37.037 ns create_clock -name cam_clk -period 37.037 [get_ports cam_clk_p]波形Waveform计算对于LVDS时钟示波器实测上升沿Rise和下降沿Fall时间。假设上升沿在0ps参考点下降沿在18.5185ns50%占空比则-waveform {0 18.5185}。若占空比为40%则下降沿在14.8148ns37.037×0.4。物理隔离验证量化标准根据IPC-2221B标准高速时钟线间隔离需满足最小间距 3 × 介质厚度FR4板厚1.6mm → 间距≥4.8mm与相邻电源/地平面距离 ≥ 2mm无共享过孔via或焊盘。在PCB设计软件中用“Measure Distance”工具实测cam_l_clk与cam_r_clk走线中心距为6.2mm满足要求支撑-physically_exclusive决策。4.3 约束文件组织与版本管理避免“约束地狱”大型项目常有数十个XDC文件混乱的组织会导致约束覆盖或遗漏。我采用三级目录结构/constraints/ ├── /io/ # I/O约束pin, IOSTANDARD │ ├── board_pins.xdc │ └── interface_pins.xdc ├── /clocks/ # 时钟约束create_clock set_clock_groups │ ├── core_clocks.xdc # 主时钟与关系 │ └── ip_clocks.xdc # IP核专用时钟如DDR, PCIe └── /timing/ # 时序例外false path, max delay ├── cdc_exceptions.xdc └── interface_timing.xdc并在顶层Tcl脚本中按顺序加载# load_constraints.tcl source ./constraints/io/board_pins.xdc source ./constraints/clocks/core_clocks.xdc source ./constraints/clocks/ip_clocks.xdc source ./constraints/timing/cdc_exceptions.xdc关键技巧在每个XDC文件头部添加注释块声明适用的Vivado版本和设计模块# core_clocks.xdc # Vivado Version: 2022.2 # Applies to: Top-level module dual_cam_top # Last Modified: 2023-10-15 by Zhang San # Description: Defines main clocks and their physical exclusivity这样当升级Vivado版本或模块重构时可快速定位需更新的约束文件。5. 常见问题与排查技巧实录那些让你熬夜到凌晨三点的Bug5.1 典型问题速查表症状、原因与一键修复问题现象根本原因快速修复方案验证命令ERROR: [Common 17-69] Cannot find clock xxxset_clock_groups在create_clock前执行或时钟名拼写错误检查XDC文件顺序执行report_clocks确认时钟存在用get_clocks *xxx*查找匹配名report_clocksWARNING: [Vivado 12-1803] No paths found between two clock domains误用-logically_exclusive于物理隔离时钟工具跳过分析改为-physically_exclusive若需保留逻辑互斥语义添加-asynchronous并插入同步器report_cdcINFO: [Timing 38-424] Found 123 false paths但WNS无改善set_false_path覆盖了set_clock_groups后者被忽略删除所有冗余set_false_pathset_clock_groups是更高阶约束无需额外false pathreport_timing -from [get_clocks a] -to [get_clocks b]CRITICAL WARNING: [Vivado 12-1411] Clock group relationship not applied时钟组中存在未定义的时钟名或使用了非法字符如空格、-用get_clocks列出所有时钟确保组内时钟名完全匹配大小写敏感get_clocks *后仿出现亚稳态Metastability波形-asynchronous约束存在但未在RTL中实现同步器在跨时钟数据路径插入两级DFF用report_cdc -synchronizer_check验证report_cdc -synchronizer_check5.2 我踩过的三个致命坑与独家避坑技巧坑一 “同源时钟”的幻觉某次设计中sys_clk和ddr_clk均来自同一晶振经不同MMCM分频生成。我以为它们是“同源”故未加任何set_clock_groups仅用set_clock_uncertainty。结果在高温测试中DDR控制器出现随机写入失败。根源在于两个MMCM的输出相位抖动jitter统计独立工具默认计算最大可能skew500ps远超DDR PHY允许的200ps。避坑技巧即使同源只要经过独立的时钟管理单元MMCM/PLL就必须用set_clock_groups -asynchronous并严格约束跨时钟路径的同步器。坑二 “物理隔离”的过度自信cam_l_clk和cam_r_clk在PCB上间距6mm我断定物理隔离用了-physically_exclusive。但量产测试发现当两个摄像头同时高帧率工作时cam_r_clk的抖动增大3倍。原因是两路时钟走线虽隔离但共用同一组电源滤波电容开关电流耦合导致噪声串扰。避坑技巧物理隔离必须同时检查电源/地网络。用电源完整性PI仿真工具如ANSYS SIwave验证在cam_l_clk切换时cam_r_clk电源轨的噪声电压 10mVpp。坑三 “约束已加载”的假象在Vivado GUI中点击“Add Sources”导入XDC后界面显示“Constraints added”但我执行report_clocks却看不到新时钟。原因是GUI默认将XDC添加到“Constrains”源集但当前正在运行的综合/实现流程绑定的是“Design”源集。避坑技巧永远在Tcl Console中执行read_xdc your_file.xdc并立即跟report_clocks验证或在GUI中右键XDC文件 → “Set as Target Constraint Set”。5.3 高级排查技巧从波形到约束的逆向追踪当问题难以复现时我常用“波形反推约束法”在VCS或ModelSim中导出问题信号的波形VCD格式用Python脚本解析VCD定位亚稳态发生时刻t_fail回溯t_fail前一个周期找到驱动该信号的时钟边沿如cam_l_clk上升沿检查该边沿后接收端时钟如sys_clk的下一个边沿时间t_next计算t_next - t_fail若 同步器最小恢复时间如两级DFF需2ns则证明约束不足在XDC中添加针对性约束set_max_delay -from [get_clocks cam_l_clk] -to [get_clocks sys_clk] 1.8。此方法曾在一次DDR眼图测试失败中30分钟内定位到sys_clk与ddr_clk间未约束的set_input_delay避免了重新流片。6. 约束有效性验证与签核如何向项目经理证明“这事真搞定了”6.1 五维验证法从工具报告到硬件实测仅仅看到Timing Summary中WNS0.123是不够的。我坚持用五个维度交叉验证约束有效性维度一STA报告一致性运行report_timing_summary -delay_type min_max确认WNS和TNSTotal Negative Slack均为正值Number of failing endpoints 0Asynchronous Paths数量与set_clock_groups声明的组数一致。维度二CDC报告完备性report_cdc -full_report -file cdc_full.rpt中Synchronizer Check全部PASSAsynchronous Clock Groups列出所有预期组对No Synchronizer警告数为0。维度三时钟树报告物理性report_clock_networks -skew中每个时钟的Max Skew 该时钟周期的10%如100MHz时钟skew 0.1nsPhysically Exclusive组的时钟其Root NodeID 完全不同。维度四布局布线可视化在Vivado GUI中Open Implemented Design→Tools→Clocking→Clock Interaction选择两个时钟查看Interaction Type是否显示Physically Exclusive右键Show Routing确认无跨组布线红色高亮线仅在组内。维度五硬件实测回归在FPGA开发板上运行压力测试如双摄像头7x24小时采集用逻辑分析仪捕获cam_l_clk和cam_r_clk的相对相位确认无周期性漂移温度从25°C升至85°C重复测试bit error rate 1e-12。个人体会某次项目签核前STA报告完美但硬件测试在70°C出现丢帧。最终发现是proc_clk的create_clock未指定-waveform工具按50%占空比计算而实际在高温下占空比偏移到45%导致建立时间不足。这提醒我约束验证的终点永远是硬件不是工具报告。现在我强制要求每个create_clock后必须附上示波器实测波形截图嵌入约束文档。6.2 签核清单一份可直接交付给DFT和验证团队的Checklist为确保约束被下游环节无缝继承我制作了一份标准化签核清单Sign-off Checklist包含12项硬性指标✅ 所有create_clock命令绑定到顶层物理端口非内部net✅ 所有create_clock的-period