VCS OBC技术的评估

当前，设计验证已经成为半导体芯片设计过程所面临的主要难题之一。如何确认芯片能够在相关应用中正确运行呢？除了要面对需要写出尽可能多的测试来验证芯片的各方面功能的挑战以外，下列问题也变得日益重要：如何测定这些测试的质量呢？测试包到底覆盖了多大范围的芯片功能呢？对于这些问题，传统的解决方法是应用代码覆盖率分析工具。利用这些工具可以测量出在仿真状态下实际执行了设计的多大部分，并能提供有关代码行覆盖率、条件覆盖率、信号翻转覆盖率的报告。但是，代码覆盖率分析工具所能给出的覆盖率数值在本质上属于乐观性的估计。举例来说，它们可以指出一条代码行得到了执行，但是却不能指出这条代码行上的代码正确性是否得到了验证。因此，有可能出现这种情况，即有报告显示一条代码行已经在仿真状态下得以覆盖，但是由此产生的效果却未在仿真中检查出来，并未检查到这条代码行的错误功能。测试结果可能会显示合格，但却没有察觉到错误的功能行为。
这项挑战可以通过应用VCS 7.0版新增的Observed Coverage (OBC)能力得到解决。这项功能包含在VCS 7.0的测试版中，也正是我们用作OBC评估的版本。

OBC工具
OBC是一项在VCS仿真器内新增加的覆盖率测量工具。OBC是建立在代码行覆盖率分析基础上的，并在其中加入了可观测性的概念：一行代码在已经执行的情况下，而且执行的效果可以传播到观测点，我们就认为这是已经观测的代码行。在缺省情况下，OBC技术把包括在TestBench内最顶层的实例的输出认定为观测点。而且可以将用户设计中的任意信号定义为观测点。
通过加入可观测性的概念，OBC工具纠正了代码覆盖率分析中的乐观估计倾向，所报告覆盖率也更为接近实际的观测结果。OBC工具的能力在于模块的输出可以不必直接与观测点有所连接。这一信号可以首先送入其它模块，随后穿过一些组合逻辑电路，储存在第3个模块的寄存器中，并最终在若干时钟周期后到达观测点。在这种情况下，OBC工具依然能够检测到信号传播链路中起始部分的赋值操作已经被观察到。

未观测到代码行的原因
OBC工具可以识别出8种不同的为何代码行被认定为未观测到的原因。
无扇出(NFO)
在一个模块中未能读取的信号明显地不会被传播到任何观测点。
未执行的读取操作(UXR)
如果一条语句从未得到执行，就可能造成一次本应通过这条语句进行传播到观测点的赋值操作未能执行。
未接线的输出端口(UCP)
如果一个子模块的输出端口未接线，则会成为某个信号无法观测到的明显原因。
赋值操作未改变信号(SUA)
一个信号被赋予了与本身已有值相同的数值时，则此次赋值被认定为是无法观测到的。这时就需要进行另外一次赋值操作，赋予其不同的数值，方能传播到输出处并被认定为已观测到。
赋值次序混乱(AOO)
这种情况经常在若干个赋值操作必须按一定的顺序进行，以达到将某个信号数值传播到某个输出的目标。但是，如果这一特定顺序在仿真过程中从未出现过，则此赋值链会断开，而赋值链的前一部分不认定为已经观测到。
赋值操作不受子表达式数值的影响(AIS)
在诸如x = a & b或x = a | (~b)的赋值操作中，在b的值为零时，a的值是“不关心的”。因此，所有对信号a的赋值均将被认为是未观测到的。
仅用于事件控制(UEC)
内部时钟或复位信号在典型情况下从来不会传播至芯片的输出端。但是，这些信号会触发其它可在观测点观测到的信号的操作。无论在何种情况，OBC工具都不会认定此种时钟和复位信号是可观测到的。
寄存器重写(ROW)
如果某个寄存器数值在此数值传播到观测点前被重写，则产生原来数值的赋值操作被认定为未观测到。

