X 态及基于 VCS 的 X-Propagation 检测

---

点击查看精选 IC 技能树系列文章
点击进入【芯片设计验证】社区，查看更多精彩内容

---

 声明：

• 作者主页：【MangoPapa的CSDN主页】。
• ⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/129996971】。
• ⚠️ 本文目的为 个人学习记录 及 知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
• ⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
• 欢迎大家指出文章错误，欢迎同行与我交流 ~
• 邮箱：[email protected]
• 直达博主：loveic_lovelife 。（搜索或点击扫码）

---

---

前言

   简单记录下数字 IC 中的 X 态 (不定态) 相关问题，包括 X 态的概念、出现原因、对待 X 态的观念、vcs xprop 仿真、Debug 等等。以下讨论涉及的设计代码仅限 Verilog 及 SV，不针对 VHDL 进行讨论。

---

1. X 态是什么？

---

  Verilog 和 SV 定义了四种逻辑状态：0，1，Z 及 X：

• 0 为低电平；
• 1 为高电平；
• Z 为高阻态，可以理解为电路上的引脚悬空；
• X 为不定态、亚稳态，可能为 0 可能为 1 也可能为 Z，常见于未复位的寄存器、锁存器或 Memory。

  其中，X 只有在仿真时存在，真实电路中不存在。若仿真过程中出现了 X 态，表明该处存在潜在的设计风险，其有可能会掩盖 RTL Bug。

---

2. X 态是由什么引起的？

---

  RTL 仿真、门仿真及低功耗仿真中均有可能出现 X 态。X 态出现的原因大致总结如下：

• 未初始化。未初始化的四态变量，比如 logic、wire、reg、integer、time 变量；未初始化的寄存器、锁存器，在被复位或有确定的值被锁定之前，保持 X 态。
• 输入信号未连接。外部输入信号未设置初值（尤其 DFT 信号）时为 Z，Z 在模块内部经过数字逻辑后变 X 态。
• 信号多驱或总线争用。SV 中允许将多个输入驱动到同一 net 类型上，多多个驱动存在冲突时，net 即表现为 X 态。
• 操作结果不定导致的 X 态。
• 位选择或数组索引超范围返回 X 态。
• 逻辑门输出的 X 态。SV 自带原语或用户自定义原语 (UDP) 支持四态操作，当这些逻辑门输入为 X 或 Z 时，输出 X。
• 后仿 setup 或 hold time 不满足，存在 timing violation，使用 notifier 将输出变为 X 态。若只看 timing violation 不输出 X，则添加 vcs 编译选项 +no_notifier。
• 主动引入的 X 态。设计人为引入的 X 态，比如在 case 分支中，对于 don’t care 的默认状态中赋值为 X 态；验证平台引入的 X 态，比如存在四态变量 wire a， assign a = ‘bx。
• 寄存器或锁存器掉电后上电。在低功耗仿真中，若无特别设置，即便在 0 时刻对寄存器或锁存器进行了初始化，当其所在的 Power Domain 掉电后重新上电，其仍然为 X 态未初始化状态，需要在 upf 中设置 reinit。

  若 RTL 仿真没问题，但门仿出现 X 态，可能为以下原因：

• 信号的输入输出方向声明错误
• 控制信号出现 X 态

---

3. X 态有什么危害？

---

  所谓 X 态传播，是指 X 态作为触发/控制条件或逻辑输入时，引起其他逻辑输出为 X 态。不同情况下 X 态危害情况不同：

• 若 X 态仅仅是存在，完全不传播，其没什么危害；
• 若 X 态出现传播，且电路中针对该 X 态传播做了保护，这种有限的 X 态传播也没有危害；
• 若 X 态出现传播但电路中针没有针对该 X 态传播进行保护，那么该 X 态传播可能会影响到芯片的正常工作。

---

4. 如何避免 X 态的产生？

---

  确保引起 X 态的条件不成立即可避免 X 态产生，简单列几条：

• 使用二态变量。
• 设计上进行复位操作，控制通路寄存器必选带复位，数据通路寄存器可以不带复位。
• 验证 TB 中接口输入信号赋初值。
• 仿真时利用 initreg 及 initmem 选项对 reg 和 Memory 进行初始化。
• RTL model 中添加针对 X 的 assertion，以及时发现 X 态并消除。
• if-else 及 case 中使用确定写法，或使用 assign+表达式代替if-else及 case。

4.1 if-else/case Vs. assign

  RTL 仿真中，if-else/case 及 assign 对 X 态有不同的行为，如下：

