在virtual prototyping的过程中，不单会有SystemC参与到将各个子系统独立开来，分而治之的方法，也有通过将C/C++或者Matlab/Simulink等的算法模型置入到SystemC的环境中进行联合仿真的需求。对于后面这些语言模型置入到SystemC环境中，它们有着完善的接口，而在之前的文中我们也介绍了如何将C/C++和SystemC模型置入到SV/UVM环境中进行联合仿真。那么，对于一个纯粹的硬件算法模块，如果验证工程师在前期得到的是Matlab/Simulink模块，那么他在前期验证的过程中就会有需求将算法模块置入到UVM环境中进行联合仿真。而且，在多数情况下，验证工程师也应当避免对算法模型进行二次转换为C/C++模型或者SV模型，因为这不但意味着额外的工作量，而且依然有可能在模型转换的过程中出现失误。如果转换的模型之间本身存在着不匹配的情况，那这无疑增加了后期调试的难度。

那么接下来，我们就算法模型嵌入到UVM环境中的这一需求出发，看如何实现这两种模型之间的联合仿真。首先我们需要考虑的是，Matlabe和Simulink模型都会在Matlab软件中独立运行，而与UVM环境之间的并行进行的。这一点要与之前的C/C++/SystemC与SV/UVM的联合仿真区分开来，因为后面的这些仿真可以只依靠仿真器来实现（所有的仿真器都已经内嵌C调试器），所以无论是单顶层（SV/UVM调用C/C++一侧），还是双顶层（SV/UVM与SC独立运行），都不存在仿真器以外还需要别的软件参与到联合仿真中来。而在UVM于Matlab之间并没有直接的库来实现通信，而C接口在它们之间则起到了“中转站”的作用，这是由于SV与C的DPI接口、以及Matlabe所提供的C库可以直接控制Matlab的执行引擎。因此，我们在接下来的论述中主要就围绕着UVM-C-Matlab之间是如何完成间接通信的。

由于Matlab自己提供C的接口库，用户可以通过调用C函数来触发和结束Matlab、传递和得到数据、以及向Matlab发送其它的控制命令。这些Matlab提供的C API包括有：

• 打开和关闭Matlab的执行引擎

• 传递和得到变量数据

• 向Matlab命令窗口（console）传递指令

这些指令可以在Matlab的安装头文件“engine.h”中找到，用户可以在Matlab的安装目录中找到由C调用Matlab的例子$MATLAB/extern/examples/eng_mat/engdemo.c。

#include “engine.h”

main () {

Engine *ep;

ep = engOpen(‘’)

}

有了Matlab与C之间的通信，利用SV DPI的接口就顺利一些了。用户可以进一步将"engine.h"中定义的C函数再导入到SV中。

import “DPI-C” function void engOpen();

借助上面导入的函数，可以定义一个面向Matlab控制的engine class，这个类可以容纳上面导入的所有DPI函数。该类的实现方式如下：

class engine_example;

 function void engOpen ();

endclass : engine_example

而通过由UVM导入C方法，继而间接导入Matlab控制函数的方式，用户可以在UVM一侧通过例化上面的engine class，调用它所具备的方法，便可以用来控制Matlab的开始和结束。

import example_engine_pkg::*;

engine_example eng;

 initial begin

   eng = new();

   eng.engOpen();

 end

而对于Simulink模型，它无法伴随着Matlab引擎一同由UVM来调起，但依然可以利用上面的Matlab C的API接口，通过API接口将指令传递给Matlab的命令窗口，继而从Matlab一侧加载Simulink模块。API函数engEvalString()函数便是用来从C一侧发送命令到Matalb端的，而伴随着将这些API接口也引入到SV DPI的类中，便可以实现在UVM端来通过DPI函数间接在Matlab来加载Simulink模型。例如下面这个例子中，传递了一个命令open_system('<Simulink model>')到Matlab的命令窗口中，进而加载目标Simulink模块。

engEvalString("open_system('<Simulink model>');");

通过这个函数，我们现在可以在UVM和Matlab命令窗口之间建立通信，以此来控制Simulink模型。由于Matlab与SV之间没有之间的接口，这使得Simulink如果要同SV之间传送数据，也应当考虑数据在传送前的转换。这一点与上一节谈到的SC与SV的通信类似，即不同语言之间的数据传送应当遵守尽量单一的数据格式、传送的频率低，以此来保证传送的效率和准确率。

例如下面的这个例子中，Simulink模型中有monitor来观测数据，同时将这些观测到的数据流发送到Matlab中，保存到Matlab的数据对象中。而UVM一侧则可以利用DPI方法engGetVariable从Matlab一侧获得这些观测到的数据。可以看到的是，数据的中转站在Matlab中。类似地，如果UVM一侧要传递一些数据，譬如随机化生成的数据到Simulink中，也需要将这些生成的数据首先传递到Matlab的中转数据中，继而Simulink模型便可以获取这些中转数据了。

上面提供的Matlab/Simulink与UVM的混合仿真方法，对于Matlab的应用场景无论是作为参考模型至于环境中、还是作为早期的DUT至于环境中用来测试，都节省了创建额外模型的时间。而这一方法的不足在于Matlab与Simulator在较大的模型仿真中，如果发生过快的命令交互，会明显影响混合仿真的效率。当然，这一现象不仅仅是Matlab与仿真器混合仿真时需要考虑的问题，而对于Simulator与其他平台进行联合仿真时，都需要注意平台两侧交换的频率不能过快，从而提高整体仿真效率。

下一节中，我们将进入本篇的最后一张，为读者们带来SV/UVM与脚本语言的交互方式《脚本语言与UVM的交互》。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。