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