先啰嗦几句。其实老早就想写这个帖子，自己犯懒一直木有写。 前阵子写了一个初版，然
后发给了几个做验证的朋友看了看，普遍反映没看明白 . 说是我写的东西和我搭的
环境结合的太过紧密了，不结合代码，理解的不透彻。可惜代码是公司的，我不能把代码发
出来。 我后来写了一个带很多代码截屏的版本，但是很抱歉没法发到论坛上来。
我个人觉得下面的文字已经能表达我的想法和思想了，希望能对帖的有一点帮助吧。
---------------------------------------------
写这个文档的目的是让大家对搭建 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 脚本程序,大致描述一下功能。
评论0