基于OpenVera构建以太网MAC芯片验证平台

引言 当芯片的设计规模越来越大，朝向SoC发展时，RTL级功能仿真时间还可以忍受，但门级仿真己经成为不可能继续广泛使用的技术了。对设计进行完备性验证要求有足够的测试向量，随着设计规模的增大，需要的仿真向量也急剧增加。近十年来，芯片的设计规模增大了100倍，仿真向量增加了近10000倍。二者的共同作用使门级仿真所需的时间飞速增长。要找到如此庞大的能够保证验证完备性的仿真向量集也变得不太可能。 另一方面，芯片设计又面临着上市时间的巨大压力，验证的不足直接导致芯片不能通过测试，由此可能造成更大的损失。验证，尤其是功能验证必将影响集成电路的设计和开发进程。因此，缩短验证时间、建立高效的验证平台已成为现代集成电路设计的关键。 [b]基于OpenVera验证平台的结构 [/b] 实时以太网RTE MAC芯片是符合IEEE802.3(CSMA/CD)协议和IEEE1588精确时间同步协议的网络通信控制器。它不仅兼容商用以太网的功能，还增加了特殊工业网络中所必须的实时特性，将应用于高速工业以太网，以满足工业以太网的实时要求。 图1 验证平台的发送部分架构 本平台就是为验证RTE MAC芯片而搭建的。平台采用OpenVera语言，基于事务级建立。验证平台发送部分的架构如图1所示，接收部分结构与此类似。它包括下面几个部分： 1) 调度：调度是整个平台的顶层，用于协调各个模块的工作。 2) DUV(design under verification)：待验证的芯片，除此以外都是用OpenVera语言编写的测试软件模块。 3) 测试事例：验证中针对具体功能而采用不同的测试事例，这里采用带约束的随机验证方式，通过对它的约束产生各种测试事例。 4) Frame_gen：将测试事例按照CPU总线侧的帧格式组成数据帧通过BFM输出到芯片。 5) Monitor：监视器，包括Bus_ Monitor和Ethernet_ Monitor。其中Bus_ Monitor监测总线的行为，可以监视存储器读写，芯片的数据处理等事务；Ethernet_ Monitor可以监视输出有效、冲突、载波等网路信息。 6) Check_table：根据BFM侧监视器检测的数据以及相应的配置，将理想DUV的输出存储在数组中，check模块可以把Check_table内的数据与DUV输出进行对照，实现自动检测。 7) BFM：总线功能模型，用于模拟总线功能，驱动DUV。 [b]OpenVera验证平台的建立方法及特点 [/b] 该平台基于事务级验证，采用专门的验证语言编写，具有高度的可重用性、灵活性，体现着现代电路设计中验证的发展潮流，下面将结合此平台介绍现代验证的特点和趋势。 [b]验证与设计并行 [/b] 传统的设计首先进行设计的开发，完成RTL代码的编写后再进行验证，整个产品开发时间接近于设计加上验证的时间。而对于现在的项目开发，在根据具体的设计要求定义功能，并给出初步的设计文档之后，就可以根据这些功能定义同时进行设计开发和验证平台的搭建。这一阶段中验证平台的搭建主要是建模，因此需要引入高级验证语言。高级验证语言是芯片设计复杂度达到一定程度后的必然产物，如OpenVera ，SystemC ，System Verilog，都具有强大的建模功能。就OpenVera而言，它引入C++中类的概念，是一种面向对象的编程，并有强大的函数功能支持，不仅使得验证与设计并行成为可能，还能加快验证平台的建立。 图2 总线的驱动时序 [b]基于事务级的验证方法 [/b] 以往的验证基于信号级，一个复杂芯片的信号数目非常多，包括大量的外部信号和内部信号，想要对它进行完整详细的验证，需要耗费很多的精力和时间，严重影响设计周期。基于事务的验证方法可以在一个更高的层次上进行验证，显著地减轻了测试工作，并有助于统计测试覆盖率。事务是一次性完成的一组操作或信号变化，在一个抽象概念上包括信号的传送，数据的处理、变化，系统的状态等。事务的概念很宽，可以简单到存储器的读写，复杂到很多数据的处理与传输。事务也可以由多个操作、多个时钟周期组成。 当一个设计在信号层经常要关注那些1或0时，设计者可以借助基于事务的方法很方便快捷地创建测试方法。系统结构设计人员可以不用费心去思考那些使能信号、地址总线等细节， 而是更多的关注数据的流向、处理、存储，以及电路的状态和动作等这类事务。基于事务的验证方法可以说是自然验证方法在设计更高抽象层的一种扩展，它也有利于平台的可重用性。 图3 将发送数据写入片内RAM [b]验证平台的重用性 [/b] 具有重用性的验证既可以被有相同特性的芯片所重用，比如当不同芯片基于同样的总线时，总线的BFM以及监视器就可以重用在不同的设计里。很多公司也有自己的成型验证库，如Synopsys提供的DesignWare VIP就是一种。另外，具有重用性的验证也可以在同一设计中被不同的测试事例所重用，本设计中的Frame_gen就是这样的模块。搭建可重用的平台最重要的是各个部件相互独立，并有层次性。下面对本平台的BFM和监视器这两大关键的可重用部件加以说明。 BFM 总线功能模型构建于较高的抽象层次，是总线功能的一种抽象描述，在基于特定总 线的基础上，为底层的各种总线操作建立直接同信号相联系的模块。这些模块可以用函数的形式出现，这些函数的组合可以用来实现总线的功能，这就是总线功能模型。可见，它的作用是提供给上层测试激励一个任务接口，而对底层的DUT，它提供具体的时序，完成从高层函数到具体带时序功能的转换。在设计测试激励的时候，可以通过简单地调用总线功能模型提供的任务以及函数对DUT进行驱动。 图4 发送开始 在本验证任务中，只对单个芯片进行验证，只需要对总线进行读写，可以完全采用任务的形式实现。BFM的程序中有一个cpu_port.vrh端口文件，是程序与芯片接口的文件之一，OpenVera通过它对DUV施加激励。驱动任务可以用类封装起来(这里是基于任务的BFM)，这些任务模拟总线的功能，通过对类内任务调用可实现对DUV施加激励。 在平台运行时可以例化这个类，并调用其任务，调用BFM任务实现对DUV驱动时的时序如图2所示。图中示出intel186写周期的时序(wr为写信号，低电压有效，s_clk为时钟，ALE为地址锁存信号，data_addr为数据地址线)，实现总线向芯片写数据的功能。采用Vera与VCS工具，数据与地址总线分时复用值为0xffff 的部分是数据，0x0001与0x0002是写操作的地址。 [b] 监视器 [/b] 本设计中有两个监视器，它的可重用性是提高验证效率的重要原因，需要遵循一些基本的设计规则。首先，1个监视器只监视1个接口，这样具有更大的灵活性，需要重用时可以不进行任何修改直接使用。 如果监视器要监视多个接口，当1个接口发生改变时就需要修改监视器，这不符合重用性的要求。其次，监视器可以被建立和取消。 在SoC设计中经常有复用I/O 的存在，随着I/O功能的不同，可能要使用不同的监视器来监控，需要通过SoC设置的改变来进行选择。一般来说，可以在监视器代码中添加一个参数开关来满足这个要求，在OpenVera中只需在调度中控制。最后还需要注意的是，监视器不能受其它设计或测试模块影响， 其它模块代码如激励驱动、运行环境或待测IP 的可配置寄存器的变化不能影响监视器工作。 [b] 随机测试[/b] 随机测试是必不可少的。因为对于一个系统而言，若期望使用直接测试激励来覆盖所有功能的测试，工作量是巨大的；对于模块间交互工作的边界情况的测试，使用直接测试激励也力不从心。所以，相对于直接激励测试而言，随机测试的目的在于试图花费较少的代价找出在某些极端情况或偶然巧合下才出现的设计错误。随机是带约束的随机，它比完全的随机测试更有针对性。对随机的控制可以在类内部建立constraint模块进行随机约束，也可以调用类的对象randomize()函数，用with{}进行约束。以以太网帧为例，“ frame.randomize() with{data_length<100};”产生的随机数据长度限定在100字节以内。另外，在随机测试中，功能覆盖率显得尤为重要，它是随机测试是否完成的标准。采用专门的语言和事务级的验证，以及监视器的监视，能使统计功能覆盖率变得很容易。比如检测是否激励经过了所有类别的帧，如超长帧、短帧、地址不匹配帧等。 [b] 平台灵活性和独立性 [/b] 灵活的验证平台会大大提高验证的效率。重用性在实现复杂功能的情况下，还要具有独立性。从另一个角度看，独立性也可以带来平台的灵活性。本文平台中的配置模块和软件提供给check模块特定的通道，从而在不影响其它模块的情况下达到了最大的灵活性。自动检测通过两侧监视器监视的事务，根据配置进行对照，然后产生错误提示，给出出错的相关信息，这使得验证人员可以根据错误报告准确定位错误发生地点。这些就是现代验证的一个趋势。 [b]实验结果 [/b] 本平台在UNIX工作站采用Synopsys的验证开发环境，设计语言采用OpenVera，应用Vera和VCS仿真工具。发送部分波形如图3和图4所示，芯片有8k的片内RAM，首先把发送数据写入RAM，当RAM中有数据或数据写完后再进行发送。 如图，从15100ns开始向片内RAM写入发送数据；从27220ns开始启动发送数据并添加前导(premable)、前定界(sfd)、校验码(fcs)。 [b]结语 [/b] 本文中所讨论的验证平台已在具体项目中得到应用，该结构在很大程度上提高了可重用性、灵活性和验证的自动化程度。使用该验证平台, 能够极大地提高验证平台开发效率，也加速了设计的最终实现。