X态详解 与 X态传播 VCS X-Propagation

Verilog作为硬件行为级描述语言，提供了四种状态来模拟实际电路的电平状态，1，0，x，z

在整个设计流程，包含了Simulation,Formal Verification,Equivalence Checking,Synthesis,Code Coverage,Power State等不同阶段或概念，X态在不同context（上下文/语境）下也存在不同的semantics语义。

Synthesis Semantics

在逻辑综合时，X态常被看作是一种“无所谓"的赋值，don't-care X-assignment。
综合工具会忽略掉X-assignment，对RTL的逻辑功能进行优化（Minimization Optimization）。
DC的逻辑综合与优化

Simulation Semantics

在RTL功能仿真时，X态表示unkonw，高低电平不确定的状态。
Verilog作为行为级描述语言，对于X态的propagate传播处理，是偏optimistic乐观的。
在Verilog协议对X态的布尔操作规定如下：

X-Optimism乐观和X-Pessimism悲观相对应，X-Propagation传播和X-Termination终止相对应。

这里的悲观和乐观，是仿真时对于X态的传播而言，当倾向于传播X态时偏悲观，倾向于终止X态时偏乐观。
assign b = a & ~a这个示例就是一个X-Pessimism，根据布尔代数，b为0。但是当a = x时，~a = x，b = x & x，b = x。

VCS仿真器对于RTL仿真提供了支持X-Propagation的功能，因为RTL仿真偏乐观(相对于Gate-level仿真而言，但是也有悲观的情况，如上个示例)，一些X态传播的bug无法在正常的RTL仿真阶段发现，但是在Gate-level仿真时会被捕获到，Gate-level仿真也更接近实际硬件行为。越早的发现bug，消耗的成本也越低，VCS的X-Propagation功能可以提供更接近Gate-level的X态传播行为，及早发现bug，也就是Shift-Left验证左移的理念。
三种模式：
vmerge mode: 就是Verilog/VHDL协议规定的X态处理行为；
tmerge mode: 更接近Gate-level仿真，也就是实际硬件行为；
xmerge mode: 相比tmerge mode，对于X态的处理更悲观；
命令：vcs ‑xprop[=tmerge|xmerge|xprop_config_file] -xproplog

If Statement

从真值表中可以看到，vmerge mode对s =x的处理是偏乐观的，无论a b为何时，都不会将X态传播给r。tmerge mode更接近真实硬件行为，虽然在真实硬件中并不存在X态，r不会是x，只会是0 1中的一种可能，但是将x传播给r，并作用于后级电路，更利与将可能隐藏的问题暴露出来。xmerge mode则当s=x时，默认无法进行逻辑判断，使得r=x。

Case Statement

vmerge mode中，s = x, r保持上一次case statement执行的结果不变。

Edge Sensitive Expression

在标准的Verilog RTL仿真时，一个上升沿除了会被0 -> 1变化触发外，也会在0 -> X, 0 -> Z, X -> 1, Z -> 1的条件下触发!
tmerge mode下，q端的结果是当前拍d端和上一拍q端值得merge结果，如果两者不同，则当前拍锁存x。

Latch

***摘自 赛宝龙 ***

Simulation Semantics: use casex and casez

RTL中使用casex casez,真值表如下：（纵列为case-item，横列为case-expression)

从上表可以看出，X或Z对于casex和Z对于casez就像一个通配符wildcard一样，既可以匹配0也可以匹配1。也可以使用?替换z。

如上

• RTL仿真会考虑每一个条件，综合器只会考虑中间两个条件(don’t care)
• case语句等价于套嵌的if语句，每个case-item是有优先级的
• case-expression与case-item匹配，是===全等，而不是==相等
• 在sel = z时命中default条件
• 如果case-item中没有显示列出x，则当case-expression为x时，命中default条件
  
  如上：
  如果使用casex，1'bx在任何情况下都会命中。综合器会当作一个简单的assign语句来处理，2'bXX对于综合器don't care。
  conding style建议不要使用casex，避免使用casez，并附带default条件。

Power Down

包含低功耗设计的仿真中，如果power domain掉电，内部逻辑会呈X态。分为以下几种情况：

