如何搭建SoC项目的基本Testbencheetop.pdf

先啰嗦几句。其实老早就想写这个帖子，自己犯懒一直木有写。 前阵子写了一个初版，然 后发给了几个做验证的朋友看了看，普遍反映没看明白 . 说是我写的东西和我搭的 环境结合的太过紧密了，不结合代码，理解的不透彻。可惜代码是公司的，我不能把代码发 出来。 我后来写了一个带很多代码截屏的版本，但是很抱歉没法发到论坛上来。 我个人觉得下面的文字已经能表达我的想法和思想了，希望能对帖的有一点帮助吧。 写这个文档的目的是让大家对搭建 SoC 项目的 Testbench 有一个比较清晰的认识，可以根据 这个文档来一步一步的搭建起一个 SoC 项目的基本的 testbench。本文档重点是指导大家搭 建基本环境，以及能解决搭建 Testbench 过程中容易遗漏的问题或者容易遇到的 “地雷”。 我搭的 SoC 项目的 testbench 会有一些相对特殊的点： 1） 要有嵌入式的软件。这里包括两部分，一是初始化的 bootloader （一般是固化在rom 或者 存放在外部的 flash 里），一是 boot 起来以后放在外部易失性存储介质上的应用层的程序。 2） 正常启动起来（一级 boot 可以切到应用程序了）以后，为了简化流程，我们要使用 ISS 的 环境。 这是比较特殊的一个点 3） 环境主要脚本的维护和修改。主要是单个仿真和批量仿真（regression）核心脚本 4） 为了优化仿真和编译速度，我们要能把不用的模块 dummy 掉。 5） 文件列表的处理 6） SoC 软件与 Testbench 都能访问的 “共享空间”的处理 7） 公用函数的准备，比如根据 CPU 看到的地址空间直接访问外部 DRAM 的数组，进行初始化写、 数据写和数据读操作。 8） 环境变量的维护。 9） Define 文件的维护 10）DDRC 的替换（一个是AXI_SLV_VIP 的替换，一个是简单AXI_SLV 模型的替换） 磨刀不误砍柴工，把需要的东西提前准备好，搭建Testbench 就像搭积木一样简单快速了。 环境变量维护 使用 module 工具来维护整个项目的环境变量。目的是为了让项目上的工程师都使用统一的 环境（主要是工具版本和环境变量）。 核心脚本的维护 两个脚本：run_sim 和 regress。 run_sim 负责提交单个仿真任务，regress 负责提交批量 仿真任务。两个脚本已经使用了很多项目了，脚本的具体说明我以后专门开专题讲。在这里 只提醒一下，run_sim 脚本通常需要根据不同的项目做微小的改变。 run_sim 和 regress 都是比较大的 perl 脚本程序,大致描述一下功能。 run_sim 脚本功能 1）为每个仿真产生仿真目录。仿真的目录里应该包括文件列表（硬件和软件）、编译和仿真 命令（注意包括嵌入式软件的 MakeFile）、提前建立需要的子目录、和单个仿真对应的文件 链接（比如维护的 C 的测试主函数、扩展的随机类的 SV 文件、一级 bootloader 文件的链接）、 define 文件、本仿真的重构命令（这是一个容易忽略的，一旦你跑 regression 的时候某个 仿真失败，你又不想在出错的目录下重新仿真，用这个重构命令文件就可以直接提交）。 2）各种option 的维护。比如不同仿真需要不同的 define、编译和运行 option、dump 波形 的 scope 以及层次 regress 脚本功能 regress 脚本比较简单，要吃一个由很多 run_sim 仿真命令组成的命令集文件。用 regress 脚本把这些仿真命令提交到工作站上去。需要注意的是：有时候可能会有一些公共的 option 或者 define，比如打开 coverage 收集、某个 define 要应用到整个 regression 里。所以 regress 脚本要能支持对所有 run_sim 命令添加 option 的功能。 产生 dummy 文件 使用 gen_dummy_file 脚本来产生 dummy 文件。设计工程师可能也要维护一个 module_dummy.v 的文件用于做 integeration，验证工程师产生的 dummy 文件记得名字不要 和设计自己维护的文件重复了。 为什么不使用设计维护的文件？因为一个是设计维护的文件在 integration 以后很可能就 不再维护了；另一个是设计维护的文件可能 output 全是 assign 成 0 的，但是对于模块输出 的pready\CEN 等信号最好 assign 成 1，否则