这些年做数字IC验证和 race-condition 打交道最多的阶段其实就是后仿真。RTL仿真跑一万遍都没事的代码网表加上SDF反标一进去芯片内部那些原本觉得“同时”发生的事件因为每一条路径的延迟差异开始互相抢跑。轻则寄存器采样到错误数据重则总线冒出一整片X态复位之后状态机直接飞掉。之前两篇聊过竞态的概念和基本定位思路这一期是场景举例的第三篇我把实际项目中撞到过的、以及同行朋友踩过的几种典型后仿真竞态场景整理出来逐个拆一遍根因、现象和修法。内容偏实战适合已经在做网表仿真或者正被后仿X态折磨的验证工程师也适合做前端设计但总被后仿问题追着改代码的朋友。1. 异步复位释放撞时钟沿只在后仿里复现的复位竞态1.1 为什么RTL仿真岁月静好换上SDF就翻车异步复位是芯片里最常见的结构复位拉低时所有寄存器被强制清零复位释放则让寄存器恢复正常的采样工作。问题就出在“释放”这个动作上异步复位信号和系统时钟之间本来没有确定的相位关系释放沿落在哪个位置完全看外部时序。RTL仿真里为什么发现不了因为测试平台的复位激励通常写得非常“干净”要么用#100 reset_n 1要么用无延迟的赋值语句信号翻转和时钟沿之间的间隔足够大。就算刚好和时钟沿出现在同一个仿真时刻仿真器的事件调度也会按照固定优先级处理结果是确定的所以看不见问题。到了后仿真就完全不一样了。复位信号进入芯片后要经过复位树、buffer链才能到达每个寄存器时钟也要经过时钟树两条路径的延迟不可能完全一致。SDF反标后内存库单元里的时序检查开始生效如果复位释放沿和时钟采样沿之间的距离小于库里的最小恢复/移除时间触发器仿真模型就会输出一个X态而不是像真实电路那样可能“偶尔正常、偶尔亚稳态”。这种X态往往不是一个寄存器的问题而是在同一条复位树下的一大片寄存器同时出现。这个场景典型到几乎每个项目都会碰到一次。某次做一颗MCU子系统的门级仿真功能用例全部通过唯独上电后第一条指令取回来是乱码。查了半天发现不是指令ROM的问题而是复位释放沿正好落在PLL切换后的第一个时钟上升沿附近一部分寄存器恢复成复位值另一部分寄存器已经按正常输入采样整个内核状态根本对不上。1.2 怎么快速判断是不是复位竞态遇到后仿刚一开始就跑挂的情况先别急着追数据流先看复位释放沿和时钟沿的相对位置。波形上把reset_n和clk拉出来如果释放沿和某个时钟上升沿之间的距离小于一个明显可见的门级延迟范围就高度怀疑是这个问题。还有一个很实用的判断方法把仿真跑到复位释放后的第一个周期就暂停看寄存器堆里的值。如果发现多数寄存器是复位初值少数寄存器已经写入了外部输入而且这种“部分复位”现象在不同seed下表现不一样大概率就是复位释放竞态。用一段简单的Verilog监控也能帮忙在仿真顶层加一个检查逻辑always (posedge clk) begin if ($rose(reset_n) || $fell(reset_n)) begin $display([%0t] Reset edge detected within setup/hold window!, $time); $warning(RESET_RACE_CHECK); end end不过这个检查比较粗糙。更严谨的做法是计算释放沿到最近时钟沿的时间差再和目标库里的复位恢复时间对比。如果时间差小于库要求就要当作真正的问题报告出来而不是等着看X态扩散。1.3 修复一定要动设计不能靠测试平台绕过很多工程师第一反应是改tb把复位释放沿往后挪或者加一个延时让释放沿离时钟沿远一点。这只能让仿真跑过去芯片该出的问题照样会出。真正修复手段是异步复位同步释放电路也就是常说的复位同步器在复位释放路径上插两级触发器把异步复位信号先在目标时钟域里打两拍再用同步后的释放沿去释放各个寄存器的复位端。这样释放沿就被强制对齐到时钟沿附近并且满足恢复/移除时间约束。复位树的延迟平衡同样重要。如果复位信号到达不同寄存器的延迟差异太大即使源头做了同步释放到具体寄存器时释放沿依然可能落在不同相位上。实际项目中通常要求复位树和时钟树一起做时序收敛后仿阶段发现问题后要把这个race点报给后端做ECO或者调整树结构。除此之外还需要检查复位释放时时钟本身是否稳定比如PLL锁定、时钟切换这些场景。曾经遇到过一个例子PLL旁路切到锁定输出的一瞬间时钟沿本身有抖动复位同步器输出虽然稳定但后续寄存器仍然采样到不确定值。这种情况单靠复位同步器解决不了必须把时钟切换和复位释放的先后顺序用状态机管起来先等时钟稳定再释放复位。2. 跨时钟域握手信号被采进亚稳态窗口X态从同步器根部开始扩散2.1 两级同步器为什么后仿还会出问题跨时钟域最常用的手段是两级同步器信号在目的时钟域连打两拍把异步信号同步进来。这个结构在RTL仿真里几乎不会出问题因为所有信号都是零延迟变化目的时钟的采样沿要么稳稳采到0要么稳稳采到1不存在“采到一半”的情况。门级仿真就开始不客气了。源时钟域的信号从0变1不是瞬间完成的在网表里它要经过若干级逻辑每个节点都有延迟信号翻转其实是一个时间窗口。如果目的时钟域的采样沿正好落在这个翻转窗口内第一级触发器会同时看到“旧值正在消失、新值正在出现”内存库单元仿真模型就会输出X或者一个亚稳态标记。第二级触发器接着采样这个X出来的还是X然后X顺着同步器后面的逻辑一路扩散。这个场景我印象最深的是某个项目中一个红外遥控接收模块源时钟域是慢速外部时钟目的时钟域是高频系统时钟单bit数据只跨一次域。RTL仿真跑了几个星期都没问题后仿随机回归偶尔会挂挂的时候全是同一个笼子同步器输出为X然后整个解码状态机进了illegal state。2.2 为什么只有某些seed才能复现这个现象经常让新人一脸懵代码没改随机种子换一个就全绿换回来又挂。其实原因很简单源时钟和目的时钟频率比通常不是整数两个时钟沿的相对相位会在每个周期里不断滑动。只有当滑动到某个位置让采样沿恰好落入源信号的翻转窗口时竞态才暴露出来。不同seed会改变时钟初始相位、复位释放的微小时间差自然会影响第一个采样沿落在哪里。后仿race问题里这种“偶现”特征很典型。排查的时候不要一上来就去翻大波形先用失败seed跑到X态第一次出现的位置记录首次出现X态的触发器和时间戳。沿着波形往前追一级就能看到那个触发器的数据端在时钟沿附近正在跳变几乎不需要更深层的分析。2.3 定位和处理的完整思路定位的第一步永远是找X态源头而不是去追X扩散后的下游。门级仿真器一般会把X态通过单向追踪打出来如果没有这个选项就在波形上使用向后追踪功能一级一级找。找到第一级同步器之后对比源时钟域的信号翻转点和目的时钟域采样沿的距离就能实锤。处理方案看信号类型如果跨的是脉冲信号两级同步器本来就不够脉冲可能被直接采丢或采成两拍必须用脉冲同步器或者先转电平再跨域如果是电平信号确保源信号在目的域至少保持两个目的时钟周期以上如果跨的是多bit数据总线那根本不是同步器能搞定的得换握手协议或者异步FIFO来保证整体一致性。仿真层面也有辅助手段。一种是在两个时钟域边界加上CDC断言监测源信号翻转时刻与目的域时钟沿的距离另一种是保留X态传播让问题提前暴露不要一上来就开“X态压缩”之类的选项把它压住。压住X态只是让仿真结果变好看芯片该出问题照样出。3. 组合逻辑延迟失配写使能路上的毛刺把寄存器“闪”了一下3.1 数据和使能抢跑的两种形态这个场景在处理寄存器堆和SRAM接口验证时特别常见。结构上往往是写数据走一条长数据通路写使能走一条短控制路径两条路径在寄存器堆的输入端汇合。后仿真一跑使能信号通常先到数据信号还在路上于是写使能有效的那一拍寄存器采到的是上个周期的旧数据或者中间态数据。反过来还有另一种形态使能信号本身是组合逻辑产生的而组合逻辑的多个输入到达时间不一样输出端会在真正到稳态之前先闪出一个毛刺。如果这个毛刺的宽度刚好够寄存器触发寄存器就会在一个本不该写入的时刻被“闪”一下写入一个随机值。RTL里为什么看不出来因为零延迟仿真里组合逻辑的输出会在同一个仿真时间片内立刻变到最终值中间状态不会被采样到。到了门级每个逻辑门都有惯性延迟信号到达时间参差不齐毛刺变成一个真实存在的时间窗口后仿模型就会把它们忠实地呈现出来。3.2 怎么从波形里快速锁定这种问题看波形有个比较直接的特征写使能沿之后数据总线还没有稳定或者反过来数据稳定之前使能就已经抬起来了。把数据总线和写使能放在同一视图中加上时钟沿标尺观察它们之间的相对时间。特别注意写使能上是否存在窄于寄存器最小脉宽的脉冲这种窄脉冲是毛刺最典型的证据。也可以用断言来抓。如果设计里有寄存器写使能信号在验证环境里加一个最小脉宽检查比如property p_min_pulse_width(sig, clk, width); (posedge clk) disable iff (!rst_n) $rose(sig) | $stable(sig)[*width]; endproperty不过这种断言在RTL仿真里大概率不会触发因为毛刺不存在真正起作用的是在后仿里跑回归的时候打开对应checker一旦出现就打印现场把时间戳和信号值记录下来。3.3 修复到底该改哪里这个问题的修复责任一般在前端。最可靠的办法是在组合路径末端插入一级触发器把控制信号和数据的生成边界对齐也就是常说的“控制逻辑打一拍”。寄存器堆的写使能最好来自同步状态机的输出而不是实时译码产生的组合逻辑。如果前端结构已经定死只能靠后端去处理路径延迟差。常见的做法是通过useful skew调整时钟到达寄存器的时间让数据路径有足够余量。作为验证工程师在这个阶段能做的事情是把race点精确定位并报告给后端工程师包括是哪两条路径在竞争、各自延迟是多少、后仿里的违例时间是多少。报告越具体后端越容易动手。这里还有一个经验不要看到后仿X态就想通过改testbench去“修”比如故意把写数据和使能的相对时序在tb里拉开。你只是在掩盖设计问题跑完了表面上全绿投片后照样挂。4. 三态总线方向切换时的双向驱动“抢方向盘”4.1 总线上一瞬间出现了两个司机三态总线在芯片内部总线和IO管脚上都很常见多个master共享一条总线谁把enable拉高谁就驱动总线。正常情况下总线方向切换要求break-before-make也就是旧master先把enable撤掉总线回到高阻然后新master再拉enable开始驱动中间必须有一个死区。但这个死区并不是天然存在的。旧master的enable撤掉信号和新master的enable拉起信号各自经过不同的控制路径和驱动逻辑后仿真里它们到达总线的时间可能发生颠倒旧信号还没撤完新信号已经拉起来了于是总线上两个驱动同时有效总线被两个源同时驱动结果就是X态或者不确定值。RTL仿真里同样不容易看到问题因为在零延迟条件下同一个时钟沿的两个enable信号在同一仿真时刻翻转仿真器会按照某种确定的调度顺序来处理不产生冲突窗口。门级仿真里每个enable的上升沿和下降沿真实地错开了冲突窗口才浮现出来。4.2 定位时先看“enable对”再看总线值排查这种问题不要直接盯着总线X态看先把总线上所有三态门的enable信号找出来按“切换前驱动方”和“切换后驱动方”组成一对同时拉到波形视图里。在方向切换时刻如果两个enable同时为高哪怕只持续几百皮秒就是冲突点。有些商用仿真器会在日志里直接打印总线竞争警告比如“BUS CONTENTION”或者类似关键字找到警告的位置基本上就定位了。如果没有这类报告可以在验证环境里写一个总线monitor对总线上每个驱动方的enable计数当计数器大于1时就打印警告。这个方法在IO验证里尤其好使因为IO pad模型的驱动和enable时序往往比内部逻辑更复杂。4.3 死区时间靠协议修不靠仿真器忍修复的核心是在总线切换协议里强制插入死区。仲裁状态机在切换master时必须先让旧master进入高阻态等一定的空闲周期再让新master开启驱动。这个死区时间要大于后端可能造成的最大enable延迟差一般至少留一个时钟周期有些高速总线上甚至要留两个以上。后仿层面还有一个常见处理办法在内存库中给三态门模型增加不同步的开启和关断延迟比如把turn-off delay设置得比turn-on delay长这样仿真时可以模拟一个安全死区。但这么做要非常小心它只是让仿真环境更接近理想协议真实芯片的延迟偏差还是要靠设计上的死区来吸收。我见过最棘手的一次是三态总线问题不是出在内部逻辑而是出在IO pad的输入输出方向控制信号上。方向控制脚内部被多级缓冲后延迟严重外部设备在方向切换后立刻驱动总线和芯片内部还没完全撤掉的驱动产生了重叠窗口。最后是给方向切换状态机单独加了一拍等待同时后端对方向控制路径做了重新布线才收敛。5. 实战习惯让竞态在后仿阶段少出现、快定位5.1 后仿一挂先审查测试平台再追设计做后仿验证这几年我养成的第一个习惯就是仿真挂掉之后绝不先怀疑设计而是先把测试平台的激励生成方式检查一遍。很多后仿race其实是testbench自己制造出来的。最典型的坑是tb里用无延迟赋值去驱动异步复位、使能信号或者手动注入错误数据。RTL仿真时这些信号和时钟沿的距离是“假的近”还是“真的远”根本测不出来但进了门级仿真无延迟赋值配合SDF反标会产生各种delta cycle竞态。建议tb里所有关键控制信号都用带延迟的赋值方式产生比如在复位释放、总线方向切换这些敏感动作上统一加一个相对时钟沿足够远的偏移量。判断是tb问题还是设计问题有一个简单方法把SDF反标去掉只跑门级功能仿真。如果去掉SDF后问题消失说明问题确实和延迟有关如果去掉SDF还在那多半是tb逻辑错误或设计功能问题和race无关。5.2 用短回归把“偶现”变成“必现”后仿race普遍具备偶发性随机seed换一下就可能消失。这种情况下最忌讳的是反复换seed去“碰运气”求全绿。正确做法是保存失败的seed然后不断缩短仿真时间范围找到能让X态重现的最短序列。最短序列往往一眼就能看出问题远比在几个小时的仿真波形里翻来得高效。同时配合断言使用。在复位释放路径、跨时钟域边界、总线驱动切换这些容易出race的位置都布上断言和monitor后仿跑挂时直接把断言打印信息作为第一手线索通常能在几分钟内把问题缩小到具体模块。还有一个技巧是看仿真日志里有没有setup/hold violation、bus contention之类的警告。很多人觉得这些警告是仿真器的“正常噪音”直接忽略但后仿里每一个时序违例都可能是竞态的源头。至少要把这些警告统计出来逐个判断是可忽略的伪路径还是真实的race点。5.3 竞态修复后的回归纪律竞态修复完成之后不能只拿原来失败的seed跑一遍就收工。因为race问题和随机相位强相关一个seed过了不代表所有相位都安全。建议用同一个用例连续跑几十个不同seed并随机扰动时钟初始相位、复位释放时间点确认问题没有在其他相位关系下复发。后仿race往往牵一发而动全身修复复位同步器可能影响所有异步逻辑的时序修改总线死区可能影响仲裁延时。所以每一笔修复之后除了目标用例相关联的功能用例也至少要回归一遍。最后说一个工作习惯每次定位完一个后仿race我都会把波形截图、根因分析、修复方案和涉及的信号名整理成一个简短的记录。这个习惯救过我很多次因为race问题高度相似下一颗芯片遇到同类问题时翻出之前的记录就能直接照方抓药省掉大量重复排查时间。做后仿真验证本质上就是在和各种“隐秘的时序竞争”打交道把每个案例沉淀下来比临时抱佛脚去翻几百M的波形要踏实得多。