• PLI是什么


    转载:https://www.eefocus.com/weidk/blog/11-05/219007_98ec9.html

    PLI是什么?PLI = Verilog Program Language Interface,也称为Verilog PLI。简单来说,PLI提供一种接口,将用户编写的C或C++程序连接到verilog仿真器上,实现verilog仿真器的功能扩展和定制。

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

    PLI接口主要提供以下三种功能。
    1。PLI接口允许用户编写自定义的system task和system function。用户写出相应的PLI程序并连接到仿真器后,就可以在自己写的verilog程序中使用这些system task和function了。一旦这些task/function在仿真过程中被调用,仿真器就会找到对应的用户编写的PLI程序来执行,从而实现仿真器的定制。
    2。这个接口还允许用户在自己的PLI程序中与仿真器中实例化的verilog硬件进行交互,比如读一个wire的值,向一排reg写值,设置一个cell的delay,等等。不夸张地说,对于PLI程序而言,仿真器中的verilog实例完全是透明的,用户想对这些硬件做什么操作都可以。(当然,硬件结构不能修改)有了这个功能,用户就可以在自定义的task/function中对硬件执行某些用verilog语言难以完成的操作。
    3。某些特定的操作需要对仿真过程中一些信号的变化做出响应。虽然我们可以用always来监控少量信号的变化,但如果需要监测大量信号,这种机制并不现实。PLI接口提供了一种函数回调机制解决这个问题。用户可以将某个wire/reg等信号挂上一个PLI程序中的C函数,以后每当该信号变化,这个C函数都会被调用,从而很方便地实现信号监测。事实上,很多打波形的system task都是用这个方法实现的。
    除了上面所说的这些机制外,PLI还能让用户控制仿真的过程,比如暂停,退出,往log文件里写信息等。还可以采集仿真过程的数据,比如当前仿真时间等等。实际的PLI程序中这些功能同样少不了。

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

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

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

    PLI相关的内容在verilog的文档中有介绍。

  • 相关阅读:
    关于XML文档
    Why sql is called structured query language?1
    UML学习---交互
    C#为什么不采用多继承:
    url中
    array
    hard
    构造函数返回值
    布局容器layout Container
    k8s的概念
  • 原文地址:https://www.cnblogs.com/zhiminyu/p/16073558.html
Copyright © 2020-2023  润新知