功能验证被广泛认为是SoC设计的主要瓶颈之一。在SoC产品化的过程中，很大一部份工作都花费在验证上。根据Wilson Research Group的统计，在2014年，典型的SoC项目中有57%以上时间都耗在验证上。

图1：设计项目中验证时间所占的百分比 （来源：Wilson Research Group）

虽然付出了如此大的努力，但对于首次设计，功能故障的风险仍然普遍存在。自从多处理器芯片(包括异质设计)问世以来，SoC的复杂度显著增加。从图2可以看到随着时间推移以及工艺的演进，SoC中的IP组件数量迅速增加。

图2：典型系统中的IP组件数 （来源：ChipDesignMag）

SoC已经演变成为复杂的实体，整合了多种不同的IP。当今的SoC可能包括多个组件，例如CPU、GPU、互连、内存控制器、系统MMU、中断控制器等。IP本身也是复杂的设计单元，需要经过独立验证。即使经过IP级的严格验证，也不可能检测出全部的错误(bug)——特别是有一些错误只出现在系统内部IP之间互动时。本文旨在让读者了解ARM所进行的系统级验证工作，并进一步带动广泛的应用。

很多SoC设计团队结合使用自家研发和现成的商用工具与方法，分别解决各种验证问题。系统级验证目标在于为合作伙伴提供经过验证而能正确互动操作的高质量IP。这样可以奠定标准基础，让合作伙伴能够在此基础上建构自己的系统验证SoC解决方案。以此坚实的基础为起点，合作伙伴的设计和验证工作就能更侧重于SoC的设计差异化，以及IP与系统其他部份的互动。

验证流程

ARM的验证流程与业界广泛采用的流程非常相似，如图3所示。

图3：ARM验证流程金字塔

设计的验证作业必须从早期以及细部单元开始，这些单元共同构成了独立的IP。在整个验证周期中，只有在单元级，工程师才能够获得设计的最佳能见度。除非讯号位于设计底层，否则可在单元级对各讯号进行探测，或将其设置为理想值以协助验证。当单元级验证达到一定的成熟度之后，这些单元可以组合在一起形成完整的IP(如CPU)。只有在此之后，才能开始IP的IP级验证。对于CPU而言，这通常是能够进行汇编程序级测试的开始时间。在此之前，大多数测试只能透过控制各个线路/讯号进行。在IP级，测试是使用汇编语言编写的。处理器从内存(仿真)获取指令，并对其进行译码后执行。在IP级验证到达一定的稳定度后，多个IP组合形成一个系统，开始进行系统验证作业。

在IP的设计、验证阶段会经过多个里程碑，能够反映其功能完整性和正确度。其中，Alpha和Beta是内部质量里程碑。LAC(限制存取)是引导合作伙伴存取IP的里程碑；其后则是EAC(早期存取)里程碑，意味着IP已经准备好用于制造，以便获取工程样本和测试。在达到REL(发布)里程碑之前，由于IP已经过严格测试，能够投入量产。

在通过系统验证流程之前，IP质量通常处于Alpha和Beta之间。在设计周期阶段，IP已经过大量测试了，大部分的低层级错误已被发现。必须非常缜密细心地构建激励，才能尽可能地覆盖每个IP微架构的内部状态。激励既可由组合程序代码提供，也可以使用整合于系统中的专用验证IP。ARM结合使用了这两种方法。

有些错误如果未被检测到，可能导致最终产品出现严重故障。基于以往的经验，ARM估计需要1至2千兆(peta)个周期验证，以及4至7个人进行数月的除错，才能发现这些类型的错误。很多情况下，严重的延迟会让芯片错失在目标时间内推向市场的机会。在整合至一部份的SoC之前，应该在设计周期及早发现这些错误，这对确保IP的稳定基础至关重要。

系统验证

ARM IP的本质意味着它可用于各种不同的SoC中，从物联网(IoT)设备到高阶智能型手机，再到企业级产品。系统验证的关键目标是确保技术能够一致地、可重现地执行设计的功能，在对IP进行严格验证时，必须始终牢记这个目标。换言之，验证的重点目标是IP，但必须在实际的系统环境中进行。为此，ARM在多种不同的实际系统配置下对IP进行测试，这些系统配置被称为套件(kit)。

套件被定义为以子系统形式整合在一起的“IP组合”，针对特定目标的应用市场(例如行动、IoT、网络等)。它通常包括ARM内部开发的一整套IP——CPU、互连、内存控制器、系统控制器、中断控制器、除错逻辑、GPU和媒体处理组件。

套件可进一步细分为更小的组件，称为“元素”(element)，可以被视为套件的构建模块。它包含至少一个主要IP，周围有空白逻辑，不过有些元素也是由多个IP整合在一起的。这些套件专为代表不同应用的SoC而设计。一种结果是让ARM能够更全面地了解整合不同IP组件的生态系统在实现目标系统性能时所面临的挑战。

图4：系统验证的多层次途径

系统验证团队结合使用激励和测试方法，形成强大的测试套件。激励主要是在系统中CPU上执行的软件测试。这些测试可以使用汇编语言或更高层级的语言等手动编写，或者使用随机指令序列(RIS)工具产生。除了编写在CPU上运行的程序代码，我们还使用一组验证IP(VIP)，为系统注入激励并观察执行情况。

