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 <xprop.log>
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
***摘自 赛宝龙 ***
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)。
上述功能可归为两个方面
- model checking: 属于logical properties逻辑属性检查, 如FCA, 形式验证会穷尽遍历RTL,对于RTL中不可能达到的代码,会自动报出。相比于动态仿真收集代码覆盖率,可以提前发现代码的冗余。VC Formal中的大部分功能都是model checking类型。
- 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
的代码。
参考文档
- The Dangers of Living with an X (bugs hidden in your Verilog)
- VCS UserGuide Using X-Propagation Part
- I’m Still In Love With My X! 此链接地址失效!… 貌似又有效了。。。。
- I’m Still In Love With My X! 增加链接
————————————————
版权声明:本文为CSDN博主「劲仔小鱼」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/Holden_Liu/article/details/117065321