令人痛苦的X！为什么调试X那么困难？

造成调试困难的因素有很多，其中包括取值未知（“X”）的情况。X是VHDL、Verilog、SystemVerilog等语言标准所定义的众多逻辑值之一，可以代表1、0或Z，也就是说X的值是未知的，从而能够预示设计或验证环境逻辑仿真中逻辑信号的不确定性。让事情变得更加复杂的是，在RTL和Gate仿真中，X的不确定性是各有不同。默认情况下，RTL逻辑仿真器的处理方式较为乐观，也就是允许X在逻辑上被阻塞。举一个比较典型的例子，多路复用器的选择信号具有X值时，这个X值是否会被传播取决于其建模方式。具体请参阅下表。

▲ 图1 该表格最初发表于一篇题为“I’m Still In Love with My X!”的DVCon 2013会议论文，作者是Sutherland HDL。

请重点留意在建模中如何确定仿真器是否允许多路复用器传递0、1或X值。请注意，在实际芯片中，信号值始终为1（高电压）或0（低电压）。

那么，为什么要关注这种乐观的处理方式呢？

乐观的处理方式可能隐藏着一些潜在的设计缺陷。在上述表格中，如果Sel输入未连接，则芯片电路的行为将变得不可预测。如果预计输出为1，但出现的是0，则实际的芯片电路可能不稳定，需要重置多次才能获得所需的值1。

门级仿真倾向于在逻辑单元中使用支持传递X值的机制（或逻辑表），因此与芯片值的相关性更大。X值的传播让用户能够在制造芯片之前发现一些不良行为。

除了像RTL仿真中那样因较乐观的传播行为而阻塞X值之外，还存在一些场景，其中X值不应该被传播。就拿下图这个简单的例子来说：

无论模块A输出端的X值如何，逻辑本身应始终在与门（AND）的输出端生成0。在这种情况下，逻辑结构的建模/仿真处理就过于悲观了。虽然在这种逻辑结构的输出端上调试X值对于开发者来说有点浪费时间，但对这种设计结构类型加以了解将十分受用。

为什么很X难调试？

无论X在RTL或门级仿真中如何传播，几乎所有X都难以进行调试。为什么会这样？首先，产生X的根本原因或来源可能有很多。例如，某个逻辑门具有X输入（非驱动）；存储器或触发器未初始化为已知值；或是触发器违反了建立时间或保持时间的规定，都有可能产生X。下图是一个简单的例子：就像这个与门，有一个X和同时有多个X的情况都很常见。输入端i1和i2上的X导致输出端o1输出X。

当输入端出现多个X时，用户需要选择其中一个作为调试X的起点，然后反复回溯到所关注信号的驱动源或扇入信号，直到能够找出最早出现的X值或根本原因。而当所关注的信号或根本原因信号不是造成X值的唯一原因时，用户需要选择另一输入X来追踪其根本原因。找到的第二个根本原因可能与前一个错误的根本原因相同，也可能是另一个来源。这是造成X难以调试且费时费力的关键原因之一。

此外，X通常要在设计中传播数千个RTL语句或门级逻辑，才能到达观察点、调试入口点或输出端口。当然，这要取决于具体部署的环境类型、模块级别、芯片级别或SoC。单个根本原因也可能传播到多个观察点。此外，这些根本原因和观察点的逻辑锥可能交织在一起。各种因素盘根错节，使得追踪X难上加难。下图说明了X态传播和输出端上X重叠的概念。输出Z1仅接收到输入A，输出Z3仅接收到输入B，但输出Z2却能接收到输入A和输入B。

这个追踪过程需要多次迭代操作，非常繁琐。此外，还需要了解来源/根本原因的类型。例如，系统可能有意设置了一个尚未重置或赋值的内存数组，而某个地址可能错误地指向了这个未初始化的数组。所以追踪这个数组并理解这个地址的逻辑也非常关键。话虽如此，是否有一种方法可以自动追踪X的根本原因，并且在确定了根本原因后，对这些X进行分类或解释原由？这种自动化将大大节省开发工作量，并大幅提升开发者的工作效率。