IC 验证篇（09-04）关于 SoC 验证和 DEBUG 技巧

芯片原厂必学课程 - 第九篇章 - IC 验证篇

09-04 关于 SoC 验证和 DEBUG 技巧

新芯设计：专注，积累，探索，挑战

引言

  NOTES：本文来自《芯片原厂必学课程 - 第九篇章 - IC 验证篇》技术专栏

---

🌏 一、系统 SoC 验证

✅ 1. 按照阶段分类

  ✉ 前仿：指的是根据中间版，最终版的 RTL 代码进行功能上的验证

  ✉ 后仿：指的是根据中间版，最终版的 NETLIST + SDF 进行的后仿回归验证，其中根据 SDF 带电和不带电划分成了功能仿真、功耗仿真以及 PG 仿真

功能仿真：主要确定功能是否正确，内部 CLK 以及外部 IO 的时序约束是否 OK
功耗仿真：主要确定各个模块的 POWER 是否符合预期，是否满足 SPEC 要求
PG  仿真：主要确定 ULP 设计流程是否正确，POWER 界面处理是否干净，特殊信号处理是否按照要求

✅ 2. 按照方式分类

  ✉ 主要是划分为 UT 单元测试，IT 集成测试，ST 系统测试

  ✉ 这里主要详细描述一下 ST 系统测试：ST 主要是按照真实的 CPU 行为，编写 C 代码，配置相关的寄存器，进行数据的处理，通过 C 代码编译出 HEX 文件，然后 LOAD 到系统中的 RAM and SDRAM 中，释放 CPU 复位，令其读取与执行 RAM and SDRAM 中的指令和数据，仿真完成之后，查看 LOG or MEM_COMPARE or TXT or WAVE，确认 CASE 是否正常结束

---

🌏 二、验证 DEBUG 技巧

✅ 1. DEBUG 思路

  ✉ 执行仿真之前，验证人员需要了解清楚仿真 PATTERN 的主要测试内容，测试方法，控制流程等等，而这些内容全部记录于 PATTERN LIST 中

  ✉ 在设计 PATTERN 的时候，可以增加 PATTERN GOTO 的打印，这是非常必要的，一方面可以协助验证人员定位当前 PATTERN 的运行情况，另一方面也可以证实软件程序是否按预期去执行

✅ 2. DEBUG 情况

  ✉ 一种是直接显示 FINISH，不过报了 MEM_COMPARE FAILED：这种 CASE 需要查看 MEM_COMPARE.TXT 文件里面的数据信息，根据 具体的提示，如哪一段地址的数据对比失败了，如对比失败的错误类型是只错了若干个字节还是错了一整大段，亦或是全错等等，验证人员根据错误发生的规律，通过自己的逻辑和经验，反向推断 CPU 和 MASTER 的行为，如到底是哪些配置的不合理导致的对比失败，从而定位根因

  ✉ 一种是直接显示 FAILED：这种 CASE 是 PATTERN 里面进行了一些状态或者数据的判断，发现不符合预期，于是直接打印了 PATTERN GOGO 令仿真直接失败，这种情况下可以直接从打印错误的地方追溯到产生差异的点，从而定位根因

  ✉ 一种是 PATTERN 无法结束的情况：这种情况的话可能是仿真时间设置过短，导致 PATTERN 还没有完成就强行结束仿真，也可能是软件程序的异常情况，检查是否存在波形文件，查看 CPU 的 LOG，若是 LOG 没有内容的话说明 CPU 没有跑起来，或者是 CPU 的 LOG 的时间和仿真时间对不上，这种较大的概率是由于 CPU 读取到了不定态数据从而导致挂死

  ✉ 后仿阶段使用的是真实的 NETLIST，没有 CPU LOG，此时 DEBUG 较为困难，不过主要是时序上或者仿真的环境设置上的问题导致 PATTERN 跑不通的

✅ 3. DEBUG 技巧

  ✉ CPU 读红：访问的寄存器空间，SRAM，DRAM 等内容可能没有初始化，数据通路上相关控制信号可能存在不定态，访问的 DFF 没有初始值

  ✉ MEM_COMPARE FAILED：数据比对的起始地址和结束地址不对，比对的长度并非一个字的 WORD 对齐，源地址和目标地址全 0 或者全 X

  ✉ CPU 不打印 LOG：存在上述的可能，CPU 没有时钟或者复位没有释放，BROM 中没有释放跳转指令

  ✉ 仿真没有波形：设计上存在逻辑环，仿真无法进行却又结束不了，环境问题，波性文件存放错误或者指定错误

  ✉ CPU 行为正常但是 PATTERN 挂死：接口相关的问题，CPU 在等待状态位，程序 BUG

  ✉ CPU 返回地址返回非预期数据：确认数据最先出错的位置，检查 PATTERN 是否设置缺漏或者错误

  ✉ CPU LOG 存在循环或者异常跳转：栈空间可能存在异常