对于非微电子专业做FPGA的同学们来讲，常常把仿真验证环境的搭建给忽略了，为了追求所谓的“高效”，自己写的代码根本就没怎么仿真验证过，就急急忙忙的上板调试。有的同学说也做过仿真啊，后来一看发现竟然是用Vivado等FPGA综合工具自带的仿真器来简单的仿真了一下，其实这些都还仅仅是停留在模块级的个别功能点仿真。一个通信的FPGA样机或者是一款ASIC芯片的仿真验证，是需要仔细把所有的功能点细分之后串联起来做出来一个兼顾软硬件及各种应用场景的全流程的仿真验证。类似的有各种成熟的方法，如UVM等，但对于初学者而言，其实用ModelSim完全可以搭建出来一个稍微像样的可回归的能够看覆盖率的仿真验证环境的。 近期发现很多同学不重视仿真验证环境搭建，认为没必要搭建仿真验证环境，结果没有充分验证的代码上板后发现BUG，费了长达一两周的时间不断的添加追踪信号看波形终于定位到了问题，结果一看是一个逻辑错误，用仿真的方法完全可以复现，如果有仿真环境，发现问题定位问题并解决问题可能就是一个小时就可以搞定的事情，结果因为没有仿真验证环境白白的浪费了大量的时间。 本文介绍的仿真验证环境搭建方法，没有涉及Vivado相关IP等相关的处理，如果想了解可参看文末链接，也可以参看本公众号之前的文章：《网络交换FPGA-20200716》超详细往期回顾，还不赶快阅读？，文中有“工具使用调试技巧及时序约束”专题相关的系列文章。
sim文件夹下存放仿真环境搭建的各种文件。
testbench下存放最顶层的testbench.v；bfm文件夹下存放以太网phy的简单模型产生以太网数据包的激励，时钟复位产生模块及数据对比模块；filelist文件夹下存放验证环境中所有的.v文件列表文件，为了看覆盖率，一般要把设计代码文件列表和仿真代码文件列表分开成两个不同的文件（windows下自动生成verilog列表文件的源码本公众号之前也分享过，详见如何快速生成Verilog代码文件列表？（内附开源C代码））；in_out下就存放每个不同的测试例对应的激励数据包和经过MAC核控制器后出去的数据包；run目录下存放运行的批处理文件和sim的tcl脚本文件；testcase下存在各种不同的测试例。
二、编写脚本
脚本分为run.bat批处理脚本和sim.do两个文件，都在上述run文件夹下，run.bat如下：
其中vsim -c 一行中的-c用来表示是否启动Modelsim的图形界面，有-c就表示启动图形界面，没有就表示不启动。
sim.do就比较简单了，就是完成建ModelSim工程及仿真等动作：
需要注意的一点是，上面把仿真代码文件列表和设计代码文件列表分开后，就可以单独的vlog，同时给设计代码添加上看覆盖率的命令。
本文后续内容是某天所做的更改记录，大家可以通过这些记录便能看出搭建改环境的一些较为核心的内容。
1、在data_cmp.v模块增加输入信号testcase_name，将测试例名字引入数据包比较模块，利用testcase_name信号，可以每次测试不同测试例的时候在数据记录文件夹in_out里面可以产生不同的数据记录log文件。
具体截图如下：
上图中增加了INITIAL_DATA_CMP的task，可以每次在不同的测试例开头对整个芯片进行复位的时候启动该task，即可建立对应该testcase的记录文件。
目前存在的问题是最开始复位的时候，testcase_name还未有实际的测试例名字，导致会产生两个没有用的文件。如下图：
2、在data_cmp.v中增加名为OVER的task，在每个测试例运行结束后可以关闭掉为该测试例新建的文件指针。
OVER任务具体实现如下：
在不同的testcase末尾调用该task：
3、手动将文件列表文件rtl.f拆分成设计代码文件列表hdl_filelist.v和仿真代码文件列表sim_filelist.v。
并修改运行脚本，使得运行结束后可以看到设计代码文件的覆盖率。
修改批处理文件，使用modelsim图形界面的方式
发现第二个测试例中间的数据包计数未从0开始，修改代码
在所有testcase中增加一行代码，让data_cnt和i都从0开始。
修改后就能每个testcase都从0开始运行：
此时在modelsim图形界面下也能看到设计代码对应的覆盖率情况：
双击某个文件就能打开对应代码是否被验证到的情况：
目前只是验证了百兆模式下100个随机帧和千兆模式下100个随机帧，大家可以在上面的基础上不断的去增加测试例。后续内容就需要大家不断的增加测试例来完成对所有代码的全覆盖仿真，并且在此过程中也能够对MAC核的各种功能更加的熟悉。
感兴趣的同学可以留言邮箱地址索要完整仿真验证环境工程。
THE END
最后附上本公众号之前写的有关仿真验证环境搭建的系列文章：
责任编辑：潘伟涛
