整合多IP的SOC芯片的验证挑战和思路

71 阅读 0 评论 47 点赞

我是靠谱客的博主安静山水，最近开发中收集的这篇文章主要介绍整合多IP的SOC芯片的验证挑战和思路，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

本文以一个整合了ARM和多DSP核等IP的多媒体处理SOC芯片的验证项目为背景，介绍了项目中所采用的以覆盖率为目标，以随机验证为基础，自底向上的验证方法。文中结合了项目中的典型案例，针对SOC设计的特点，着重分析了如何建立带有完备的自检测功能的SOC验证环境和如何确立SOC验证功能点，即验证重点这两个随机验证工作中的难点。

This paper is based on a verification project of a multimedia-processing SOC chip, which integrates ARM, multi-DSP cores and other IPs. It introduces the coverage-driven, random-based, and bottom-up verification methodology which is well applied in this project. Giving the typical bugs met in the project as examples and taking into account the SOC design characteristics, this paper focuses on how to construct a complete self-check SOC verification environment and how to figure out functional coverage points or verification emphasis, which are the two major difficulties in random verification work.

关键词: IP, SOC, 功能覆盖率，随机验证

1. 引言

随着应用环境越来越复杂，对成本和性能的要求越来越高，SOC设计已经成为IC设计的一个趋势。SOC设计一般包括一个或多个处理器系统(处理器及其外设)，存储器，互连总线，高速接口模块（如千兆以太网，RapidIO, PCI-Express等）。SOC设计实际上集成了以往的一块板级系统，千万门以上的设计非常多见，如何验证如此复杂的系统，是摆在设计者面前的一个问题。此外，SOC系统中绝大多数的设计任务就是整合现有的IP，因此主要问题就在IP之间复杂的接口上，而不是IP设计本身。如果没有一套快速有效的验证方法，验证将成为严重制约SOC产品开发的瓶颈。

实际中，我们采用以覆盖率为目标的验证方法。在这个项目中，覆盖率为目标的验证思路得到了很好的贯彻。产品开发初始阶段，我们就定义好覆盖率，在随后的开发的每一个环节，覆盖率都被作为我们验证进程的衡量指标。到最后项目结束，覆盖率达到100％。下面着重阐述验证方法的几个重要方面。

2.1 验证目标

覆盖率是我们的验证目标。所谓覆盖率包括两方面，代码覆盖率和功能点覆盖率。代码覆盖率比较简单，现在大部分的仿真器都支持自动统计代码覆盖率。而对于功能点覆盖率，则需要设计者或者验证者确定，有很大的人为因素。如何确立合理的功能点，即如何抓住验证的重点，是验证的关键。一般来说，验证者需要根据产品需求书和设计说明书，抽象出产品的特性，再细化为具体的验证功能点。这一过程也需要设计者的参与，因为设计者可以从设计角度给出一些验证重点的建设性意见。对于SOC设计，由于其结构的相似性，有许多相似的验证重点，下一节对其做了一些总结。

2.2 验证流程

确立验证目标后，我们采用自底向上的验证流程。设计中重用的IP一般会提供相应的验证环境，主要的功能点覆盖率和代码覆盖率需要在IP的验证环境中达到。对于全新的设计，设计者需要建立子模块验证环境，来达到覆盖率的目标。而在系统级验证环境中，每个模块的输入激励的可控性受到很大的局限，因此覆盖的重点主要集中在IP之间的互连上。

2.3 随机验证

在以覆盖率为目标的验证方法中，随机验证是一个很重要的方面。测试功能点实际上最终被具体为某些参数范围。例如，数据包传输系统中，数据包的长度，各个字段的可能值等都可以被作为测试功能点；设计内部的状态，端口的变化等也可以被用作测试点。在写测试实例时，需要尽量随机化这些参数，从而产生随机的测试矢量。这些随机矢量被作为待测芯片的激励。而随机化的结果，可以被环境记录下来，用来分析功能覆盖率。

2.4 直接测试

