ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Vivado 2020.2与ModelSim 2020.4联合仿真配置全攻略

Vivado 2020.2与ModelSim 2020.4联合仿真配置全攻略 做FPGA验证这一行几乎没人能绕开仿真工具选择这道坎。早些年大家习惯直接用Vivado自带的Xsim但碰到复杂testbench、UVM环境或者大工程回归时Xsim的编译速度和波形调试效率确实让人有点着急。Modelsim作为老牌仿真器胜在脚本成熟、上手快、波形界面顺手所以在Vivado 2020.2这一代很多人都会选择把它接到Modelsim 2020.4上做联合仿真。这篇文章就是我实际配置过程中的全记录从安装准备、库编译、Vivado内调用到各种报错和避坑经验基本覆盖了你会遇到的九成问题。如果你是第一次搞Vivado和Modelsim联合仿真建议把整篇看完再动手如果你已经配到一半卡住了可以直接跳到对应章节找解决办法。整个流程本身不复杂难就难在版本匹配、库编译路径、环境变量这些细节上任何一环出错启动仿真时就会弹出各种莫名其妙的错误。下面我把整个实战过程一步步拆开讲。1. 为什么非要在Vivado里挂Modelsim1.1 Xsim和Modelsim的差距在哪里先说句公道话Xsim并不是不能用小模块、简单testbenchXsim完全够用而且和Vivado集成得最好点一下就能跑。但一旦进入稍微认真点的验证场景Xsim的短板就很明显了。第一是编译速度。大型设计加上多层UVM验证环境Xsim每次迭代都要重新编译大量文件等待时间明显比Modelsim长。Modelsim的增量编译做得更成熟改一个文件只重编相关依赖在大工程里节省的时间非常可观。第二是波形调试。Modelsim的wave窗口用起来更顺手支持批量信号拖拽、分组、颜色标记还能用add wave -hex这类命令精确控制显示格式。做协议级调试的时候这种细节效率差距会直接体现在你的加班时长上。Xsim的波形界面这几年进步不小但和Modelsim相比还是差点意思。第三是命令行和脚本化。Modelsim的可脚本化程度极高vlib、vmap、vlog、vsim这套命令用熟了以后你可以把整个仿真流程做成一个.do文件双击就跑完编译-仿真-出波形全流程。这在批量跑回归、自动验证的场景下几乎是刚需。Xsim当然也支持xsim命令但生态和资料远不如Modelsim丰富。1.2 什么场景才值得搞联合仿真不是所有项目都需要接Modelsim我个人的判断标准是这样的工程里用到了UVM验证方法学需要成熟的仿真器支持Modelsim对UVM的支持比Xsim更完整很多现成的UVM组件和示例都默认用Modelsim或Questa跑。需要跑大量回归用例希望有一套可以脱离GUI、命令行自动执行的仿真脚本方便集成到CI流程里。从老项目迁移来的testbench原本就基于Modelsim里面有大量.do文件、宏定义、老式写法直接在Vivado里用Xsim跑会很痛苦。处理FPGA 软核/SoC联调时Modelsim对总线协议仿真和存储模型的仿真速度更有优势。如果你只是写个简单的计数器模块验证一个组合逻辑功能那真没必要折腾联合仿真直接用Xsim跑反而更省事。联合仿真这件事适合在验证工作量上来了之后再搞。2. 版本选择与环境准备2.1 为什么偏偏是Vivado 2020.2 Modelsim 2020.4版本匹配这事说着简单做起来坑不少。Vivado官方对支持的仿真器版本有明确列表但那是“官方支持”实际工程里大家选版本考虑的因素更多。Vivado 2020.2在2020年下半年发布这一版相比2020.1修复了不少编译仿真库的问题同时兼容的第三方工具链范围也广了一些。Modelsim 2020.4是Mentor那边2020年的版本支持Windows和Linux双平台对SystemVerilog和UVM的支持已经很成熟。这两个版本搭配在一起是很多FPGA工程师实测比较稳的组合比Modelsim 2020.2配Vivado 2020.1靠谱也比2021之后的Modelsim和Vivado 2020.2的兼容性问题少一些。另外一个很现实的因素是License。Vivado 2020.2对Vivado ML Standard也就是之前的WebPACK支持的器件范围比早期版本更宽而Modelsim 2020.4这个版本在很多公司里已经有现成的授权不需要额外申请新版本的License省了不少事。2.2 安装顺序和路径注意事项关于先装Vivado还是先装Modelsim我的建议是先装Modelsim再装Vivado。倒不是说顺序颠倒就装不上而是Vivado在安装过程中会扫描已存在的仿真工具如果先装了ModelsimVivado的某些配置向导能自动识别到Modelsim安装路径省得后面手动填。当然你完全可以先装Vivado再装Modelsim后面手动配置路径也不影响使用。安装过程有几个硬性要求安装路径不能有中文最好也不要有空格。建议直接默认的C:\Xilinx和C:\modeltech64_2020.4不要为了整理磁盘搞什么C:\工具\FPGA\这种目录Vivado和Modelsim对中文路径的兼容性都差后面编译仿真库时会出现各种奇奇怪怪的报错。Vivado安装时组件选择要注意如果你需要仿真FPGA里的Xilinx IP核建议把对应的器件系列都勾上比如你的板子是Artix-7就确保Artix-7系列的部分勾选完整。这里多说一句Vivado安装时的组件选择直接影响后期仿真库编译少了器件文件库就编不全。Modelsim安装时最好选完整安装别用精简版后面跑UVM需要的库文件精简版经常缺。2.3 License与系统环境变量配置Modelsim启动时经常会弹出License checkout failed或者报找不到License绝大多数原因不是License文件本身有问题而是环境变量没配对。Windows下Modelsim SE版通常用的是LM_LICENSE_FILEModelSim DE版和PE版可能会用到MGLS_LICENSE_FILE具体用哪个取决于你的授权文件和安装版本。配置方式是在系统环境变量里新增一个用户变量变量名按你的软件要求填变量值指向License文件所在的完整路径注意是文件路径不是文件夹路径。Vivado的License配置相对简单在Vivado License Manager里加载一份有效的.lic文件就行。如果Vivado之前能正常综合和实现就说明License本身没问题不需要重复折腾。系统环境变量里还有两个值得关注的PATH建议把Modelsim的安装目录加进去比如C:\modeltech64_2020.4\win64。这样后面命令行里直接输入vsim、vlib就能启动不用每次写全路径。MODELSIM这个环境变量指向Modelsim的modelsim.ini文件位置。modelsim.ini是Modelsim的核心配置文件里面记录了各种仿真库的映射关系。如果你不设置这个变量Modelsim启动时会去当前工作目录找modelsim.ini找不到就用默认配置这会导致后续仿真时找不到你编译好的Xilinx库。配置完环境变量后建议重启或者重新登录一次Windows别图省事很多奇葩问题就是环境变量改了但没重新加载导致的。3. 编译Xilinx仿真库——联合仿真的核心门槛3.1 为什么必须单独编译仿真库Vivado里的IP核、原语、器件模型在仿真时都需要对应厂商库的支持。这些库包括unisims_ver、secureip、xil_defaultlib等等。问题是这些库文件不是以“可编译好”的形式直接提供给Modelsim用的它们是一堆Verilog/VHDL源文件需要用你安装的Modelsim工具链编译一遍生成这个仿真器能识别的库格式。这个编译过程就是Vivado里的“Compile Simulation Libraries”。理解了这一点你就能明白为什么网上很多人说“联合仿真的关键不是配置Vivado而是编译库”。库编译好了后面所有仿真都能跑库编译不对Vivado怎么设置都没用。3.2 图形化编译仿真库的详细操作在Vivado主界面菜单栏选择ToolsCompile Simulation Libraries会弹出一个配置窗口。这里有四个关键配置项Simulator下拉选择你安装的Modelsim版本。Vivado 2020.2会列出支持的Modelsim型号通常情况下选择ModelSim SE/DE/PE如果你安装的是Modelsim SE 2020.4选这个没问题。需要注意这里的选项名称和实际安装版本不需要完全一致大致匹配就行关键是ModelSim的架构位宽要选对。Language选择Verilog还是VHDL或者全选。这里取决于你的工程语言但建议直接全选反正编译时间也不长后期切换到其他语言时不用重新编译。Simulator executable path这个非常关键要指向Modelsim的安装可执行目录不是安装根目录。比如我的是C:\modeltech64_2020.4\win64这里选到win64这一层。如果你填错了Vivado会提示找不到vlib或vsim但很多人在这一步会栽跟头因为Vivado在填写路径时会把C:\modeltech64_2020.4作为默认可能的候选但实际上它需要的是win64这个子目录。Library output directory选择编译好的仿真库存放位置。建议放在独立的目录比如D:\Xilinx_SimLib\vivado2020.2_lib不要放在Vivado安装目录里也不要放在工程目录里。这样即使重建工程仿真库还能复用不用每次重新编译。再提醒一句这里依然不能有中文路径。基础配置填完后还有一个容易忽略的点就是Device families选择框。默认是全部系列都编译但全系列编译耗时会很长通常在半小时以上而且有些器件系列的库编译还可能因为网络或文件缺失报错。实际项目中只编译你正在用的器件系列就够了。比如你的板子用的是Artix-7那就只勾选Artix-7编译速度会快很多通常在几分钟内能完成。点击Compile按钮后Vivado会调用Modelsim的编译工具按器件系列逐个编译库。这个过程会产生大量命令行输出耐心等它跑完就行。编译完成后在输出目录里会生成一个modelsim.ini文件这个文件非常重要它在后续联合仿真中会自动映射这些仿真库。每次Modelsim启动时如果能找到这个modelsim.ini就会自动加载里面的库映射关系。3.3 命令行编译方式如果你习惯命令行操作或者需要在多台机器上批量编译Vivado也提供了Tcl命令方式。在Vivado的Tcl Console里直接执行compile_simlib -simulator modelsim -family artix7 -language verilog -dir D:/Xilinx_SimLib/vivado2020.2_lib -simulator_exec_path C:/modeltech64_2020.4/win64参数含义和GUI界面一致-simulator modelsim指定仿真器类型-family artix7如果要多个系列可以用-family {artix7 kintex7}这种写法-language verilog或者all-dir编译输出目录-simulator_exec_pathModelsim的可执行目录命令行方式最大的好处是参数可以复用保存成一个Tcl脚本以后在新机器上一条命令搞定。3.4 验证编译结果编译完成后用文本编辑器打开输出目录下的modelsim.ini你会发现里面有一段[Library]映射类似[Library] xil_defaultlib D:/Xilinx_SimLib/vivado2020.2_lib/xil_defaultlib unisims_ver D:/Xilinx_SimLib/vivado2020.2_lib/unisims_ver secureip D:/Xilinx_SimLib/vivado2020.2_lib/secureip这几行说明库已经成功编译并完成映射。如果缺失某个关键库那就要回头检查是不是编译过程中某一步报错了。另外建议把这个modelsim.ini文件保留好后面在Vivado里配置仿真库路径时可以直接指向这个文件所在的目录。注意编译库时如果提示找不到vlib、vlog或者Failed to start Compile Tcl task这类错误99%是Simulator executable path填错了。去检查一下Modelsim安装目录里win64文件夹是否存在然后把路径指过去。4. 在Vivado里配置Modelsim并跑起第一个仿真4.1 Vivado仿真器设置库编译完成后接下来就是在Vivado工程里切换仿真工具。在Vivado菜单栏打开SettingsTool SettingsSimulation需要修改三项Simulator在Windows下选ModelSim Simulator。如果你用的Linux也可以选QuestaSim但这里不是讲LinuxWindows下就是Modelsim。Simulator Language建议选Verilog或者根据工程实际语言选但要注意如果工程混合了VHDL和Verilog这里选Mixed更稳妥。我个人习惯建议选Mixed虽然编译时间稍微长一点但可以避免后续因为语言设置导致的库映射问题。Compiled library location这里填上一步编译出来的仿真库输出目录也就是包含modelsim.ini的目录比如D:/Xilinx_SimLib/vivado2020.2_lib。这里有个小坑Compiled library location这个路径有时候在GUI里点浏览选了路径应用后还是会报错。如果遇到这个情况可以手动把路径复制进文本框用正斜杠/代替反斜杠\能规避一部分路径解析问题。Vivado设置里其实还有一个Simulation下的-simset相关选项一般不需要动默认的就行。4.2 准备testbench并运行行为仿真在Vivado的Sources窗口里给设计添加仿真激励文件也就是我们的testbench。这一步要注意testbench文件要放在Simulation Sources目录下不是在Design Sources下面。操作方式是在Sources窗口右键选择Add Sources选择Add or create simulation sources然后添加文件。如果你直接把testbench放在设计源文件里Vivado会把它当成一个可综合模块来对待综合时会报错或者综合出一堆你没想过的逻辑。写好testbench后在Flow Navigator左侧找到SIMULATIONRun SimulationRun Behavioral SimulationVivado会先自动编译设计文件和testbench然后调用Modelsim启动仿真。第一次启动时Vivado会生成一个.do脚本脚本名一般是sim_1_behav.wcfg对应波形配置以及自动生成的使用库映射的脚本然后把它传给Modelsim执行。正常情况下Modelsim界面会自动打开波形窗口里能看到你的信号。如果这一步能跑通说明整个联合仿真的核心链路已经打通了。4.3 手动添加库映射的姿势有经验的读者应该知道上面这个流程看似简单但实际经常会遇到一个经典问题Vivado自动生成的仿真脚本里默认是用xil_defaultlib映射的方式引用IP核模型的而xil_defaultlib这个名字本身不是Vivado模拟器自动能识别的它需要在modelsim.ini的[Library]段里有映射。我们的仿真库编译完成后modelsim.ini里已经有了xil_defaultlib的映射。所以在理论上Vivado启动Modelsim时会通过环境变量MODELSIM指向这个modelsim.ini从而自动加载映射关系。如果这一步没配置好启动Modelsim时就会出现# Error: Cannot find module 你的IP核名 in library xil_defaultlib遇到这种情况先检查环境变量MODELSIM是否指向了编译输出目录下的modelsim.ini。如果没有手动补上。然后重启Vivado重新跑仿真。如果问题依旧还可以在Vivado的Tcl Console里手动添加库映射set_property -name {xil.sim.modelsim_lib_path} -value {D:/Xilinx_SimLib/vivado2020.2_lib} [current_project]然后重新运行仿真。这个方法本质上是告诉Vivado编译好的仿真库在哪个位置让Vivado生成的仿真脚本能带上正确的-L参数。实测下来这个属性设置对解决IP核找不到的问题很有效。4.4 从Vivado启动的底层发生了什么理解这一层排查问题会从容很多。当你在Vivado里点Run Behavioral Simulation时Vivado实际上做了这几件事生成一个行为仿真脚本里面包含了项目的RTL文件列表、testbench文件列表、IP核文件列表。调用vlib创建work库。调用vlog或vcom把RTL文件和testbench编译进work库。调用vsim加载顶层模块进行仿真同时打开波形窗口。如果你在Modelsim的命令行里看到了类似这样的输出# ModelSim vlog 2020.4 Compiler 2020.04 Apr 27 2020 # ** Note: vlog: Compiling source file C:/Project/tb_top.v说明Vivado已经成功调起了Modelsim的编译器。如果在这个阶段报错说明前面的库编译或环境配置有问题。如果你的Modelsim窗口根本没弹出来那问题往往出在Vivado的Tools Settings里要么仿真器设置不对要么路径配置有问题。5. 脱离Vivado用Modelsim独立仿真的进阶玩法5.1 什么情况下需要脱离Vivado虽然从Vivado直接启动Modelsim很省事但实际工作中经常遇到必须脱离Vivado独立仿真的时候。最常见的场景是跑回归测试设计不变testbench不变只是换一组测试参数或约束变量跑一轮回归。如果每次都打开Vivado工程等Vivado加载IP核和工程信息效率太低了。我自己的习惯是对于一个工程先把Modelsim独立仿真脚本写好日常开发用Modelsim命令行跑仿真Vivado只用来做综合和实现。这种方式在大型FPGA项目里非常普遍尤其是那些每天要跑几百个用例的验证环境下能不能脱离GUI自动化执行直接决定了工作效率。5.2 一个可直接复用的.do脚本模板脱离Vivado跑仿真的核心是写好.do脚本。这里给一个我实测可用的模板工程里用了Xilinx的FIFO IP核和一个简单的顶层设计# 清空之前的仿真状态 quietly set StdArithNoWarnings 1 onerror {resume} # 创建/映射工作库 if {![file exists work]} { vlib work } vmap work work # 映射Xilinx仿真库 # 这里假定modelsim.ini已经在编译库输出目录下 # 并且MODELSIM环境变量已指向该ini文件 vmap unisims_ver D:/Xilinx_SimLib/vivado2020.2_lib/unisims_ver vmap secureip D:/Xilinx_SimLib/vivado2020.2_lib/secureip vmap xil_defaultlib D:/Xilinx_SimLib/vivado2020.2_lib/xil_defaultlib # 编译设计文件 vlog -sv -work work \ C:/Project/rtl/top.v \ C:/Project/rtl/fifo_wrapper.v \ C:/Project/rtl/axi_lite_slave.v # 编译testbench vlog -sv -work work \ C:/Project/tb/tb_top.sv # 启动仿真 vsim -voptargsacc work.tb_top # 添加波形 add wave -divider Top Level add wave -hex /tb_top/clk add wave -hex /tb_top/rst_n add wave -hex /tb_top/wr_en add wave -hex /tb_top/rd_en add wave -hex /tb_top/fifo_din add wave -hex /tb_top/fifo_dout add wave -hex /tb_top/fifo_full add wave -hex /tb_top/fifo_empty # 运行仿真 run -all这套脚本的核心逻辑很简单建立work库 - 映射Xilinx库 - 编译RTL和testbench - 启动仿真 - 添加波形 - 运行。5.3 手动脚本里的关键细节这个模板里容易踩坑的有几点第一vsim -voptargsacc这里的acc表示保留全部信号的访问能力如果你的信号被优化掉了波形窗口里会看不到内部信号或出现无法添加信号的情况。有些老教程里写的是vsim -novopt work.tb_top在Modelsim 2020.4里-novopt选项已经被标记为obsolete直接传上去会报错。这也是网上很多老脚本在新版本Modelsim上跑不通的原因之一看到-novopt相关的错误直接删掉就行。第二add wave -hex后面的信号路径必须以/tb_top/开头这是Modelsim的格式要求。如果你不确定信号名可以在Modelsim的Objects窗口里复制信号名或者先run -all跑完然后通过wave窗口手工添加信号。第三脚本里如果用到Xilinx的FPGA原语或者IP除了unisims_ver和secureip之外还可能需要映射unimacro_ver。原语和宏模型的区别是原语是底层硬件模型宏是功能模型。如果你工程里用了很多Xilinx原语建议把unimacro_ver、unimacro一起映射上免得仿真时出现模块引用找不到的错误。5.4 把脚本和Vivado工程关联起来还有一个比较实用的做法是把.do脚本放到Vivado工程目录下的一个固定文件夹里比如./sim然后在Vivado里通过Settings - Simulation - Simulation Script指定启动仿真时默认使用的脚本。这样Vivado启动仿真时也会自动读取这个脚本实现“既可以从Vivado跑也可以用Modelsim独立跑”的双轨制。不过要提醒一点Vivado启动仿真时会优先使用它自己生成的编译脚本如果你指定了自定义脚本要注意脚本里的文件列表要和工程保持一致否则很容易出现编译文件不全导致的报错。我自己更常用的方式是在Modelsim里独立跑仿真时用自定义脚本在Vivado里跑仿真时用默认流程两者互不干扰。6. 高频报错与避坑实录6.1 最常遇到的几个错误及解决对照表把常见的联合仿真报错整理成了一张速查表按错误类型检索效率最高报错/现象根本原因解决方案# ** Error: (vsim-3193) Could not find module in library worktestbench顶层模块没编译进去或者名字写错了检查.do脚本里编译的文件列表检查vsim后面的顶层模块名大小写# ** Error: Cannot find module IP名 in library xil_defaultlib仿真库没编译全或者modelsim.ini缺少映射重新编译仿真库确认输出目录里有modelsim.ini检查MODELSIM环境变量vsim: Error: -novopt argument is not supported旧教程的-novopt选项已在新版Modelsim废弃删掉-novopt改为-voptargsacc# Fatal error in process: License verification failedLicense环境变量不对或License过期检查LM_LICENSE_FILE/MGLS_LICENSE_FILE是否正确指向License文件波形全为红色或高阻态信号未初始化或者复位没有生效或者输入没有驱动检查testbench里的复位逻辑和initial块用force命令手动赋值测试Vivado里Implement Design进度条出现红叉时序约束没满足或者布局布线出错查看implementation日志中未满足的时序路径检查时钟约束是否完整编译仿真库时卡住不动部分器件系列的库文件缺失或者网络问题只勾选当前需要的器件系列关掉杀毒软件后重新编译Modelsim启动后找不到modelsim.iniMODELSIM环境变量没设置在系统环境变量中新增MODELSIM指向编译输出目录下的modelsim.ini6.2 波形是红线、高阻态和未知态的排查思路这是搜索热度很高的一类问题也是仿真新手最容易被劝退的地方。波形显示红线在Modelsim里意味着信号值是X未知或者Z高阻态出现这个现象的原因通常是以下四种之一第一种testbench里没有给复位信号赋初值。很多FPGA设计依赖外部复位信号把内部寄存器和状态机拉到已知状态如果testbench里没写rst_n 0; #100; rst_n 1;这样的初始化逻辑那内部寄存器在上电后的初始值就是未知态反映在波形上就是一堆红线。解决方法是写一个标准的复位序列并且保证复位释放前所有模块已经稳定工作。第二种输入信号没有驱动。检查一下testbench里是否给每个输入端口的信号都赋值了wire类型如果一直没人驱动默认值是高阻态波形上就是Z。这里要分清reg和wire类型的区别经常有人把所有信号都声明成wire然后发现仿真波形全不对。第三种是阻塞赋值和非阻塞赋值的混用问题。在always块里如果时钟驱动逻辑里混用了和很容易产生仿真时的竞争冒险现象导致信号在某一时刻出现X态。建议遵循一个简单规则组合逻辑用阻塞赋值时序逻辑用非阻塞赋值。第四种仿真时间太短信号还没来得及稳定下来。比如复位需要100ns才释放你run -all总共才跑了50ns什么都没执行完波形当然什么都有问题了。先检查你的仿真运行时间设置。6.3 综合实现阶段的两个高热度问题热搜词里的vivado implement design变红和vivado生成比特流失败本质上是综合和实现阶段的问题虽然属于后端范畴但在联合仿真联调时也经常被问到。Implement Design变红最常见的触发原因是时序违规。检查方法是打开Implementation后的Report Timing Summary看里边的TNS和WNS如果有负值说明有路径没满足时序约束。处理方法通常是增加流水线级数、优化关键路径的组合逻辑、或者调整Pblock约束。生成比特流失败则可能是多种原因叠加比如I/O标准没配对、约束文件里有语法错误、或者实现阶段本来就有未解决的错误。遇到这类问题不要只看最后的弹窗去查看runme.log里的具体报错信息搜索关键词[ERROR]或ERROR:定位真正出错的位置。这两个问题虽然不在仿真的范围里但工程做大了之后仿真通过和上板成功之间的距离就是靠这些细节填上的。提前了解常见的报错模式能帮你省不少调试时间。6.4 关于运行性能的几点优化建议最后分享几个提升联合仿真效率的小技巧都是日常实际跑出来的经验仿真库一定要放在固态硬盘上。Modelsim仿真过程中要频繁加载库文件机械硬盘和固态硬盘的差距非常明显库大一点差距是三倍以上。如果条件允许把D:/Xilinx_SimLib放到SSD。vsim时尽量用-voptargsacc但不要加accrb这种限制参数。acc会保留所有信号的可见性方便调试但也会降低仿真速度。如果只是跑最终回归而不需要看波形可以用-voptargsaccrn限制访问级别明显提升仿真速度。用run -all配合超时控制。在.do脚本里加一个run -all然后设置一个onbreak和onfinish逻辑可以让长时间仿真的流程可控。比如proc sim_timeout {} { echo Simulation timeout, force stop. quit -code 1 } onbreak {resume}这种处理方式在高强度回归中能帮你自动捕获死仿真。编译testbench时建议保留调试信息。vlog -sv默认会去掉大部分调试符号如果后面需要用在Modelsim里做行号调试可以加上-debug参数。代价是编译出来的文件更大但调试效率提升明显。7. 这一步做完整个联合仿真脉络就清楚了文章写到这里安装、库编译、Vivado内调用、独立脚本跑仿真、报错排查这几个环节基本都过了一遍。从我自己的实际体验来说最值得分享的一条经验是首次配置联合仿真时一定要先跑一个极简的测试用例比如一个10行代码的计数器加上一个简单的testbench把整个链路先打通。不要一上来就编译整个工程那样报错了都不知道是自己配置的问题还是工程文件的问题。等最小用例通过后再逐步加入真实的工程文件、IP核、UVM环境每一步都确认无误再进行下一步。另一条经验是关于仿真库的编译仿真库这个动作虽然只做一次但输出目录一定要保留好。我见过不少同事换了台电脑或者重构了工程目录后仿真库找不到了只能重新编译一遍白白等半小时。建议把编译库输出的目录固定放在一个稳定路径下或者写一个自动编译脚本保存在代码仓库里换环境时一键搞定。要是你在配置过程中遇到了本地仓库里没有的报错欢迎按照本文的思路逐步排查顺序就是环境变量 - modelsim.ini - 库编译 - 仿真器设置 - 工程配置 - 脚本内容这个排查顺序能覆盖绝大多数联合仿真的坑。
返回列表