• if(x) 会默认 x=0，走 else 分支，不传播 X 态。
• case(x)，若存在 default 分支，则走 default 分支，否则不会匹配到任何分支。
• assign c = sel ? a : b; sel=x，输出 X，从而将 X 态传播出去。

  也就是说，if-else 和 case 不能传递 X 态，无法暴露 X 态传播问题，这就导致无法在仿真时去发现 X 态相关的 Bug。相比之下，assign + 条件表达式的方式能够传递 X 态。此外，if-else/case 为带有优先级的选择电路，不利于时序和面积，建议使用 assign 代替 if-else 和 case。

  有人有疑问：if-else/case 不传播 X 态，assign 传播 X 态，为什么还要用 assign?——我们不希望出现 X 态，但我们更不希望由于 RTL 写法原因而掩盖 X 态。使用 assign，能够及时暴露 X 态问题，从而避免 X 态被掩盖所导致的问题。

---

5. 两种 X 态模型：X-optimism 和 X-pessimism

---

  在对待 X 态问题上有两种模型：

• X-optimism，乐观派，其认为 X 态不会被传播。若检测到逻辑输出为 X 态，将 X 转换为 0 或 1。
• X-pessimism，悲观派，其认为 X 态会一直被传播下去。若检测到逻辑输入存在 X，即便输出结果是确定的，也要输出 X，从而将 X 态传播出去。

  在仿真阶段，RTL 仿真对 X 态过于乐观，RTL 仿真时往往忽略 X 态并赋一个确定的值，从而无法检测到 X 态传播所引发的问题；门仿更接近硬件行为，会暴露出 X 传播问题。

---

6. 如何检测 X 态传播？

---

  从设计角度，我们希望电路的逻辑输出都是确定的，以避免非预期的功能缺陷。从验证角度，我们不喜欢 X 态，但我们希望能够发现并评估电路中所有可能存在的 X 态，尤其是能够传播的 X 态。

  前文提到，RTL 仿真往往对 X 态过于乐观，在门仿阶段才会暴露出 X 态传播问题。相较于 RTL 仿真，门仿的 netlist 易读性差、仿真速度慢且难以 Debug。鉴于此，vcs 提供了一种 Shift-Left 方案，通过在编译仿真选项中添加 -xprop 相关选项即可在 RTL 仿真阶段对 X 传播进行检查。

6.1 Merge Mode 介绍

  vcs xprop 检查有 3 种模式，按照从乐观到悲观的顺序，分别为：vmerge -> tmerge -> xmerge。其中：

• vmerge mode，对待 X 态最为乐观，遵守 Verilog 或 VHDL 规定的 X 态处理规则，不存在 X 态传播问题。
• tmerge mode，处于乐观与悲观之间，接近实际硬件行为或门仿，X 态传播一段路径后终结。
• xmerge mode，对待 X 态最为悲观，比门仿还悲观，X 态会一直传播下去。

  不同 Merge Mode 时的 X 态传播情况如下表所示：

	逻辑代码	逻辑输出真值表
if-else	always@*  if(s)   r = a;  else   r = b;
case	case (s)  1’b0: r = a;   1’b1: r = b; endcase
edge sensitive	always@(posedge clk, negedge rst)   if (! rst)    q <= 1’b0;  else    q <= d;
latch	always@(*)   if(g)    q <= d;

  说到底，-xprop=tmerge/vmerge 是为了扩散 X 态传播，把不传播不定态的情形，强制传播出去，从而尽早暴露 bug。

6.2 xprop 命令使用

  一般来讲，可以在编译或仿真任一阶段指定 -xprop 选项即可开启 xprop 检测。-xprop 示例用法如下：

vcs ‑xprop[=tmerge|xmerge|xprop_config_file]

。其中，xprop_config_file 用以针对特定 instance 进行特定模式的 xprop 监测或开关特定 instance 的 xprop 检测，其示例用法如下：

tree        {top}
instance {top.A} {xpropOn};
instance {top.B} {xpropOff};
module   {C} {xpropOff};
merge = tmerge;

  使能 xprop 后发现的 X 态不一定都是 Bug，或者设计已经针对 xprop 做了保护。这种情况下，可以采用 -xprop=xprop_config_file 对不同模块施以不同的 xprop mode。

注意事项

• -xprop 一般不能跟 +vcs+initreg+0/1/random 同时使用，因为 +vcs+initreg+0/1/random 会把 Verilog 的变量、寄存器及 Memory 初始值设置为 0 或 1 等非 X 状态，这样就测不到初始 X 态了。
• 若未指定 -xprop，默认为 vmerge，即默认不存在 X 态传播问题，也不进行检查。
• 若定义了 -xprop 但未指定具体模式，默认为 tmerge，即采用接近真实电路的 X 态传播模式并进行检查。

6.3 xprop 报告查看

  vcs 在编译、仿真两个阶段均提供了相关手段来检查相关 instance 的 xprop 开关情况：

• 若在编译阶段使能了 xprop，编译完成之后会生成一个 xprop.log 来报告 if/case 状态、always 边沿触发等条件的 xprop 检查开关情况。
• simv 仿真阶段添加仿真选项 -report=xprop[+exit] 能生成 xprop_config.report，便于在仿真后对 xprop 检查情况进行确认。若采用 -report=xprop+exit，在检测完 xprop 状态情况后后立即终止仿真。

