首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

应对百万门级系统级芯片验证挑战的可扩展解决方案(2)

应对百万门级系统级芯片验证挑战的可扩展解决方案(2)

改进的纠错解决方案
        为支持可扩展验证解决方案,纠错工具必须实现集成,在各个抽象层次上保持前后一致,在各个可扩展性工具之间保持一致。其目标 是加快速度发现错误、跟踪捕获故障原因、修复故障,并最大限度缩短反馈时间,将反复回路减少到最低限度。目前,无论是设计团队还是验证团队,都将超过 50%的时间用在纠错上,因此这一领域的改进可能对缩短产品上市时间产生重大影响。
        在系统层次上,由于抽象层次混杂,系统内部存在的不同语义,因此纠错工作变得更加复杂。在异类环境,比如硬件和软件或数字 和模拟环境中,挑战就会更为严峻。因此,信息不仅必须可用,而且必须在正确的语义背景下可用。同样,利用多层次抽象,信息也必须在必需的抽象层次上可用。
        例如,对软件纠错时,有关软件程序执行的所有信息都包含在硬件记忆体中,但没有任何东西是随时可用的。了解变量放置在何处 正是解决方案的发端。它还必须确定信息保存在哪个芯片之中以及芯片中的相对位置,假定它并非缓存或寄存器。在许多情况下,即使在这种时候,数据还可能因为 数据或地址交叉原因而未按逻辑排序。因此,获得变量值就可能非常复杂。
        为了化解这些挑战,新的纠错方法正在不断推广。例如断言或检查器,尽管其用途并未得到完全理解。另一个容易引起混淆的问题 则涉及覆盖率问题。许多工程师并未认识到,满足代码覆盖率标准并不意味着系统已经得到适当验证。同样,我们还必须使用功能覆盖率或断言覆盖率等其它标准来 确认该设计已经得到完全验证。
        今天,绝大多数工程师都在创建激励源,并将其馈送进入执行引擎之中,这样他们就可以对产生的响应进行分析(图4)。在许多 情况下,他们对照参照模型对该设计的某项实施的波形进行比较,寻找不同之处。这是一种单调乏味且毫无把握的纠错途径,也正是众多错误不被发现的原因所在。 我们很容易将注意力集中在手边的问题,同时错过这样一个事实,即有些地方已经出错,或目前的测试平台无法反映新的问题。
        设计人员必须摆脱当前的绝大多数纠错方法,因为就本质而言它们都是单调的、重复的且不可能行得通。在设计流程的稍后阶段,等效性检查可能是一项非常强大的工具。等效性检查可用于对照参考模型测试实施情况,但它采用形式验证的方法,而不是试图通过模拟比较两套波形。
        最近,其它一些测试平台组件已经臻于成熟达到可用程度,比如生成器、预测器和检查器等。它们允许自动生成测试预案,并对照期 望行为检查响应成果。其中最成熟的当属检查器,也即断言。现有两种类型断言,即依赖测试内容的断言和不依赖测试内容的断言。依赖测试内容可以轻松插入现有 验证方法中,无需其它工具支持;不依赖测试内容的断言则与生成器联系,需要其它工具并改进验证方法。
        故事并不止于此,因为目前还有一些尚未精确定义的测试平台组件,比如功能覆盖率、测试计划以及验证管理等。尽管这种测试平 台转换尚需几年时间才能完成,但一旦完成,人们梦寐以求的可执行计划规范就将实现,不过其方式已经迥异于业界最初的预测。它不会用于自动执行设计流程,但 将应用于自动执行验证流程。
