当可追溯性发现验证无法发现的错误时
作者：Paul Graykowski, Arteris IP
在复杂的设计过程中，即使是最专业的系统级芯片 (SoC) 设计团队也不可避免地会犯一些错误。严格的 V型流程（如下图所示）将在从概念到设计（左臂）和从验证到确认（右臂）的过程中防止许多此类错误。在行业内，一些团队已经为右臂开发了重要工具和方法自动化。这个现有流程非常擅长测试设计人员根据设计规范构建的内容。左臂也有一些出色的单点工具。但是由于系统设计工具和用户领域跨度更大，方法自动化还没有那么强大。沿左臂向下移动仍然需要一步一步人工翻译，有可能会产生误解和疏忽。总体而言，在测试系统需求时，V 型流程是无效的，直到右臂的最后一步 – 验证确认（validation），V 型流程才起作用，尽管这时才发现基本错误已经相当晚了。
路径可追溯性必须从系统需求到验证确认进行跟踪
把设计规范作为系统Oracle
测试是以一个参考规范作为基准，该规范声称提供一个或多个需求的精确定义。在测试术语中，将其称为Oracle，意思是神圣的信息，是设计是否合格的最后评判标准。Oracle 可能是设计或用例规范，或者是其他一些具体的需求定义。Oracle构建者在多大程度上遵循最初的系统目标，取决于设计人员接收到的输入的准确性、清晰度和定义。可以理解的是，在这条路径上任何地方出现故障（Oracle构建与最初系统目标相脱节）都会蔓延下去。更糟糕的是，它会以Oracle的权威传播下去。故障点之后的每一步都会将该故障视为不可协商的需求，直到更广泛的测试才有可能发现该脱节。
在有关验证的文章中，通常会谈到发现错误（bug）的时间越晚，查找错误的成本越高。解决方案总是通过尽早进行更多测试 - 静态验证、形式验证、仿真等，来使发现错误的时间提早，即在V型流程中向左移动。尽早进行所有这些测试非常重要。验证人员将会发现低层级Oracle与设计之间的脱节，但是不能发现Oracle的问题。问题来源通常有两个：自然语言规范中的歧义，以及因进度压力而部分或完全放弃一些需求。无论哪种原因，再多的早期验证都无法发现此类问题。
需求验证有助于根据结构来修正设计
W. Edwards Deming 几十年前提出了这样的看法：“通过检查来提高质量为时已晚、效率低下且成本高昂。质量不是来自检查，而是来自生产过程的改进。” 或者在设计方面，最好是第一次就准确地构建结构，而不是依赖验证来纠正实现。当然，验证对于确认设计是否符合需求仍然是必不可少的。同样的陈述也可以用于更新和错误修复。
虽然高级设计语言引起了一些人的兴趣，但它与最终的系统设计相比仍然是相当低层级的，并且与系统级需求没有更好的连接。有一种更高级的方法是直接与需求进行比较，最大限度地减少容易出错的中间级解释。通过低层级的实现细节和对更高层级系统目标的直觉，设计人员可以比较V型图左臂中下一个更高层级的需求。这种比较有助于根据结构来修正设计。在构建测试时，验证人员也可以因此同样受益。在创建和修改实现时，两者也都可以与更接近原始需求的Oracle信息相比较。
SoC 团队如何知道Oracle信息是可靠的？ V 型图左臂下方的需求细化最终提供了输入，设计人员将根据这些输入来实现 SoC ，验证人员也将根据这些输入来构建测试套件。通过低层级需求，可追溯性提供了从系统规范到实现、单元测试，以及系统级测试和全系统验证测试的链接。这些链接确保架构师、设计人员和验证人员可以遵循每个需求，以确保正确解释它。这个过程提供了对于每个Oracle信息、设计和验证工件的更多关注，从而有更多机会发现错误解释。
可追溯性在设计、验证和确认方面的未开发价值
虽然可追溯性通常与汽车和其他市场的安全合规性测试相关联。但作为一种根据结构来修正设计的辅助方法，在实现任何领域的复杂需求方面，它可以提供更多的准确性。它还通过提高对系统规范的关注使验证提前（在V型流程中向左移动）。需求可追溯性为设计人员和验证人员保持Oracle的前瞻性和中心性。验证确保了设计相对于这些Oracle的正确性。
想了解更多？ 请查看 Harmony Trace product。
|
||||||