• RTL with UPF sim: VCS Native Low Power支持RTL with UPF仿真，可以插入虚拟power cell模拟掉电上电行为。当逻辑掉电后，信号为X态。如果配合Verdi Power Aware使用，在波形dump中加入power信息，则可以从波形上区分X态是由掉电引起还是未初始化等其他原因引起。
• Netlist with PG pin sim: 对于带PG(Power Ground Pin)的仿真，Netlist中包含power cell, std cell包含PG pin。逻辑掉电时，std cell会判断PG pin的状态，赋值为X，模拟掉电行为。
  带PG pin的std cell多了VDD VSS VBP VBN四个PG pin，下电条件下通过三态门bufif1驱动x态，上电则正常导通，来模拟电源行为：

Equivalence Checking

equivalence checking等价性检查是static/formal静态/形式验证工具提供的一种功能。

SNPS将涉及芯片验证的工具都归类于VC platform中，VC指Verification Continuum，在有些地方也指Verification Compiler（DC逻辑综合，ICC布局布线，FC Fusion Compiler融合综合和布局布线）。

VC platform涵盖了Prototyping原型验证，Simulation仿真，Static/Formal静态形式验证，Emulation硬件加速，UPF低功耗验证，FPGA验证，各种VIP, VCS仿真工具，Sypglass静态检查，Verdidebug工具，UVM平台搭建，验证计划制定，覆盖率收集等各个方面。

SpyGlass静态检查工具，提供CDC RDC Lint等功能。VC platform中集成了VC SpyGlass，提供了VC SpyGlass CDC,VC SpyGlass RDC,VC SpyGlass Lint工具。

等价性检查分为三种：
1：Transaction Equivalence (Hector)

VC Formal Data Path Validation (DPV)用于 C/C++ model和RTL之间的等价性检查，基于transaction的对比（和UVM中的transaction类似，抽象级的inputs/outputs集合）。适用于CPU, GPU , AI/ML产品中包含大量point/integer adder, multiplier, divider, multiplication accumulate运算单元的数据通路的算法类设计。
2：Sequential Equivalence(SEQ)

