《可扩展验证克服现有验证方法的局限性》由会员分享，可在线阅读，更多相关《可扩展验证克服现有验证方法的局限性（10页珍藏版）》请在金锄头文库上搜索。
1、可扩展验证克服现有验证方法的局限性随着芯片设计规模和设计复杂度日益增加(包括软件设计和模拟设计在总设计工作中所占的比重日益增加)，功能验证的重要性也日益凸显。所谓设计规模增加，是指一块SoC上所包含的晶体管数量变得惊人的多，这就导致其中包含的门也越来越多。如今，仅一块SoC上就已经可以包含上千万个门，这无形中增大了电路出错的几率，也使验证工作变得更加复杂。 而所谓设计复杂度增加，则指一块单独的芯片上包含的组件种类增多，不同种类组件的数量也变多。这里所说的组件包括高性能CPU、多个千兆I/O、嵌入式RAM、系统时钟管理组件、模拟混合信号、嵌入式软件和专用数字信号处理器(DSP)。随着这些组件的种
2、类和数量增加，对芯片的整体功能和性能而言，各组件之间的接口就变得越发重要。此外，片上软件和模拟器件也越来越频繁地出现在芯片中，这又进一步提升了系统的复杂度，同时对传统的验证方法提出了挑战。 首先，数字设计工程师们必须面对一些他们并不熟悉的模拟设计方面的问题。其次，许多硬件设计都要求固件或低级软件就绪而且可以工作后才能验证RTL的功能。这就要求固件设计师必须在硬件设计中扮演重要角色，仔细协调软、硬件之间的相互关系。 这就是说，我们必须改变设计方法。用一句老话说，要么做得更好，要么就换种方法来做。想做得更好就必须研究现有方法所采用的工具及其效率，而换种方法来做则必须改变方法以获得更高的效率。这两种
3、方式之间不存在谁对谁错，但更有效的方式则是随着时间推移，将二者中的一些元素结合起来，并在恰当的时刻应用到我们的验证方法中去。 要改进现有方法，首先必须研究各种工具本身，以及它们之间的相互关系。为此，我们需要能够涵盖以下验证域的工具：软仿真、硬仿真、硬件、软件，以及模拟和数字域 。此外，这些工具还必须支持所有标准和新兴的设计语言，包括VHDL、Verilog、 PSL、 C、 SystemC，以及最新的SystemVerilog。在某种程度上说，这就是我们所说的可扩展验证(Scalable Verification )。 改变现有方法意味着研究设计过程本身，并在设计的更早期开始进行验证，包括创建
4、系统级测试平台、建立事务级模型，以及保证在系统接口创建时(而不是在设计末期)就能对其进行检查。要做到这些，需要有能够涵盖各个抽象级以及系统各个域(例如软件和硬件)的工具。 不同验证工具间的可扩展性 要做到以上这些，我们的方案中应包含一系列工具，这些工具结合起来能够胜任从HDL仿真到在电路仿真(in-circuit emulation)的一整套完整的任务。也就是说，采用更好的软仿真器和硬仿真器能够加速各种集成度等级的验证过程。 之所以要求工具间具备可扩展性，是因为不同类型的验证在不同的性能区间上提供的是不同的方案。每一套方案都必须在许多不同的特性之间进行权衡，例如迭代时间、性能、容量、调试的可视
5、性和验证成本。就连HDL执行引擎也需要许多不同的方案。 一些方案在模块级表现更好，另一些则在芯片级或系统级表现更好。例如，打算验证系统结构决策的设计师就不应采用HDL软件仿真器，而应采用抽象模型或事务级硬件软件环境，因为这些方案才能提供他们需要的信息。反过来说，验证芯片设计中相对较小的子模块时，在电路仿真并不合适，而HDL软件仿真器则能快速简单地完成任务。 认清哪些工具最适合手头的验证任务，然后找到这些工具。如果做到这点，设计师就能得到最高的效率。以下是一些可供可扩展验证方法采用的技术： 软件仿真：适合模块级验证，因为其运行速度很快而且调试功能强大 软硬件协同仿真：允许将嵌入式软件引入验证过程
6、，并提供了一种可用于加速处理器、存储器和总线操作的手段，还可用作验证硬件的测试平台 测试平台加速：通过逐级提升验证的性能等级突破了协同仿真的性能局限。基于事务的方法使重用率更高，而对更高重用率和高级验证语言的支持则催生了生产率更高的测试平台方法。 硬件仿真(在电路测试)：允许在真实系统中进行高容量和高性能的验证，让设计师确信其芯片在真实系统中能够正常工作。 正式等价性检验(Formal equivalence checking)：其容量和速度保证了设计流程晚期进行的一些改动不会影响芯片的预期表现。 模拟/混合信号仿真：允许对芯片的多个域进行验证，保证验证具备最佳的准确度和性能。 还有很重要的一
7、点需要注意，那就是高性能的硬件辅助或者面向硬件的方案对于在系统级环境下实现验证的完整性至关重要。 验证工具内的可扩展性 一个优秀的验证方案，除了能够在不同的工具间转移之外，还应确保发挥工具本身最大的效率。因为只有这样，验证过程才能在单一环境下持续，直到确实需要改用其他方案为止。 这种工具内的可扩展性可通过多种方式得到体现。例如，在进行回归测试(regression testing)时，很可能会有大量测试需要频繁运行，而且大多数公司都希望在一个晚上的时间内完成测试，以便在第二天早上开始其他工作之前发现并解决问题。但单独一个软件仿真器的性能不可能达到在合理时间内完成如此大量工作的程度。反之，一个很
8、容易建立的仿真集群则可以将这些大量的工作排序，并在任何可用的机器上运行，从而使回归测试变得更加切实可行也更简单。 如果回归测试集中还包含运行时间很长的测试，那么就需要用到硬件仿真器。一个单独的硬件仿真器本身在仿真规模上就已经非常灵活，因为只要设计中门的数量不超过该系列硬件仿真器的最大容量限制，仿真器的容量可以轻松扩展以适应不同的设计规模。而且在必要时，还可以通过将多个硬件仿真器连接起来达到扩展容量的目的。 另一个例子是正式等价性检验。等价性检验工具可以缩短一次回归测试运行的时间或降低其运行的频率，但这种工具也有其自身的限制。此类工具的结构必须实现极高的存储器效率才能实现全芯片验证和回归。在设计
9、规模达到上百万门时，设计师不可能依靠工作站上的物理存储器来解决这一问题。同时，等价性检验也需要根据设计的复杂度调整规模。如果需要更大的处理能力，可以让多台机器同时工作，以缩短回归测试的运行时间。 工具内可扩展性的另一方面对硬件仿真而言尤其重要，那就是尽管在不同的设计规模下硬件仿真器的性能基本一致，但当需要与逻辑仿真器连接时(例如在行为测试平台中)，硬件仿真器的速度性能会急剧降低到与一般的软件仿真器速度相当的程度。要解决这一问题，必须构建一系列方案，允许将更多的设计与/或测试平台映射到硬件仿真器。这些方案中还必须包含高速的事务级接口，以保证与那些必须留在工作站上的部分有效连接。这一过程中需要用到
10、非常先进的综合技术，在设计流程的正常情况下并不要求采用这些技术，但它们却能改善硬件仿真器的性能。 不同抽象等级之间的可扩展性 今后，我们将不得不在设计过程的初期就开始某些方面的功能验证，而要做到这一点，就必须利用更高级的模型和事务处理器使验证更加抽象化。将验证提前到设计早期进行可带来以下好处： 首先，在设计早期，模型更容易编写，允许的数据流量也更大，因此可能对设计决策有决定性的影响。另外，在这种更高的抽象级别上工作有助于提高测试平台的可重用性。对于复杂SoC而言，在RTL或门级进行所有验证耗时太长，也太困难。我们必须用更抽象的表达来描述设计，不仅对设计是如此，对测试平台亦如此。 利用C,、C+
11、和SystemC等编程语言创建此类高级原型，就可以立即验证每一个正在进行的架构或划分决策。即便是传统的硬件描述语言(HDL)，例如Verilog、VHDL或 SystemVerilog，都可以在比RTL更高的级别上得到较高的效率。这些抽象模型可以通过创建系统级测试来验证。在将系统分为硬件模块和软件模块，或者提炼出设计层次之后，我们可以借助验证工具在这些模块或层次间建立接口，不必等所有模块都达到同样的抽象级别之后才开始验证，从而使每个模块能随时间的推进而有所进展。 而多级抽象策略要想行得通，就必须将工艺和IP结合起来。为此，我们需要一些能够让设计师们在不同的抽象等级之间切换并将它们联系起来的模型
12、。 利用一系列事务处理器为一个设计构造理论接口，我们就可以进行分级验证(Hierarchical verification)，因为此时我们可以将不同抽象等级上的设计描述混合起来。这些事务处理器可以组合成一个测试平台或环境，用于检查一个设计的实现是否与更高级的模型相符。 这种验证策略还有一个优点，即不要求所有模型处于同一个抽象级别。因而设计团队可以将在某个特定时刻可用的任何模型组合起来，得到在一定的运行时间所必需的分辨率水平。 基于事务的接口可以将抽象系统模型与设计连接起来，提供一个理想的系统级测试平台。例如，采用基于事务的仿真，设计团队就能在很高的抽象级上定义一个系统。然后我们可以将这个高级系
13、统定义内的单个抽象级，或单个模块拿出来，采用将该事务具体化所需的IP代替它，从而得到一个更加具体的实现模型。将这个模型放回系统中原来的位置，就立即得到一个测试平台。设计团队可以立即使用这个测试平台，得到一个提供给模块的自然激励。这样一来，不但验证的生产率得到了提高，设计人员对设计的信心也会更饱满。 改善的调试方案 要支持可扩展验证方案，调试工具必须完整，即必须支持各个抽象级和各种扩展工具。其目的是加快验证过程查找问题的速度，查出问题的起因，并解决问题，将反馈时间减至最短，并将验证的重复次数减少至最少。目前，设计和验证团队超过一半的时间都用于调试，因此该领域的性能改善必将极大缩短产品的上市时间。
14、 一个系统内，多抽象级和多种不同符号含义的共存会使系统级调试变得更加复杂。而调试环境的不同，例如硬件和软件环境或者数字与模拟环境的不同，则使这一问题变得更难解决。因此，设计信息不但必须对设计和验证人员开放，而且必须出现在语义正确的上下文之中。而且，由于一个系统中存在多个抽象级，所以此类信息还必须在设计人员需要的抽象级上出现。 例如，在调试软件时，有关软件程序运行的所有信息都包含在硬件存储器中，而在调试过程中这些信息都是设计人员看不到的。因此，弄清一个变量的存放位置只是我们要做的第一步。 同时，如果信息并未存储在缓存或寄存器中，那我们还必须明确信息到底存储在哪一块存储芯片中，以及它在该芯片中的相
15、对地址。即便这点已经明确，很多时候由于数据或地址的交叉，数据在芯片中的存储也并没有一定的逻辑顺序。 为了解决这些问题，新的调试方法正在得到普及，例如断言(assertion)和检查库(checker)，但这些新方法的作用还没有得到充分发挥。业界关心的另一个问题是验证的覆盖率。许多工程师都没有意识到，满足了代码覆盖率标准的要求并不意味着系统已经得到了充分验证。要保证系统得到充分验证，还要使用功能覆盖率和断言覆盖率等其他标准来检验。 自己创建一个激励，将其馈入执行引擎，然后分析得到的响应(见图5)，这是今天的许多工程师都会的。一般情况下，他们会将设计的某一次实现得到的波形与一个参考模型进行比较，从
16、中寻找差异。这是一种缓慢又有些依靠运气的调试方法，因此会有许多错误遗漏。因为这样一来，我们很容易死盯住已经发现的问题，忽略了其他有问题的地方，或者意识不到我们当前采用的测试平台根本没能暴露出新的问题。 图5 所以，设计工程师必须要走出大多数现有调试方法重复、冗长和盲目的死胡同。在设计流程的晚期，等价性检验将是一种非常强大的工具。等价性检验主要用于测试一次设计实现与一个参考模型之间的差异，但它并非仅仅比较两组仿真波形，而是通过一种更加正式的方法进行比较。 最近，另有一些测试平台组件已经成熟，可以投入使用，例如测试环境生成器、预测器和检查库(checker)。有了这些测试平台组件，我们就可以自动生成测试环境，并检查相应的结果是否合法行为。这些组件中，检查库是最成熟的一种。当然，检查库也属于断言。断言分为两种，一种叫做测试依赖断言(test dependent)，一种叫做测试独立断言(test in
