（转）Verilog PLI应用简介

Verilog PLI即verilog program language interface（verilog的编程语言接口），Verilog PLI提供一种接口，将用户编写的C或C++程序连接到verilog仿真器上（wolf批注：通过动态连接库拉接到仿真器，ncverilog支持的为.so格式，modelSIM支持的为.dll格式），实现verilog仿真器的功能扩展和定制，下面介绍其功能和典型应用…

说到这里，大家首先要明确一点：PLI只是用来做仿真的，说得更具体就是只用来写testbench的，而且只用于verilog。在VHDL上也有类似的编程语言接口，我这里就不提了。如果你对仿真不感兴趣，就不用往下看了。

PLI接口主要提供以下三种功能。
1。PLI接口允许用户编写自定义的system task和system function。用户写出相应的PLI程序并连接到仿真器后，就可以在自己写的verilog程序中使用这些system task和function了。一旦这些task/function在仿真过程中被调用，仿真器就会找到对应的用户编写的PLI程序来执行，从而实现仿真器的定制（wolf批注：PLI技术最使人头痛的应该是他的对接函数了，也叫注册函数，即起牵线搭桥作用，让verilog和c model侧的函数名匹配起来，彼此认识。格式是相当的死板，一不小心就会出错，切记切记！）。
2。这个接口还允许用户在自己的PLI程序中与仿真器中实例化的verilog硬件进行交互，比如读一个wire的值，向一排reg写值，设置一个cell的delay，等等。不夸张地说，对于PLI程序而言，仿真器中的verilog实例完全是透明的，用户想对这些硬件做什么操作都可以。（当然，硬件结构不能修改）有了这个功能，用户就可以在自定义的task/function中对硬件执行某些用verilog语言难以完成的操作（wolf批注：小狼认为，PLI的最大功能是能把算法的c model通过该接口挂在仿真器上，做其他工作简直得不偿失。）。
3。某些特定的操作需要对仿真过程中一些信号的变化做出响应。虽然我们可以用always来监控少量信号的变化，但如果需要监测大量信号，这种机制并不现实。PLI接口提供了一种函数回调机制解决这个问题。用户可以将某个wire/reg等信号挂上一个PLI程序中的C函数，以后每当该信号变化，这个C函数都会被调用，从而很方便地实现信号监测。事实上，很多打波形的system task都是用这个方法实现的。
除了上面所说的这些机制外，PLI还能让用户控制仿真的过程，比如暂停，退出，往log文件里写信息等。还可以采集仿真过程的数据，比如当前仿真时间等等。实际的PLI程序中这些功能同样少不了。

PLI的典型应用主要包括：
1。实现verilog模型和C模型的共同仿真（wolf批注：Right！这次你终于说到点子上去了）。在国外，对于比较复杂的系统，开发者经常需要首先制作一个能够工作的C模型，然后逐模块地将其改写为verilog，这样可以实现一个比较安全、渐进的开发过程。还有一些比较复杂的硬件单元库，尤其是定制的浮点单元库，其仿真模型都是C模型，这时也必须使用PLI来连接两种模型。
2。产生测试激励，产生验证矢量或直接进行验证（wolf批注：没有必要！）。这是PLI程序最常用也是最主要的功能。比较复杂的系统经常需要根据上一个激励的响应决定下一个激励，这就要求过程控制做得很好。可是，大家用过verilog的都知道，verilog的过程控制非常弱，很难在testbench中写出复杂的程序控制。而C在这一点上有绝对的优势。因此，使用PLI可以取长补短，实现一个高效的仿真系统。
（事实上，GateWay（wolf批注：做啥呢？）公司在一开始发明verilog语言时，就已经使用了PLI来进行与C的交互，所以一直没有在verilog中加入太多的过程控制。有人认为verilog的逻辑建模能力很强，而仿真能力不好，那是因为verilog在设计时就考虑了使用PLI进行增强。从这个意义上讲，PLI是verilog不可分割的一部分。）
3。捕获仿真过程和结果，并以用户易于接受的方式输出。举一个典型的例子，打波形就是这种应用。再举一个例子，我们仿一个MPEG4解码芯片，可以把输出码流用PLI实时采集变换后，直接用实际图像的方式直接打到屏幕上，这样我们就可以很直观得观察我们设计的硬件的效果。
4。分析仿真过程，计算性能参数。大家知道功耗分析是怎么实现的吗？就是用PLI纪录每个cell的翻转情况，然后根据翻转次数计算功耗。再举个例，我们想知道解码芯片中各运算部件占总运行时间的比例，也可以使用PLI来监测，然后根据监测结果调整我们的设计。
5。软硬件联合仿真（wolf批注：你所谓的软件应该指firmware！你需要开发一个ARM／MIPS／MCU模拟器来进行对接。否则软件怎么跑？还有一种联合仿真的概念是这样的，我的芯片中包含MCU实体，软件编译成机器码加载进MCU所使用的ROM中去，大家一起来联合仿真。该方案的缺点是难以调试）。现在，纯以硬件方式工作的IC已经不多了，大量的IC工作时都需要软件的参与和控制。离开这些控制软件进行仿真，工作环境不真实，可能造成激励模式的遗漏。如果不用PLI，我们就只能用verilog来在testbench中模拟软件控制，但verilog可能根本描述不了复杂的控制。使用PLI连接控制软件和仿真器，我们就能够模拟实际的芯片工作环境和过程。另外还有一个额外的好处：控制软件本身也能在这个过程中进行调试。
其它使用PLI的应用还很多，不再一一赘述。