SEQ时序等效性检查是VC Formal工具所提供的一种功能，用于RTL vs RTL 每一个拍的等价检测。和Systemverilog Assertion类似，属于property verfication，和sequential时序相关，对每一拍的结果都会做assert断言。适用于对原有block级RTL做了非逻辑修改，如Clock/power gating，对修改后的RTL进行等价检查。
VC Formal除了SEQ，还提供了其他的形式验证APP，包含属性验证 (FPV)、自动提取属性 (AEP)、覆盖分析器 (FCA)、连接性检查 (CC)、 寄存器验证 (FRV)、测试平台分析仪 (FTA)、形式导航器 (NAV) 以及用于验证标准总线协议的一组断言 IP (AIP）。

上述功能可归为两个方面

1. model checking: 属于logical properties逻辑属性检查， 如FCA, 形式验证会穷尽遍历RTL，对于RTL中不可能达到的代码，会自动报出。相比于动态仿真收集代码覆盖率，可以提前发现代码的冗余。VC Fromal中的大部分功能都是model checking类型。
2. equivalence checking: 属于logical functions逻辑功能检查，如SEQ（SEQ也包含部分logical properties，因为具备时间属性，而下面提到的Formality则是纯logical functions的equivalence checker）。

3. Combinational Equivalence(Formality)

combinational equivalence组合等价检查工具Formality（不属于VC platform，一个单独的sign off工具）用于逻辑功能的equivalence checking。
Formality将Reference design和Implementation design做比较，比较点为primary outputs, internal registers, black box input pins, or nets driven by multiple drivers where at least one driver is a port or black box.
这里有一个Logic Cones逻辑锥的概念：
Formality采用数学方法，穷举Inputs，对比Reference design和Implementation design中的Output.

Formality不可以检查时序属性（SEQ可以），但是可以检查Sequential elements时序元素，如internal register。设计中的寄存器的input由每一个逻辑锥驱动，Formality会检查每个寄存器的inputs，但是寄存器的锁存值不会检查，可以是1或0。因为寄存器的outputs就是逻辑锥的inputs,inputs会遍历0,1。

Formality可用于RTL vs Synthesis Netlist, Netlist VS Netlist with Scan-chain, Netlist VS Netlist with Power-Cell等不同阶段equivalence checking。
逻辑综合netlist，floorplan netlist，placement netlist ，CTSinserted netlist,P&R netlist，在每一个步骤后都有新的逻辑加入到netlist中，但是这个新的逻辑的加入不能改变之前netlist的功能。

形式验证工具采用数学穷举方式，对于逻辑锥的input,都会遍历0,1 2-state两种情况。
X态在Formality中有两种模式：

• 2-State Consistency
  Formality默认模式，X态don't care,只要Implementation design在X=0或者X=1中有一种同Reference design逻辑功能一致，就算通过一致性检查。
• 2-State Equality
  相比上一种模式，更佳严格，需要同时考虑X=0，X=1两种条件(仅在RTL vs Netlist情况下，Netlist vs Netlist中，Netlist没有X-assignments)。

X态在SEQ中：

• 2-State Sequential
  X态在SEQ中相对于Formality不同，Formality只对比内部寄存器的inputs，寄存器不会锁存X态。SEQ会考虑锁存在寄存器中的X态和寄存器输出X态，此时可以用来验证设计的复位正确定或电路完备性。
  将两份相同的RTL（RTL中默认都是包含复位的寄存器）做对比，未初始化的寄存器处于X态，如果两份RTL outputs不一致，发生X态传播，说明复位不正确或电路不完备。
  

Bugs Missed by RTL Simulations

Latch Behavior in RTL Simulation

没有default条件，在RTL仿真中发生锁存，o1一直为1。与Gate Sim行为不一致。

Optimistic X Semantics in RTL Simulation

RTL与Gate Sim仿真结果不一致，当X态传播到o1时，RTL中的if条件false，o2=i2。o2可以发生toggle。
在Gate Sim中，X态被当作don't care处理，有50%的概率o2一直保持为0。导致在RTL sim中可以通过的case无法在Gate Sim中通过。

Bugs Missed by Equivalence Checking

2-State Consistency can miss RTL vs.Netlist Simulation differences

在RTL sim和Netlist sim中，i1=0, i2=1时，结果不一致。
使用Formality一致性检查，2-State Consistency模式下无法发现不一致，因为X态在RTL中被当作don't care处理，而RTL sim中X态被当作Unknow处理。但是在2-State Equality模式下，可以发现隐藏的错误，X=1,X=0两种情况都被遍历。

Sequential Differences missed if X’s stored in Registers

如何，RTL sim命中第四个case-item, Gate Sim命中default条件。Synthesis时X态don't care,会被优化为0或者1来处理。
使用Formality进行等价检查：（check point是DFF的input aData，组合逻辑的outputs o1)

• 2-State Consistency: 100%一致
• 2-State Consistency: 67%不一致，aData[5:0]不一致。但是RTL vs Netlist中的o1确一致，和RTL sim VS Gate Sim结果不一致 。因为等价检查工具把X态当作2-state处理，而RTL的casex把X态当作wildcard处理。

Misleading Code Coverage

如上：RTL sim收集的代码覆盖率和Formal tool遍历的代码覆盖率结果不一致

• 无论 i1=0 i1=1,中间两个条件都无法覆盖到。因为 RTL语法规定~x=x if(x) = false。
• 使用VC Formal中的覆盖分析器 (FCA)，会将X态当作2-state处理，可以发现最后一个条件为deadcode

对于don't care X-assignments,如果是reachable的，如示例中的w1 = i1 ? 1'b1 : 1'bx，需要谨慎使用。这会在RTL sim 和 Netlist sim中引发歧义，也会被等价检查工具误解。所以对于reachable don't care X-assignments，应该赋一个固定值。对于unreachable don't care X-assignments，则可以保留，如case语句中的case-item枚举完备，也可以加上default赋值为X的冗余条件，将X态传播出去，最终综合结果保持不变。但是覆盖率收集时，default为hole。

VC formal AEP 提供X_assignment reachability的检测，在$VC_STATIC_HOME/doc/vcst/examples/AEP中的demo示例，会报出reachable X-assignment的代码。

参考文档

1. The Dangers of Living with an X (bugs hidden in your Verilog)
2. VCS UserGuide Using X-Propagation Part
3. I’m Still In Love With My X! 此链接地址失效！… 貌似又有效了。。。。
4. I’m Still In Love With My X! 增加链接