在准备验证时，必须为套件中的每个IP创建测试计划。测试计划包含不同的IP配置、待验证的功能、涵盖的场景、激励与IP的互动、验证指标、追踪机制以及验证中的各种流程。对套件的测试从简单的激励开始，然后逐渐升级到更复杂的场景和压力测试。

测试将执行各个子系统级的评估，例如性能验证、功能验证和功率估测。透过报告记录选定套件的参考数据，包括性能、功率和功能质量，并在内部公布。

ARM的系统验证团队已经建立了可重复的自动化套件开发流程，让我们能够构建针对不同市场的多个套件。ARM目前每年建构和验证大约25个套件。

选择IP及其内部配置，以及系统的拓扑结构等不同组合，能够反映广泛的最终用途。这些套件在两个主要平台上进行测试——硬件仿真(Emulation)和现场可编程逻辑数组(FPGA)。通常，测试会先在硬件仿真器(Emulator)上开始，然后在FPGA上完成Soak Testing(浸泡测试)。每个IP平均经过5-6兆次硬件仿真器周期和2-3千兆个系统验证FPGA周期。为了执行这个级别的测试，ARM开发了一些内部工具。

系统验证工具

系统验证主要使用三种工具，分别着重于指令管线、IP层级和系统级内存系统、系统一致性、接口级别等互操作性等。其中两种工具是随机指令序列(RIS)产生器。RIS工具可通过自动化方式探索架构和微架构设计领域，试图触发设计中的故障。相较于手动编写的定向测试，它们能够更加有效地覆盖测试空间。这些程序代码产生器可以产生测试，以便透过自动化方式，对架构和微架构的不同区域进行探索。这些测试是多线程的组合程序代码，包括随机的ARM和Thumb指令，目的在于充份执行设计中不同部份的功能。

第三种工具是轻量级的核心，可用作开发定向测试的平台。这种验证方法结合使用定向测试和基于随机指令的自动化测试，可支持基本的内存管理和线程排程，以及一部份Pthreads API，让用户能够开发参数化的定向测试。

方法

为了在系统级对于IP进行压力测试，采用更随机而非定向方法。这将足以覆盖广泛的场景、激励多种时序条件并创建复杂的事件。为此，套件可以支持多种有利于验证的功能，例如在不同接口上更改频率比、实现错误注入以及停用不需要进行功能验证的组件等。此外，还可以更改系统中不同接口(例如CPU、互连和易失存储器控制器)的总线频率比，以激励实际的系统频率条件。

图5：系统验证发展

图5显示系统最初如何发展、调度，以及测试复杂度如何随之逐渐增加。

__整合测试和KVS__　初始测试从一系列简单整合的测试开始，其目的在于确认套件的基本稳定度，并消除较小的整合问题。随后采用一套名为Kit Validation Suite(KVS)的测试软件，彻底测试套件的整合度。这些测试在验证周期的早期进行，以确认套件是否足够强大，足以执行更大压力的工作负载。KVS可以配置为在多个套件上执行。它包括了多个子软件包，分别用于测试整合、功耗、CoreSight除错与追踪、媒体IP。KVS还提供特定的测试，用于测试GPU和显示器的整合，以及GPU的一致性。初始启动通常得先做模拟，然后逐渐转移至用于整合测试的硬件仿真器。

__RIS Boot和BringUp测试__　随后，以套件上的基本上线(bring up)测试启动所有的RIS工具，以检测所有的硬件/软件配置问题。

__RIS：默认和重点配置__　套件稳定后，测试的复杂度逐渐增加，对于系统的压力也会随之提高。相较于定向激励，随机激励可以更快地覆盖设计空间，在激励创建方面的工作量也比较小。因此，压力测试更加依赖于随机激励，而不是定向激励。首先执行RIS工具的默认配置，在经过适当数量的验证周期后，将重新配置工具，以便对套件中的特定IP进行压力测试。

__RIS浸泡测试__　在系统验证的最后阶段，套件在FPGA上进行浸泡测试。虽然硬件加速器更加有利于除错，但FPGA的速度更快，能提供更多验证周期。因此，待IP稳定成熟后，在FPGA上进行浸泡测试，以寻找那些复杂的极端案例(Corner Case)。

指标、追踪、覆盖和里程碑

为每个套件执行的验证周期数量是值得追踪的主要指标之一，目的在于确保达到目标验证周期数量。这对于确保达到浸泡测试周期的目标尤其有用，从而增强IP在各种应用中的质量信心。此外，利用统计覆盖方法进行量化和追踪，则确保整个设计(包括潜在的极端案例)都经过充份测试。

例如，最新版本的ARM Juno芯片经过总计6,130小时的验证运行时间，相当于8.5个月的测试。这为我们提供可看到系统内部极端情况的独特视角，因而能够更有效地为尝试除错自家设计问题的合作伙伴提供支持。此外，在验证流程中发现的错误也可以回馈给IP设计团队，让他们利用这些信息改善IP质量，并为下一代产品提供指导。

小结

随着时间推移，验证方法已经演进为一种为系统大部份IP测试多个组件与压力的方法了。而当系统复杂度随着SoC性能一起增加，导致花费在验证上的时间和投资大幅增加。ARM在向合作伙伴发布IP之前均先行验证IP的互操作性，以确保适合各种应用，同时也确保设计IP能够在合作伙伴建构的系统中协同运作。

本文授权编译自EE Times，版权所有，谢绝转载

关注最前沿的电子设计资讯，请关注“电子工程专辑微信公众号”。