OBC工具的使用
图1是OBC工具运行方式的概述以及报告生成的过程。
运行OBC工具需要3个步骤：
＊编译和在代码中建立相应的观察机制
vcs -cm obc source.v
＊运行仿真并生成一个有关行代码覆盖率和可观测性结果的数据库
simv -cm obc -cm_obc history -cm_name test1
＊在批处理方式下生成报告
obcView -b -cm_name merged
前两个步骤为VCS编译和仿真的标准执行步骤，只包含了有关OBC工具的少数几个开关。最后一个步骤是专用于OBC的，这一步骤中生成若干个有关覆盖率和可观测性的报告文件：
?报告中可提供若干个层次的详细信息：所有代码行，只对未观测到的代码行，或者是对每个模块的一个总结报告。
?每个模块实例生成相应报告，但是如果同一个模块有多个实例，也可针对每一个模块提供一份累计报告。
?一份可用于追溯某一特定代码行被报告为未观测的历史记录报告。

OBC工具的应用
在模块级上应用OBC工具
在模块级上应用代码覆盖率分析工具是最为广泛的应用形式，模块设计人员需要通过它们来确认验证了设计中的所有组成部分。但是，传统的代码覆盖率分析工具在典型情况下所给出的覆盖率结果过于乐观。通过为OBC工具定义合适的观测点后，以这种观测为基础的覆盖率结果有助于查明模块中那些已执行的部分，但其执行代码的正确性可能根本未经这项测试进行验证。在模块级上使用OBC工具的目的就是尽可能百分之百地使所有的行都被覆盖到并被观测到。
在芯片级上使用OBC工具
在芯片级上同样会发生存在于模块级上的问题，这些问题的解决难度远大于模块级：测试包覆盖了多大范围的芯片功能？哪些测试是属于冗余的？芯片中哪一部分的覆盖率比其它部分更低？如果设计中存在一处缺陷，则是否至少会在一项测试中不能通过？
特别是对于复杂程度较高的单片系统芯片，包括一个或多个处理器、许多外设，在模块级上的代码覆盖率结果是无法对下列这些问题做出答复的，其原因有多种：
?所有的模块均已经假设为在单元级经过了验证，也就是说，在单独测试中已经达到了很高的代码覆盖率。因而，在芯片级的验证中，其目的不在于重复进行相同的测试，这是由于模块的功能已经得到了验证。在芯片级，我们所要验证的是模块的集成是正确的，而且相邻模块之间的信息交流是正确的。芯片级上100%的代码覆盖率也由于仿真资源方面的限制而无法达到。
?在芯片启动时，许多操作均开始自动执行：各个锁相环电路均进行启动，产生出复位序列，核心部分从ROM代码开始启动等等。这些操作将至少对某些模块产生相当高的代码覆盖率，但是这就意味着所有的代码均已真正得到了测试吗？答案或许是否定的。这是由于在较大的芯片中，只有很少数的内部信号真正传送到了芯片的输出端。
因此在较大的芯片中，我们就会发现这样一种特殊的情况：一方面，标准的芯片操作产生出相当高的某种代码覆盖率，而另一方面，绝大多数的数据仅在芯片内部进行传送，而在芯片引脚上是观测不到的。针对这种情况，OBC能够有助于在芯片级仿真中产生更为有效的测量结果。
在随机测试中使用OBC工具
随着当今的芯片设计变得越来越复杂，采用传统的直接式激励越来越难以达到很高的测试覆盖率。因此，随机验证技术的应用越来越广泛。但是，随机激励必须完全依赖于自动检查，因为通过对波形的目视检查或其它手工方法无法检查出这种仿真的正确性是不可行的。
OBC技术的概念对于在这种随机验证方法中判断随机激励的质量和覆盖率是非常有用的。
但是，对于OBC工具来说，观测点的选择对于分析来说是至关重要的：只有通过自动检测得到了验证的信号方可定义为观测点。OBC不检查某个信号数据的正确性，但是它假设其它方(人员或自动检查)能够在所有的观测点验证信号的正确性。
对于观测点的选择来说，存在着一个非常重要的限制，这一限制对于随机测试和直接测试一样有效。如果观测点处的信号数值没有得到检查，则OBC工具所报告的数字是无指导意义的。