基于断言的验证
        如前所述,测试平台受到两大独立因素的制约:可控制性和可观察性。可控制性可等同于激励源插入后测试平台激活设计中存在问题的能力。它与代码覆盖率存在非常密切的关系,也正是我们在运用代码覆盖率时必须小心谨慎的原因所在,因为它并未考虑测试平台的其它方面因素。
        问题的另一半则是可观察性。故障一旦出现,两件事情必须发生。首先是这一故障所产生的效应必须传播至主要输出,随后故障必须 被发现。对大多数测试平台来说,接受验证的主要输出的数量非常少,因此我们会对许多问题视而不见。这正是断言之所以强大的原因所在。断言对可观察性造成积 极影响,提供多项好处。它们能够明确除错的主要原因――而非次要或第三位原因――纠错工作变得更为轻松和快速。这是因为它们能够分散在整个设计之中,产生 实际的主要输出,后者则自动检查验证对象的行为好坏。
        这样,测试平台就不必再将这些错误效应传播至实际的主要输出,使得测试平台的开发变得更加容易。另外,我们还可以对大量数 据进行验证,否则的话它们将被忽略。断言还开展数据检查,使得测试平台更加有效。某项断言一旦设计完成并被置入设计中,那么它就总是处在运行状态。在许多 情况下,断言检查的东西并非测试的主要内容,因此它们将会发现非预期故障。例如,在模块测试阶段插入的断言在集成阶段乃至系统层次测试中都会执行其检查功 能,这样就可以提供更为广阔的验证覆盖面。
        最后,断言使得测试的范围更为宽广。运用基于断言的验证技术的工程师经常发现,其检错速度远远超过非断言技术。这样就可以 抵消编写和放置断言造成的总体开销――约占3%总开销时间以及10%总运行开销时间。运用断言的公司报告称,在其所有程序错误中,大部分是通过断言来发现 的,其纠错时间也缩短了80%之多。
        断言可以嵌入设计之中,或者其规定内容可以独立于设计,并附加在设计中的各个点。是内部还是外部则部分取决于谁在创建这一 断言,比方说创建人员是设计人员还是独立的验证工程师。如果它们被嵌入设计之中,则主要验证技术规范的实施。如果属于外部开发,则将验证技术规范的解释, 或在某些情况下对技术规范本身进行验证。因为嵌入式断言实际上都是可执行的注释,因此它们可能放置在任何可以放置注释的地方。
        好处是注解现在变得更有价值,因为它们在发挥作用。注解包括期望行为的说明、设计人员作出的假设或针对期望用途作出的限制。它支持再利用,它提供有关设计的预期行为的所有各类信息,提供原设计人员的意图。至少所有的第三方知识产权IP就应该内建接口上和用途方面的断言。
        目前,人们对断言的主要兴趣是如何进行模拟断言,但这并非断言的所有功能。断言的基础是一些名为属性的更为基础的东西。属性 可以用于断言、功能覆盖标准、形式检查器以及用于伪随机刺激生成的约束生成器。属性既可为模拟器也可为形式分析工具所用,它能够将静态和动态验证技术融入 一种方法中。随着这一领域中标准的来临,在今后数年中,运用属性的工具预计将会迅速增长。
本文小结
        设计团队需要运用那些能够在设计复杂性和多层次抽象之间扩展的工具改进现有方法。可扩展解决方案能够帮助工程师开展他们目前能够开展的工作,而且在相同时间范围内只会变得更好、更快且效率更高。它使得验证工具对用户更为友好,并能够在设计过程中推入更多测试向量。
        任何有效的系统验证策略都必须提出这样的前提条件,即系统实际上指的是整套系统,它包含的远非数字逻辑那么局限。换而言之, 一套有意义的解决方案必须能够解决数模信号混合问题,必须能够提供为软件、RTOS的验证运行所必须依赖的环境,并将其联系在一套统一的解决方案之中。
        新的测试平台组件正在进入今天的验证方法之中,断言的使用可能对质量和速度产生戏剧性的影响,因为验证工作可以利用断言来 开展。此外,某些更新的测试平台组件正在出现。所有这些新的组件都将受到属性的驱动,既而操控和利用属性。这是未来的发展方向,现在开始已经变得异常光 明。这种自动化、基于属性的验证方法将推动验证性能的提高,这也是缩短验证鸿沟的必要条件。这事实上相当于10年之前设计路径曾经享受过的综合的好处。验 证综合还在发展之中,并将从根本上改变探讨和处理验证问题的方式。
继承事业,薪火相传
返回列表