X态是什么？X态有什么危害？如何避免X态的产生？X态怎么处理？

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 态传播情况如下表所示：

说到底，-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

把出现 X 态的信号 A 拖到 nWave 窗口

nWave 窗口 Cursor 点在 X 态信号 0/1 -> X 跳变沿的地方

在源代码窗口左键双击该信号 A，追踪其 Driver

检查 A 的 Driver (控制信号、触发条件、逻辑输入等) 是否存在 X 态

重复以上步骤，直到找到 X 态产生的源头

8.1.2 自动 Trace X

把出现 X 态信号 A 拖到 nWave 窗口

nWave 窗口Cursor 点在 X 态信号 0/1 -> X 跳变沿的地方

nWave 窗口右键单击该信号的波形，或源代码窗口右键单击该信号

选择 Trace X，弹出 Trace X Settings 窗口

窗口勾选所需的 Trace X 相关设置。默认 View Options 为 Flow View，此处我们也可以改为 nWave View

左键单击 Trace，开始 Trace X，Trace 结果一方面显示在 Flow/nWave 窗口内，一方面显示在 tTraceXRst 窗口内（Note 提示 X 的大致出现原因）

8.2 Verdi 的 traceX 工具

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

设置变量打开 traceX 工具，setenv VERDI_TRACEX_ENABLE

采用以下命令追踪 X 态

未提供 X 态信号列表：traceX -lca -ssf xxx.fsdb

提供了 X 态信号列表：traceX -lca -ssf xxx.fsdb -signal_file signal.list若需要手段加载 database，还需要添加选项 -dbdir simv.daidir

查看 trx_report.txt 查看 Trace 结果

9. X 态怎么处理？

如果 X 态没有传播，无需处理。

如果 X 态发生传播，但后续有 X 态保护电路，无需处理。

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

10. 其他注意事项

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

审核编辑：刘清