企业官网建设流程全解析

做FPGA验证这一行，几乎没人能绕开仿真工具选择这道坎。早些年大家习惯直接用Vivado自带的Xsim，但碰到复杂testbench、UVM环境或者大工程回归时，Xsim的编译速度和波形调试效率确实让人有点着急。Modelsim作为老牌仿真器，胜在脚本成熟、上手快、波形界面顺手，所以在Vivado 2020.2这一代，很多人都会选择把它接到Modelsim 2020.4上做联合仿真。这篇文章就是我实际配置过程中的全记录，从安装准备、库编译、Vivado内调用，到各种报错和避坑经验，基本覆盖了你会遇到的九成问题。

如果你是第一次搞Vivado和Modelsim联合仿真，建议把整篇看完再动手；如果你已经配到一半卡住了，可以直接跳到对应章节找解决办法。整个流程本身不复杂，难就难在版本匹配、库编译路径、环境变量这些细节上，任何一环出错，启动仿真时就会弹出各种莫名其妙的错误。下面我把整个实战过程一步步拆开讲。

1. 为什么非要在Vivado里挂Modelsim

1.1 Xsim和Modelsim的差距在哪里

先说句公道话，Xsim并不是不能用，小模块、简单testbench，Xsim完全够用，而且和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在安装过程中会扫描已存在的仿真工具，如果先装了Modelsim，Vivado的某些配置向导能自动识别到Modelsim安装路径，省得后面手动填。当然，你完全可以先装Vivado再装Modelsim，后面手动配置路径也不影响使用。

安装过程有几个硬性要求：

1. 安装路径不能有中文，最好也不要有空格。建议直接默认的C:\Xilinx和C:\modeltech64_2020.4，不要为了整理磁盘搞什么C:\工具\FPGA\这种目录，Vivado和Modelsim对中文路径的兼容性都差，后面编译仿真库时会出现各种奇奇怪怪的报错。

2. Vivado安装时组件选择要注意，如果你需要仿真FPGA里的Xilinx IP核，建议把对应的器件系列都勾上，比如你的板子是Artix-7，就确保Artix-7系列的部分勾选完整。这里多说一句，Vivado安装时的组件选择直接影响后期仿真库编译，少了器件文件库就编不全。

3. Modelsim安装时最好选完整安装，别用精简版，后面跑UVM需要的库文件精简版经常缺。

2.3 License与系统环境变量配置

Modelsim启动时经常会弹出License checkout failed或者报找不到License，绝大多数原因不是License文件本身有问题，而是环境变量没配对。

Windows下，Modelsim SE版通常用的是LM_LICENSE_FILE，ModelSim 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主界面菜单栏，选择Tools>Compile Simulation Libraries，会弹出一个配置窗口。这里有四个关键配置项：

1. Simulator：下拉选择你安装的Modelsim版本。Vivado 2020.2会列出支持的Modelsim型号，通常情况下选择ModelSim SE/DE/PE，如果你安装的是Modelsim SE 2020.4，选这个没问题。需要注意，这里的选项名称和实际安装版本不需要完全一致，大致匹配就行，关键是ModelSim的架构位宽要选对。

2. Language：选择Verilog还是VHDL，或者全选。这里取决于你的工程语言，但建议直接全选，反正编译时间也不长，后期切换到其他语言时不用重新编译。

3. Simulator executable path：这个非常关键，要指向Modelsim的安装可执行目录，不是安装根目录。比如我的是C:\modeltech64_2020.4\win64，这里选到win64这一层。如果你填错了，Vivado会提示找不到vlib或vsim，但很多人在这一步会栽跟头，因为Vivado在填写路径时会把C:\modeltech64_2020.4作为默认可能的候选，但实际上它需要的是win64这个子目录。

4. 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菜单栏打开Settings>Tool Settings>Simulation，需要修改三项：

• Simulator：在Windows下选ModelSim Simulator。如果你用的Linux，也可以选QuestaSim，但这里不是讲Linux，Windows下就是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左侧找到SIMULATION>Run Simulation>Run Behavioral Simulation，Vivado会先自动编译设计文件和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实际上做了这几件事：

1. 生成一个行为仿真脚本，里面包含了项目的RTL文件列表、testbench文件列表、IP核文件列表。
2. 调用vlib创建work库。
3. 调用vlog或vcom把RTL文件和testbench编译进work库。
4. 调用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 -voptargs="+acc" 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 -voptargs="+acc"这里的+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 最常遇到的几个错误及解决对照表

把常见的联合仿真报错整理成了一张速查表，按错误类型检索效率最高：

6.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 关于运行性能的几点优化建议

最后分享几个提升联合仿真效率的小技巧，都是日常实际跑出来的经验：

1. 仿真库一定要放在固态硬盘上。Modelsim仿真过程中要频繁加载库文件，机械硬盘和固态硬盘的差距非常明显，库大一点差距是三倍以上。如果条件允许，把D:/Xilinx_SimLib放到SSD。

2. vsim时尽量用-voptargs="+acc"，但不要加+acc=rb这种限制参数。+acc会保留所有信号的可见性，方便调试，但也会降低仿真速度。如果只是跑最终回归而不需要看波形，可以用-voptargs="+acc=rn"限制访问级别，明显提升仿真速度。

3. 用run -all配合超时控制。在.do脚本里加一个run -all，然后设置一个onbreak和onfinish逻辑，可以让长时间仿真的流程可控。比如：

proc sim_timeout {} { echo "Simulation timeout, force stop." quit -code 1 } onbreak {resume}

这种处理方式在高强度回归中能帮你自动捕获死仿真。

4. 编译testbench时建议保留调试信息。vlog -sv默认会去掉大部分调试符号，如果后面需要用在Modelsim里做行号调试，可以加上-debug参数。代价是编译出来的文件更大，但调试效率提升明显。

7. 这一步做完，整个联合仿真脉络就清楚了

文章写到这里，安装、库编译、Vivado内调用、独立脚本跑仿真、报错排查这几个环节基本都过了一遍。从我自己的实际体验来说，最值得分享的一条经验是：首次配置联合仿真时，一定要先跑一个极简的测试用例，比如一个10行代码的计数器加上一个简单的testbench，把整个链路先打通。不要一上来就编译整个工程，那样报错了都不知道是自己配置的问题还是工程文件的问题。等最小用例通过后，再逐步加入真实的工程文件、IP核、UVM环境，每一步都确认无误再进行下一步。

另一条经验是关于仿真库的，编译仿真库这个动作虽然只做一次，但输出目录一定要保留好。我见过不少同事，换了台电脑或者重构了工程目录后，仿真库找不到了，只能重新编译一遍，白白等半小时。建议把编译库输出的目录固定放在一个稳定路径下，或者写一个自动编译脚本保存在代码仓库里，换环境时一键搞定。

要是你在配置过程中遇到了本地仓库里没有的报错，欢迎按照本文的思路逐步排查，顺序就是：环境变量 -> modelsim.ini -> 库编译 -> 仿真器设置 -> 工程配置 -> 脚本内容，这个排查顺序能覆盖绝大多数联合仿真的坑。