1. 项目缘起从一次“诡异”的CDC违例说起最近在做一个高速接口模块的物理实现项目已经接近尾声静态时序分析STA和形式验证都过了眼瞅着就要流片。为了求个心安我决定用Spyglass跑一遍CDCClock Domain Crossing检查权当是最后的“体检”。结果这一跑还真跑出点东西来——Spyglass报了一个我之前完全没预料到的违例而且这个违例的根源恰恰隐藏在一个看似“理所当然”的异步复位处理中。这个违例不是那种常见的、由于缺少同步器导致的亚稳态风险而是关于异步复位信号的“毛刺过滤”Glitch Filtering问题。Spyglass提示我的异步复位释放de-assertion路径上可能存在毛刺这个毛刺如果被目标时钟域的触发器捕获可能导致系统状态机进入非预期的状态。一开始我还有点不以为然觉得异步复位信号在芯片顶层已经做了很好的处理应该没问题。但Spyglass的报错信息非常具体指向了一个跨时钟域传递的“复位释放”使能信号。这让我不得不停下来重新审视整个异步复位跨时钟域处理的细节。这次经历让我意识到对于CDC验证尤其是使用Spyglass这类专业工具我们的认知往往停留在“数据路径要加同步器”这个层面而对于控制信号特别是复位信号的CDC问题容易想当然地认为“复位是全局的异步的没问题”。实际上复位信号的跨时钟域处理尤其是其释放时机充满了陷阱。Spyglass CDC检查的价值就在于它能系统性地、基于严谨理论模型把这些隐藏在角落里的风险点给挖出来。所以我想把这次排查和解决的过程以及由此延伸出的关于Spyglass CDC在复位信号验证上的一些关键要点记录下来算是对Spyglass CDC功能的一次“拾遗补缺”重点聊聊那些容易被忽略的非典型CDC场景。2. 理解Spyglass CDC的核心检查范式与复位信号的特殊性在深入我的具体案例之前有必要先统一一下我们对Spyglass CDC尤其是它对复位信号检查的基本逻辑的理解。Spyglass CDC不是一个简单的语法检查器它是一个基于静态分析的形式验证工具其核心是构建一个“时钟域模型”和“信号传播模型”。2.1 Spyglass CDC的检查逻辑拆解当你把设计代码RTL和约束文件比如SGDC喂给Spyglass后它会做以下几件事时钟域识别首先它会识别设计中的所有时钟和复位信号并根据你的约束或自动推断确定它们的时钟域归属。一个信号属于哪个时钟域取决于驱动它的触发器的时钟。路径分析接着它会分析所有信号从起点触发器输出、输入端口到终点触发器输入、输出端口的传播路径。跨时钟域标记如果一条路径的起点和终点属于不同的时钟域这条路径就会被标记为潜在的CDC路径。规则检查对于每一条被标记的CDC路径Spyglass会调用一系列内建或用户定义的“规则”Rules去检查它是否符合安全跨时钟域的条件。最著名的规则就是cdc_setup它检查数据路径上是否使用了合适的同步器如两级触发器同步。对于数据信号规则相对明确必须通过同步器隔离。但对于复位信号情况就复杂了。2.2 复位信号的CDC难题释放比有效更危险复位信号通常分为两类同步复位和异步复位。在CDC语境下我们更关注异步复位因为它本身就和时钟无关。复位断言Assertion异步复位有效拉低时它可以直接清零触发器这与时钟无关因此从源时钟域到目标时钟域的复位断言路径通常不被认为是典型的CDC问题因为复位本身是“强制性的”和“异步的”。Spyglass一般会对这类路径进行豁免或特殊处理。复位释放De-assertion这里才是真正的风险区复位释放是一个“同步事件”。当异步复位信号撤销拉高时目标时钟域中的触发器需要在其自身有效时钟沿到来时才会脱离复位状态并开始采样数据。问题在于这个“释放”的边沿是如何传递到目标时钟域的如果这个“释放”信号本身是由另一个时钟域产生的那么它就是一个需要跨时钟域传递的控制信号。这个控制信号的任何抖动、毛刺如果在其无效复位保持和有效复位释放的跳变沿附近发生就可能导致目标时钟域中的部分触发器在一个时钟周期释放另一部分在下一个周期释放从而造成状态不一致。这就是所谓的“复位释放不同步”问题它和亚稳态一样会导致功能错误且极其难以调试。Spyglass CDC对于复位释放路径的检查其核心就是确保从源时钟域产生的“复位释放”控制信号能够安全、无毛刺、同步地传递到目标时钟域并作用于目标寄存器的复位端。3. 案例复盘复位释放使能信号的“毛刺过滤”违例现在回到我遇到的那个具体问题。我的设计中有两个时钟域clk_src(100MHz) 和clk_dst(200MHz)。一个状态机在clk_src域它产生一个rst_release_en信号这个信号拉高表示允许clk_dst域的某个模块脱离复位。rst_release_en信号通过一个两级触发器同步器同步到clk_dst域产生rst_release_en_sync然后这个同步后的信号用于控制clk_dst域的一个本地异步复位信号local_rst_n的释放。简化代码如下// 在 clk_src 域 always (posedge clk_src or negedge global_arst_n) begin if (!global_arst_n) begin rst_release_en 1b0; // ... 其他状态逻辑 end else begin // 状态机逻辑在某个条件满足时释放复位 if (release_condition) begin rst_release_en 1b1; end end end // CDC 同步器模块 sync_2ff u_sync_release_en ( .clk (clk_dst), .rst_n (1b1), // 注意这个同步器本身通常不带复位或者用目标域复位 .d (rst_release_en), .q (rst_release_en_sync) ); // 在 clk_dst 域生成本地复位 always (posedge clk_dst or negedge global_arst_n) begin if (!global_arst_n) begin local_rst_n 1b0; end else begin // 关键逻辑用同步后的使能信号控制本地复位释放 local_rst_n rst_release_en_sync; end end // clk_dst 域的功能逻辑 always (posedge clk_dst or negedge local_rst_n) begin if (!local_rst_n) begin data_dst b0; end else begin data_dst data_src_sync; // 假设data_src已同步 end end看起来似乎没问题使能信号同步了本地复位用同步后的使能信号控制释放。但Spyglass报了一个关于glitch_filter的违例指向从rst_release_en到local_rst_n的路径。3.1 违例根因分析组合逻辑毛刺的潜在风险Spyglass的报错信息深入分析后其担忧在于rst_release_en_sync这个信号直接用于驱动local_rst_n触发器的数据输入D端。在clk_dst的时钟沿采样时rst_release_en_sync必须是一个稳定的值。虽然rst_release_en_sync本身是经过同步器输出的理论上已经消除了亚稳态达到了稳态值但Spyglass会进一步检查产生这个稳态值的源头。它的推理链是这样的local_rst_n的释放依赖于rst_release_en_sync。rst_release_en_sync来自于对rst_release_en的同步。rst_release_en是在clk_src域由寄存器产生的这没问题。但是如果rst_release_en在从0跳变到1的过程中这是一个跨时钟域事件在clk_src域其寄存器输出到端口之间或者在其传输路径上存在微小的组合逻辑哪怕是一个反相器缓冲理论上在电源噪声、串扰等影响下有可能在跳变沿产生一个极短的毛刺glitch。这个毛刺如果被clk_dst域的同步器第一级触发器恰好采样到那么经过两级同步后rst_release_en_sync就可能出现一个同样极短的脉冲尽管概率低但静态分析工具必须考虑最坏情况。这个脉冲如果刚好覆盖了clk_dst的某个时钟沿就会导致local_rst_n在这个时钟沿被误释放而在下一个时钟沿又可能因为脉冲结束而重新被拉低如果rst_release_en_sync恢复为0。这就造成了复位信号的“抖动”对于目标逻辑是灾难性的。注意这种毛刺风险在纯寄存器到寄存器的同步路径上极低但Spyglass作为严谨的验证工具其默认规则cdc_setup会对所有CDC路径提出“无毛刺”要求。对于复位释放这种关键控制信号它尤为严格。3.2 解决方案使用“复位同步器”替代“数据同步器组合赋值”问题的本质在于我们用一个数据信号的同步结果直接作为另一个触发器的数据输入这没有对潜在的毛刺进行过滤。标准的解决方案是使用专用的复位同步器电路。复位同步器的核心思想是在目标时钟域用一个本地触发器链来“展宽”复位释放信号确保释放信号是干净、稳定且持续至少一个目标时钟周期的。常见的复位同步器结构如下module reset_sync ( input wire clk_dst, input wire rst_async_n, // 来自源时钟域的异步复位释放请求低有效 output wire rst_sync_n // 同步到clk_dst域的、干净的异步复位 ); reg [2:0] sync_ff; always (posedge clk_dst or negedge rst_async_n) begin if (!rst_async_n) begin sync_ff 3b000; end else begin sync_ff {sync_ff[1:0], 1b1}; // 将释放请求“1”逐级移位 end end assign rst_sync_n sync_ff[2]; // 取最后一级输出作为同步后的复位 endmodule将这个模块应用到我的案例中// 替换原来的同步器实例化和本地复位生成逻辑 reset_sync u_rst_release_sync ( .clk_dst (clk_dst), .rst_async_n (rst_release_en), // 注意这里输入是源域的使能信号但电路理解其为“异步复位” .rst_sync_n (local_rst_n) // 输出直接就是干净的本地复位 );为什么这样能解决问题毛刺过滤即使rst_release_en上有一个毛刺脉冲这个脉冲必须足够宽才能让sync_ff[0]采样到1并且经过至少3个clk_dst周期后传递到输出。一个极短的毛刺大概率会在三级触发器的链路上被“淹没”无法影响最终的local_rst_n。同步释放复位释放的过程被强制与clk_dst的时钟沿对齐并且释放边沿是“干净”的寄存器输出消除了组合逻辑路径。Spyglass认可这种结构是Spyglass CDC规则库中明确认可的安全复位同步方案。工具识别出这个结构后相关的glitch_filter违例就会消失。修改后重新运行Spyglass CDC关于这条路径的违例果然被清除了。这个案例给我的教训是对于跨时钟域的复位释放控制不要简单地用数据同步器同步一个使能信号然后组合赋值给复位端。应该使用结构清晰的复位同步器模块。4. Spyglass CDC在复位验证中的其他关键检查点与约束解决了手头的问题我趁热打铁系统性地回顾了Spyglass CDC在处理复位信号时其他几个容易出错的检查点和必要的约束方法。4.1 异步复位信号的时钟域约束这是最基本也最容易出错的一步。如果约束不对Spyglass可能无法正确识别CDC路径或者产生大量假违例。对于异步复位信号比如global_arst_n你需要在SGDC文件中明确声明它不属于任何时钟域。# 在 .sgdc 约束文件中 reset -async -active low global_arst_n这条语句告诉Spyglassglobal_arst_n是一个低电平有效的异步复位信号它没有关联的时钟。这样工具就不会将源自或到达这个复位信号的路径误判为CDC路径。4.2 复位同步器的识别与豁免当你使用了类似上文的复位同步器模块后你需要确保Spyglass能正确识别它而不是将其内部路径误报为不安全的CDC。Spyglass通常有内建的知识库lib来识别常见同步器结构。但如果你的代码风格或模块名比较特殊可能需要使用abstract_port或cdc_abstract命令来创建抽象模型或者直接对同步器内部的路径进行豁免。更常见的做法是在SGDC中使用false_path或cdc_false_path约束告诉工具某条特定的复位同步路径是安全的。# 假设复位同步器内部信号为 sync_ff[0], sync_ff[1], sync_ff[2] cdc_false_path -from sync_ff[0] -to sync_ff[1] -clock clk_dst cdc_false_path -from sync_ff[1] -to sync_ff[2] -clock clk_dst但请注意滥用false_path会掩盖真实问题。最佳实践是使用工具认可的、标准的同步器代码模板这样工具通常能自动识别并处理。4.3 多源复位与复位树的CDC检查在复杂SoC中可能存在多个复位源如上电复位、看门狗复位、软件触发复位汇聚到一个复位控制模块然后分发到各个子模块。这形成了一个复位树Reset Tree。Spyglass CDC需要检查复位树中不同复位源可能来自不同时钟域汇聚时的CDC问题。例如一个来自clk_a域的软件复位请求和一个来自clk_b域的看门狗复位请求在复位控制逻辑中做“或”操作生成最终的global_rst_n。这个“或”逻辑本身就是一个CDC汇合点。Spyglass会检查这两个异步复位信号是否都经过了适当的处理例如都先同步到一个公共的时钟域再进行逻辑操作以避免在复位断言或释放时产生竞争条件。对于这种场景约束和设计都需格外小心。通常需要在复位控制模块的输入端为每个来自外部的复位请求添加同步器或脉冲同步器确保它们都同步到控制模块本身的时钟域后再进行逻辑合并。4.4 门控时钟与复位交互的CDC问题另一个高级场景是门控时钟Clock Gating。当一个模块的时钟被门控关闭时其内部的寄存器无法动作。如果此时一个跨时钟域的复位释放信号到来目标模块由于没有时钟其复位同步器无法工作导致复位无法安全释放。当门控重新打开时模块可能处于一个不确定的复位状态。Spyglass CDC可以检查这类问题但需要正确的时钟门控约束。你需要使用clock_gating相关的约束来定义门控时钟结构这样工具才能分析在时钟关闭期间的信号传播情况。对于复位信号一个安全的设计原则是确保复位释放操作发生在目标时钟域时钟稳定开启之后。这通常由系统级的电源管理序列来保证但在RTL设计时也需要考虑。5. 构建稳健的Spyglass CDC复位检查流程基于这次的经验和后续的梳理我总结了一套在项目中使用Spyglass进行CDC检查时针对复位信号的流程和最佳实践。5.1 检查清单复位相关CDC项目在运行Spyglass CDC之前对照这份清单检查你的设计和约束复位信号声明所有异步复位信号包括顶层输入和内部生成的是否都在SGDC中用reset -async正确声明复位同步器设计中所有跨时钟域的复位释放路径是否都使用了标准的复位同步器电路如三级触发器同步释放结构避免使用数据同步器组合逻辑的方式。复位树CDC检查复位控制逻辑。来自不同时钟域的复位请求信号在汇聚前是否已同步到控制逻辑的时钟域门控时钟交互对于有时钟门控的模块检查其复位释放信号是否与时钟使能信号有正确的时序关系确保“时钟先于复位释放”。Spyglass规则集是否启用了针对复位信号的专项检查规则除了默认的cdc_setup可能还需要关注reset_synchronization等相关规则。5.2 调试技巧如何解读Spyglass的复位相关违例当Spyglass报出复位相关的CDC违例时不要急于添加豁免约束。按照以下步骤进行定位路径在Spyglass GUI中或通过报告找到违例的起点From和终点To。确认这是否确实是一条复位信号路径。理解违例类型看清违例代码和描述。是glitch_filterno_synchronizer还是async_reset相关每种类型对应不同的设计问题。查看电路图利用Spyglass的Schematic View功能可视化这条违例路径。看清楚信号是如何从起点传播到终点的中间经过了哪些逻辑单元寄存器、门电路、MUX等。这能帮你快速判断问题所在比如是否在路径上发现了不该有的组合逻辑。区分真假违例真违例路径确实存在CDC风险且当前设计未处理。例如一个异步复位信号直接驱动了另一个时钟域的寄存器异步复位端中间没有任何同步。必须修改设计。假违例/工具误报你的设计实际上是安全的但Spyglass由于约束不完整或无法识别特定安全结构而误报。例如你使用了工具库不认识的复位同步器变种。需要完善约束或修改代码为工具可识别的模式。修正与验证对于真违例采用前面讨论的安全方案如复位同步器进行修改。对于假违例通过添加精确的cdc_false_path约束或修改代码来消除。修改后重新运行CDC检查确保违例被清除且没有引入新问题。5.3 经验之谈复位CDC设计的几个“不要”不要在跨时钟域复位路径上使用简单的缓冲器或反相器。任何组合逻辑都是潜在的毛刺源。不要将同步后的数据使能信号直接赋值给异步复位端。务必使用寄存器链来产生复位释放边沿。不要随意使用cdc_false_path豁免整个复位网络。豁免必须精确到具体的、已验证安全的路径。不要忽略来自不同电源域或始终开启域Always-On Domain的复位信号的CDC问题。它们同样是跨时钟域信号。不要只跑一次CDC检查。在RTL冻结、综合后网表、布局布线后网表等不同阶段都应该进行CDC检查因为后端工具可能会插入缓冲器或进行优化改变原有的时序和结构。Spyglass CDC是一个强大的工具但它需要设计师正确的引导通过约束和深刻的理解才能解读结果。复位信号的CDC验证是其功能中比较深入但至关重要的一环。它要求我们跳出“数据同步”的思维定式从控制信号和系统稳定性的角度去审视设计。这次“拾遗”之旅让我对时钟域交叉有了更立体的认识。真正稳健的设计就是在这些看似边角的细节处都经得起形式化工具的严苛拷问。