日志

验证的方法篇之七：性能验证

已有 3820 次阅读| 2016-9-11 16:19 |个人分类:验证系统思想

在迈过了效能验证的坎以后，我们来到了性能（performance）验证部分。顾名思义，在这部分验证当中我们需要测试芯片的性能，而测试性能又离不开大量的运算或者数据传输。我们之前提到过，硅前RTL验证的瓶颈之一在于仿真速度，而且一旦到了芯片级仿真，这一因素就更进一步放大了。

由于在产品定义过程中，对于系统的运算和数据传输都有要求，如果可以在产品实现阶段尽早地得出一些基本数据，从而为硅后测算出一些性能数据，那么这不但可以帮助提前指明硬件实际性能是否满足，在有时间的情况下对于可以调整的硬件设计还可以做出完善性能的修改，同时，这种将性能测试提前的方式也可以使得硅前验证与硅后测试使用的性能测试用例保持一致，进而得出有帮助的性能数据。

性能验证是用来衡量一个系统在特定工作负载下它的响应能力和稳定性，同时通过性能报告也可以用来分析和优化系统的质量标准，例如可靠性和资源使用能力。性能验证是一门实用的计算机科学工程方法，且在软件工程测试中分类较多，譬如有负载测试（load testing）、压力测试（stress testing）、浸泡测试（soak testing）、尖峰冲击测试（spike testing）、配置测试（configuration testing） 、隔断测试（isolation testing）等。

目前在硅前验证阶段，性能验证还是一个新颖的概念，一方面由于业界对这一测试还没有形成一致的定义和验收标准，另外也是由于性能验证更多地是在衡量测试指标，而与验证（判断设计是否与功能描述一致）本身的聚焦不太重合。但是，对一些性能要求（同样对于功耗要求）较严格的硬件设计，我们确实希望在更早期就得出一些数据，而且最好能够赶得上给设计做出反馈并且完善设计，做更早期的回馈，以此来降低开发成本。所以，这就要求我们能够自己先定义出硅前性能验证的目标、环境和方法。

设定目标

目前我们主要将性能验证主要侧重在负载测试和压力测试上面，来完成下面的目标：

证明系统（或者子系统）的性能是否符合产品要求。
衡量哪一部分的子系统会成为整个系统或者某些特性要求的瓶颈。

在我们开始性能测试之前，应该首先问一问自己“为什么我们要进行性能验证？”，因为只有朝着明确的性能目标方向，才能得出下面的一些测试数据：

数据并发量（concurrency）/吞吐量（throughput）：测试数据并发量是系统整体性能的考量，因为在某一个时间段，多个子系统会并行工作，而且共享一些网络和内存资源；测试吞吐量是就整个一条完整的数据通路，来测算出它的它的最大吞吐量或者传输速率，例如测试USB的传输速率。
响应时间：这集中体现在，处理器访问寄存器和存储器的读写回路延迟，也可以适用于其它协处理器或者DMA（Direct Memory Access）。

实际上我们很难在性能验证计划中具体描述出测试方式和场景，而性能验证计划又应该列在硬件设计之前。在实际项目中，我们不能很好地知道软件使用硬件的场景，已经应用软件如何调度不同硬件模块，所以我们只能首先将目光着眼于单个子系统的性能测试，或者通过测试单一的数据链路找到最薄弱的节点。因为上面这种方式可以将复杂的问题降维到可以理解可以描述测试场景的难度。

测试环境

理想地来看，如果测试环境贴近于用户实际使用的情况，我们得出的数据会更加真实有意义，然而作为硅前硬件实现阶段，我们与用户的距离又何其远。退而求其次，我们希望可以通过和固件开发团队合作，找到一些典型的子系统应用场景，在硬件仿真上实现来观察子系统的性能。

同时为了将测试的成本降低，我们尽可能选择原有的功能验证的环境，通过动态的环境配置或者仿真开关来实现监视系统性能的组件。这些监视性能的组件可以分为：

在线监视（online monitoring）：一般将一些监视器（monitor）绑定到目标模块或者总线上面，来动态监测目标的运算处理量或者数据传输速度。
线下分析（offline analysis）：将监视到的数据首先通过仿真记录下来，通过线下的脚本分析，绘制出性能的波动曲线。

验证方法

从性能验证流程来看，目前我们参照微软的性能测试方法学流程，它包括以下步骤：
构建验证环境：一般利用现有的功能验证环境，通过更新使其可以完成性能检测和分析的任务。
决定性能验收标准：在测试之前首先限定反馈时间、吞吐量、资源利用率等验收标准。一般而言，对于硅前测试，我们可以测出反馈时间和吞吐量，而资源利用率是一个系统概念，较难测试。
制定计划和测试用例：需要同系统人员、固件人员一同列出重要的测试场景，同时建立可以衡量性能的表格。
配置测试环境：如果环境足够灵活，我们甚至可以在递归测试（regression test）中开关性能检测功能，来平均衡量子系统的性能。
开发用例和测试：开发测试用例，提交和检测带验模块，收集性能检测数据。
分析结果、反馈和再测试：分析测试数据，提交性能报告，如果硬件性能与计划的性能之间有缺口需要硬件做出修改。而后在此测试，直到硬件性能符合预期，满足验收标准方可结束。


正如前面提到的，实际项目中的性能测试除了不规范和较难实现意外，也缺少明确的验收标准。这就使得不同验证人员编写的测试用例距离真实情况应用的差别不等，而且检查性能的标准也各不相同。目前，我们通过下面一些形式来帮助实现性能验证：
在芯片网络结构的端点处（network terminal）绑定总线协议的监测器，以此来在网络核心出检测芯片整体的通信情况，计算网络的实时吞吐量，以及单个挂接的子系统的数据传输速率。
将一些RTL仿真较为耗时的测试用例迁移到硬件加速平台，利用emulator来完成性能测试。
为测试用例提供一些宏定义用来做高密度数据传输，以此来保证有足够的数据量用来测试数据传输的饱和峰值。


我们下一篇也将是本系列的完结篇，回顾和展望将来的验证需求和发展趋势——《趋势展望》。