验证复用技术确保设计符合预定要求

验证复用技术确保设计符合预定要求验证复用技术确保设计符合预定要求类别：测试仪表 系统级芯片是由已经设计好的模块组成的，设计人员事先已考虑到了各个方面，并对每一部分都进行了检验，现在只需要把这些模块组合起来，集成为一个完整的系统即可。但问题是怎样使集成好的系统能像各个模块一样可靠完整呢？怎样以最快的速度完成呢？如何才能在一项工作完成之后再集成另一个芯片时，尽管每一步都不同也不会觉得又是完全从头开始呢？本文介绍利用验证复用技术对芯片进行测试，确保设计符合原来预定的要求。  在设计复用中，验证就像汽车的刹车一样，我们都知道如何制作结构模块，怎样使接口标准化并使用兼容的后端流程，但恰恰是验证使我们无法再高兴下去。的确，我的模块和你的模块都有很好的测试平台和测试软件，然而将它们放在一起时，却需要新的测试平台和全新的测试，每一个集成步骤都好像要重新来过。验证不像其它设计任务那样可以累积，这就是为什么随着设计变得越来越大，花在验证上的时间也越来越多。下面介绍一些方法使验证工作能够重复使用，这样项目的集成就是可以预测的而不是掉入一个无底洞。我们以国家半导体公司的GeodeGX2为例，许多此类想法都是针对Geode系列集成处理器开发的，而GX2项目也证明了这种方法非常成功。  验证环境包含许多部分，如测试平台组件、测试软件、随机测试生成器、测试计划、规定条件和覆盖范围分析，要想解决集成瓶颈，上述所有部分在下一结构层次也必须可重复使用，这些验证部分的建立和调试时间将比花在设计模块本身上面的还要多，如果不能重复利用，这部分工作将难以想象。  验证复用既不简单也不轻松，需要做大量工作以使验证环境不仅好而且可以复用，但结果是很明显的。下面首先介绍在模块级如何进行验证，然后说明需要验证组合模块时如何复用模块验证工作。  测试平台组件  测试平台组件可以激励设计并观察评估其反应特性。测试平台必须是针对待测模块的，我们发现通过将测试平台以某种规范方式组织起来，并使各组件之间通信方式标准化之后，将可在下一级集成时再利用这些组件。  一个模块规范测试平台包括测试阅读器、处理器、监视器、仿真器和检验器。测试阅读器读取测试语言并将其转化为一系列命令转给处理器，处理器驱动待测模块输入信号，监视器观察模块的反应特性并按照事件序列做出报告。  仿真器是设计参考模块，我们用C++编写仿真程序，这些仿真程序是对事件处理精确而不是对周期精确。给仿真程序输入和处理器相同的命令序列，它将产生我们认为模块应该具有的反应序列。  检验器得到从仿真程序输出的事件数据流和从监视器输出的事件数据流，将两者进行比较并将不匹配作为错误报告出来。  许多设计人员习惯于在测试平台中使用监视器和处理器，却将仿真器和检验器视为额外的工作。编写自查测试或使用判定语句和智能监视器来查找错误确实比较简单，但我们发现编写仿真程序和傻瓜式监视器及检验器常常比编写智能监视器更加简单，它使得测试不必检查其自身，这样随机测试更加容易。 这种测试平台组织方法的真正优越性还体现在集成上。例如可以凑出一个测试平台，用另一个模块的仿真程序来驱动处理器而不用自己的测试程序，这样可以在不更改模块的前提下运行另一模块的所有测试。或者也可以使用两个监视器、两个仿真器和两个检验器分别说明两个模块，如果原模块输入是点对点来自于另一个模块，则只要去掉原处理器运行另一个模块测试程序即可；如果原模块输入是多路驱动器总线，则可以保留两个处理器同时进行两个测试，每个测试的内容从各模块测试程序中选取。通过在模块级测试平台上做一些额外工作，可以得到能在集成测试平台使用的组件。  这种复用性能可一直延伸到结构最上层，通过将仿真器和处理器混合匹配在一起，你可以测试任意组合形式模块而无需设计新的测试平台组件。  GeodeGX设计小组针对每个主要模块使用一种测试平台，如存储器控制器、 PCI接口、处理器内核和显示控制器（图1），我们将各部件组合起来做成组合模块测试平台，到项目收尾阶段我们使用了40个不同的测试平台，这些测试平台都共享测试组件。  测试计划  每一个验证环境都应该有一个测试计划，建议你将它写下来。测试计划就像锻炼一样：我们知道应该做，但有时就是不想做，因为太麻烦。计划做好后应将整个小组集合起来，集思广益讨论测试方法，要经常这样做而且越早越好。测试计划也应是可重复利用的，我们选择一个可以描述极端情况的简单格式，然后记下这些情况是否已被考虑，以及由哪个测试完成。如果测试计划使用通用语言，还可以有一些工具能根据计划追踪进度，并且在到达集成时将测试计划累积起来。  有关验证一个很困难且无法回避的事实是，没有什么可以替代用手工仔细编写的测试程序。这是一种劳动密集型工作，其编写和调试非常单调乏味。但如果谁要能够编写覆盖极端情况的测试程序，那么他将是一个很好的逻辑设计师，事实上模块设计师应该编写大部分测试程序，在数字设计中黑盒测试和白盒测试都很重要。  我们设计了一个C++应用程序接口作为外围模块测试语言，而将X86汇编语言用于处理器内核。但是具体的测试语言要根据设计类型决定，测试语言越少越好，这一点很重要，最好是只有一种。如果不同的模块可以用同一语言进行测试，那么在硬件运行这些测试或今后设计采用新模块组合时可以节约大量人工。  验证的一个重要部分是随机测试，对GeodeGX2我们编写了上千条测试程序并生成了更多的随机测试。我们对想得到的任何事情进行随机处理：中断、停止、调试中断、探测、存储器延迟、I/O延迟、仲裁形式等等，如果随时都可以用两种方法，那么确保两个都做，并在两者之间进行均衡。  设计中有些地方只有逻辑设计师知道，他们需要将这些部分作为规定内容进行编码，然后在每次仿真时都可自动进行检查。规定内容就像一个微型监视器，它可检查一些条件并且在违反这些条件时使测试失效。例如你可以规定两个信号不能在同一时刻出现，或一个信号不能在另一个信号的六个周期内出现，或FIFO不能溢出等等。无论怎样规定和定义数字接口，我们总要假设接口是怎样使用的，并经常在口头上对其它设计师讲清这些假设。我们应该做一些额外的工作将假设作为一个规定写到设计中去，这样两年后当你不认识的人使用你的设计时，或者接口协议有轻微改变时，都可以容易地取消这些规定直接解决问题。 一些设计人员喜欢这种规定是因为它们使调试变得十分简单，而有些人则必须要经过劝说他们才会使用。其实这是很值得的，它将使你的设计更加完善。由于它们是模块RTL逻辑的一部分，所以对集成复用并不重要。这种规定的另一个好处是可将它们提供给静态规则检查器，我们在GeodeGX2上使用了等效检查器而不是静态规则检查器。正式检验工具在特性和处理复杂性方面发展得很快，即使有好的测试计划、好的测试平台和随机测试，验证也只是一个没有覆盖范围分析的开环过程，只有覆盖范围分析能告诉你所做的工作状况怎样并显示哪些地方仍需要关注。最为成熟的覆盖工具是代码覆盖工具，它能检查所有已编写并正在使用的代码，或设计中正在摆动的每一个信号、设计中每个翻转的触发器等等。GeodeGX2小组使用的代码覆盖工具结果在90雅V99沱间，我们还计划了一个功能覆盖工具但后来没有时间和资源来实现它。  总而言之，只在模块自身环境下对其进行测试集成是不够的，需要运行一些