PLI的版本
到现在为止，PLI有两个版本：1.0和2.0。PLI1.0一般就简称PLI，而PLI2.0又称为VPI（wolf批注：See！原来如此！DPI呢？跟他们有什么关系？）。PLI1.0从1985年GateWay发明verilog起开始发展，到1995年verilog成为IEEE标准时，就停止发展了，而VPI从此时开始诞生，到现在也还在演化。IEEE verilog工作组的本意是从那以后逐步使用VPI替代PLI1.0，但这个目标到现在也没有实现，而且还看不到实现的希望。究其原因，一是出于兼容性的考虑，二是VPI并没有特别明显的优势（wolf批注：兄弟，你又对了！去学systemC或systemVerilog吧），三是verilog仿真器的市场竞争不够激烈。
在使用上，PLI和VPI各有特点。PLI的API（wolf批注：what？）又多又全又乱，而VPI的API就非常精炼，一个词，漂亮。常用的PLI的函数集中恐怕至少有近百个，写程序时不查手册几乎不可能；而且，很多API是重复的。这也难怪，因为PLI完全是在实践中发展起来的，经常是一个developer认为需要一个功能，他就往API里加一个函数，完全没有统筹规划。而VPI是标准组织制订出来的，而且融入了相当多的面向思想，因此在精炼方面显然远远超过PLI。整个VPI的函数集才二十来个函数。但是，VPI并不好学，因为它的结构远比PLI复杂。VPI最大的弱点还是仿真器对其支持不好。很多03年出的仿真器都还不敢声称自己很好地支持VPI。
就我自己的感觉，PLI1.0足够用了。我见过很多国外著名公司写的PLI程序，没有一个是用VPI写的。

这一节的最后，我讲讲在实际工作中使用PLI的问题。PLI虽然很强大，但它有个相当显著的弱点：难以调试（wolf批注：兄弟，你又对了！了解一下就行，能看懂就好！已经退出历史的潮流了）。对于没有经验的C编程者而言，编写调试一个大型的PLI程序简直是一场噩梦。你如果说我在学校里学过C语言，那没有什么用；也许你费很大劲能做一个类似$hello_world的system task，但复杂的你一定做不出来。而且，大部分人以前编、调C程序都是用IDE环境做的（wolf批注：其实就算是用systemC开发的函数依然难于调试，唉！），而PLI很难用IDE来调试。就我自己的经验，大型PLI程序在IDE上调几乎都会垮。调试PLI程序的通用方法是最原始的printf，这对不习惯的人来说也是一大考验。而且，PLI一般都在unix平台上用gcc来编译链接的，而大家有多少使用过这种纯命令行的工作方式呢（wolf批注：I super like it）？所以，大家如果要学PLI，一定要有一定的软件基础。
另外，对于做ASIC的人，使用PLI确实能够大大提高仿真的效率。但我观察，论坛里很多人都是做FPGA的。我的看法是，做FPGA根本没有必要费劲地做testbench，直接烧了跑就是了，实际工作环境比什么testbench都可靠。因此，这部分用户实在没有太大必要来学习PLI。