---

7. 什么阶段进行 xprop 检测？

---

  X 态传播不能不做，但也不宜早做。一方面，在验证初期调 datapath 或 sanity 期间，我们并不想看到太多 X 态传播，我们希望对待 X 态传播更乐观一点；另一方面，带有 xprop 的仿真为 4 态仿真，毫无疑问，4 态仿真比不带 xprop 的 2 态仿真更慢。

  那么应该在什么阶段开启 xprop 检测呢？以下是推荐的方案：

• RTL 仿真前期不开启 xprop，以尽快调通 sanity/smoke case 及主要 datapath。
• RTL 仿真后期建议开启 xprop，提前排除部分 X 态。

  网表中没有 always 块，xprop 对门仿不起作用。门仿的一大作用就是排除 X 态传播导致的芯片功能问题，尤其是控制通路上的 X 态传播。

---

8. 如何用 Verdi Trace X？Trace 到什么地方停止？

---

  我们说的 Trace X 是指追踪 X 态产生的源头。利用 Verdi 能够自动追踪组合逻辑、锁存器、触发器等的 X 态传播的源头。Verdi Trace X 有两种途径：一种是在 Verdi GUI 内 Trace，一种是直接利用 Verdi 的 traceX 工具直接 Trace。

8.1 Verdi GUI 内 Trace

  若 X 态出现传播，通常能在波形里找到很多 X 态信号。多个 X 态的源头，此时我们可以选择其中一个信号进行跟踪。

  假设在波形中已经发现了 X 态，该如何 Trace X 呢？两种常用方式：

8.1.1 手动 Trace X

1. 把出现 X 态的信号 A 拖到 nWave 窗口
2. nWave 窗口 Cursor 点在 X 态信号 0/1 -> X 跳变沿的地方
3. 在源代码窗口左键双击该信号 A，追踪其 Driver
4. 检查 A 的 Driver (控制信号、触发条件、逻辑输入等) 是否存在 X 态
5. 重复以上步骤，直到找到 X 态产生的源头

8.1.2 自动 Trace X

1. 把出现 X 态信号 A 拖到 nWave 窗口
2. nWave 窗口Cursor 点在 X 态信号 0/1 -> X 跳变沿的地方
3. nWave 窗口右键单击该信号的波形，或源代码窗口右键单击该信号
4. 选择 Trace X，弹出 Trace X Settings 窗口
5. 窗口勾选所需的 Trace X 相关设置。默认 View Options 为 Flow View，此处我们也可以改为 nWave View
6. 左键单击 Trace，开始 Trace X，Trace 结果一方面显示在 Flow/nWave 窗口内，一方面显示在 tTraceXRst 窗口内（Note 提示 X 的大致出现原因）

8.2 Verdi 的 traceX 工具

  除了在 GUI 内进行 X 态追踪，Verdi 还提供了 traceX 工具来追踪 X 态。traceX 用法如下：

1. 设置变量打开 traceX 工具，setenv VERDI_TRACEX_ENABLE
2. 采用以下命令追踪 X 态
   • 未提供 X 态信号列表：traceX -lca -ssf xxx.fsdb
   • 提供了 X 态信号列表：traceX -lca -ssf xxx.fsdb -signal_file signal.list
   • 若需要手段加载 database，还需要添加选项 -dbdir simv.daidir
3. 查看 trx_report.txt 查看 Trace 结果

---

9. X 态怎么处理？

---

• 如果 X 态没有传播，无需处理。
• 如果 X 态发生传播，但后续有 X 态保护电路，无需处理。
• 如果 X 态发生传播，且后续没有 X 态保护电路，需要从根源上消除 X 态。

---

10. 其他注意事项

• assertion 中应规避 X -> 0/1 形成的跳变沿

---

11. 参考

1. I’m Still In Love with My X
2. X-Propagation : An Alternative to Gate Level Simulation
3. Xprop User Guide
4. 关于X-Propagation问题 – Wenhui’s Rotten Pen
5. ​门级仿真中的X传播现象 - 知乎 (zhihu.com)
6. X态详解与X态传播VCS X-Propagation
7. vcs xprop 仿真的一些理解
8. SystemVerilog and Verilog X Optimism
9. SystemVerilog and Verilog X Optimism – What About X Pessimism?
10. Hardware-like X Propagation with Xprop - Verilog Pro
11. 再见xprop
12. Verilog RTL优化策略（一）：推荐使用assign语法替代if-else和case语法
13. 提高与 X 态相关的仿真和调试的效率
14. 学习一下simulation 仿真中的x态仿真
15. Catching X-propagation related issues at RTL
16. 在Assertion中规避信号从X态到0形成的negedge

---

— END —

---

精选往期 IC 技能树相关博文，请查看【 数字 IC 技能树】专栏

⬆️ 返回顶部 ⬆️