OBC工具所获得的首批结果
对OBC工具的首次评估只在模块级上执行，采用了一个JTAG控制器作为受测试的模块，然后在模块上运行了一个有8个不同测试的测试包。表1是对这个JTAG控制器模块所达到的覆盖率的概述。
如表1所示，这8项测试的代码行覆盖率(标准覆盖率分析)是相当高的，但是在采用了所有模块输出作为观测点的OBC分析中，已观测到代码行的百分比出现很大幅度的下降。此结果表明，14%的代码行得到了执行，但它们的执行效果并未在模块输出端得到直接的观测。这些代码行的绝大多数均与控制逻辑有关，这是由于控制信号极少直接与模块的输出端直接连接，而是对数据信号进行控制。但是，OBC工具将这种情况认定为未观测到(原因：UEC)，即使这些控制信号有可能与输出端之间存在着一些非直接的效应。
如果选TDO输出端为仅有的观测点(如同TDO输出端是芯片级仅有的输出端一样)，则观测到的代码行的百分比将会出现极大幅度的下降。一方面，这一结果表明某些测试可能需要进行改进，以保证测试结果能够在TDO输出端上被观察到。另一方面，出现大幅下降是基于许多JTAG模块输出均为控制信号的事实，这些控制信号都被送到芯片上的其它模块，而且是不能够直接观测到的。
表2列出了一些关键性的数值，这些数值表明了OBC工具在仿真运行中对性能所起的影响。本结果显示了如上所述的JTAG模块的结果，也显示了作为一个较大规模设计的范例的微控制器芯片的结果。每栏右侧的数值表明与标准的VCS仿真相比较的性能，即没有OBC工具或任何其它覆盖率分析工具的情况下。
在JTAG芯片的设计中，编译和仿真的时间较短，所以对OBC工具使用的影响是观测不到的。但是，在更大的微处理器设计中，对于仿真时间的影响会变得非常明显。
作为一项有意义的成果，我们发现OBC工具所产生出的多余数据(test.line文件)并不大。但是，OBC的能力对于仿真所需的RAM有着显著的影响。这一点对于较大的模块来说，在对内存量的需求超过工作站中可提供的RAM时，可能会成为一个瓶颈。

结果和建议
尽管评估OBC时，它尚处于测试版，但该工具的表现非常稳定，而且比较容易使用。只需在标准的VCS编译和仿真命令中加入几个开关项即可。
对于小规模和中等规模的模块，它对磁盘空间和工作站内存的要求是适中的，因此可以容易地将OBC工具加入到现有的设计流程中。但是，对于大规模的芯片级仿真，OBC对于仿真时间将会有显著的影响，并要求占用工作站的较多内存。OBC对于这种非常大规模的设计所带来的好处尚有必要进行进一步的研究。
可观测性的概念对于传统的代码行覆盖率分析来说，是一项非常有价值的补充。它对于提高一个测试包质量的好处是确定无疑的。将数据的变化传送到一些观测点的概念与传统的故障仿真类似，但是OBC解决方案在仿真速度和内存需求方面所要求的代价较低。
在评估过程中也发现了少数几项缺点：
?运行OBC时需要进行一次单独的编译，而且不能与其它诸如条件覆盖率和翻转覆盖率等选项结合使用。
?在观测到某个寄存器的某一位时，OBC假定整个寄存器均被观测到。这一假定对于移位寄存器来说属于典型情况，但很明显这项假定过于乐观。在内存中的一个字被观测到时，也会发生同样的情况：OBC假定整个内存均被观测到了。
?OBC对数据路径代码的分析是良好的。但是，它把时钟信号、复位信号等仅用于always块的事件控制的控制逻辑信号认定为未观测到。
这就导致了分析结果会过于悲观。但是对于通过采用“if”和“case”等语句描述的控制逻辑的判断是不错的，即OBC认定它们属于可观测到的信号。
OBC改进建议：
?有关上述移位寄存器的问题：很明显，如果要对所有寄存器的所有位均单独进行分析，会过于耗费时间和内存。但是，应该提供一项参数选项，使得OBC能够对所选择的寄存器进行逐位的处理。较为理想的是，OBC应该从源代码中自动地检测出移位寄存器。
?对于内存来说也是如此：由于内存数量可能非常大，逐字对所有内存地址进行处理在绝大多数情况下不可能实现。但是，OBC应该能够对所选地址范围进行逐字处理。
?目前，OBC可以在所选定的模块上执行其分析任务，其中包括整个次层级。
但是，对于芯片级的仿真来说，获取低级模块中所观测到的代码行的相关信息并无多大意义。在芯片级的集成中，其重点更主要地集中在最高2至3层级。是否存在一种方法，能够规定OBC不到模块级做检查，或者只到极少数的几级做检查？