造成调试困难的因素有很多,其中包括取值未知(“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进行分类或解释原由?这种自动化将大大节省开发工作量,并大幅提升开发者的工作效率。
新思科技Verdi的XRCA组件
新思科技Verdi回归调试自动化的XRCA组件是一种先进的根本原因分析工具,恰好能够满足上述自动化要求。XRCA是追踪X和进行根本原因分析的出色引擎,不仅可以自动扫描FSDB中的X信号并追踪X信号的根本原因,而且可以批量处理大量X信号以缩短调试时间。此外还能生成逻辑清晰的报告,按不同类别列出根本原因。报告会加载到新思科技Verdi的RCA主设备中,以便观察结果和追踪路径。
XRCA是在启动门级仿真和进行回归处理时调试X信号的理想工具。除了许多根本原因分类之外,XRCA还支持门级网表追踪、RTL级追踪、新思科技VCS X态传播追踪、低功耗组件X追踪,以及X值悲观处理检测。
全部0条评论
快来发表一下你的评论吧 !