随机测试是测试的主要手段，而直接测试作为辅助手段，也是必不可少的。在测试的最后阶段，覆盖率分析后，可以采用直接测试弥补少量随机测试很难覆盖的测试漏洞，这样的效率往往会比较高。另外，在验证环境不够稳定，或者少数测试情况环境很难支持自检测时，也往往需要采用直接测试。另外，直接测试也可以和随机测试相结合，某些测试参数固定，而另一些随机，这种直接随机测试的方法，在验证中使用的也比较多。

SOC设计具有很多共性，例如一般都是通过多个IP整合构建，一般都有处理器，存储器，寄存器等等。由于这些设计上的共性，在验证上也有很多共同的验证重点，本节结合项目中的具体例子，分析一些典型的SOC验证重点。

3.1 IP 之间的接口

比较大的SOC设计都包含多个IP，由于有些IP功能非常复杂和产品开发的市场压力，在系统级验证上很难覆盖到IP所有的功能。在有限的时间内，主要精力需要放在IP之间的互连接口上（当然，前提是IP提供者已经对IP进行了完备的测试）。在确定验证功能点时，需要考虑这一点。验证功能点可以包括端口所有支持的操作类型，端口信号的可能输入以及它们的翻转等。

MAC AHB接口的HLOCK输出并不完全符合AHB接口协议，但是这在访问其他外设（如带有AHB接口的DPRAM）时，并没有问题。但是，当从MAC发出的带有LOCK的一组传输想通过AHB2AHB桥接器时，却会导致输出端在NONSEQ传输和SEQ传输之间插入若干个IDLE控制，这是严重的接口协议的错误。

3.2 交换互连总线验证

在复杂的SOC中，交换互连总线可以作为独立的模块用于作为各个IP之间的互连。交换互连总线往往包括输入逻辑，地址译码，总线仲裁和输出逻辑几部分，可以完成数据流交换，地址分配，共享资源的优先级确定等功能。其作为IP之间接口模块，是数据流的必经通道，因此也是验证的重点。

交换互连总线的每个接口（主接口和从接口）都接有AHB 的eVC。AHB eVC可以产生随机激励，同时对每个接口进行一致性检测。在输入和输出接口之间有记分板（scoreboard）保证输入输出数据的一致性。由于环境简单，并且激励产生灵活，可以做大量的随机测试，从而保证所有关心的接口组合情况都被测试到。实践证明，这种测试方法非常有效，不仅抓到设计改动的问题，而且还暴露出参考设计中的一些潜在的问题。

3.3 处理器建模和验证重点

处理器是SOC系统的核心，一般完成控制，配置和计算等功能。处理器的验证可以包括以下几个方面：

3.3.1 中断的接受和响应

中断是处理器验证的重点之一。验证时需要考虑中断的不同触发类型：电平触发，沿触发和脉冲触发等等。验证中断时需要考虑两个方面：外设的中断是否能被处理器正确的检测到；处理器能够及时的清除中断。对于有多个中断的情况，还需要考虑中断是否同时发生，中断之间的优先级等等。

3.3.2 处理器对地址空间的操作

不同处理器有不同的地址空间分配，同一个物理单元(存储器或寄存器)也可以被不同的处理器以不同的地址访问，这里也存在处理器竞争，这些都是验证的重点。

处理器（如ARM）通过交换总线访问外设（如DMA），片选信号（CS）由交换总线译码产生，设计时为DMA预分配了32k的地址（片选信号CS由Addr[31:15]译码产生）。实际上，DMA的地址空间仅有4K（即只有12位地址输入），这样DMA的任意一个地址单元，对ARM来说，都有8种可以访问的地址（Addr[14:12]可以为任意值），这不是设计者所期望的。

3.4 存储器的验证方法和重点

在复杂的SOC设计中，存储器的规模一般也很大，如何快速有效的实现验证环境对存储器的自检测，并且确定存储器的验证重点，是SOC验证者需要解决的问题。

寄存器是硬件和软件的常用接口，一般分为以下几种：

3.6 性能验证

IP有自己的性能指标，但是由IP整合后的系统的性能指标是否满足产品需求说明书上定义的性能需求还需要做系统级仿真才能得到。一般来说，系统的性能不仅取决于硬件的结构，还和系统操作类型有关，例如，共享的资源被多个源点同时访问时，系统性能可能会受到影响。

4. 结论