具体实施方式
为使本公开的目的、技术方案和优点更加清楚明白,以下结合具体实施例,并参照附图,对本公开进一步详细说明。
需要说明的是,除非另外定义,本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性,而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同,而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电性的连接,不管是直接的还是间接的。
UVM(Universal Verification Methodology)验证平台是一套基于TLM(Transaction Level Modeling)通信开发的验证平台,可以帮助验证开发人员搭建可配置可重用的验证环境。如图1所示,图1示出了一种UVM验证平台的示意性结构图。图1中的验证平台test通过接口对待验证设计DUT模块进行验证测试。在测试过程中,通常需要在顶层验证环境中对所有的接口(interface)进行声明、连接和配置传递。而对于复杂的RTL设计,仅声明接口可能就需要至少上千次,很容易遗漏出错。此外,传统的接口连接通常需要手动或者通过脚本来实现对待测设计中所有接口的信号连接,对于层次复杂的设计模块,这种方法非常麻烦且容易出错。而且还常常存在主从模块,并且有的模块的输入接口需要由验证环境来负责驱动,有的则需要由前序设计模块的来驱动,因此,在接口连接的过程中还需要根据端口的方向特性来进行连接。对于复杂的设计模块来说,往往有成百上千的接口信号,这样一一区分接口的信号连接方向往往容易导致错误,影响开发效率。
鉴于此,本公开实施例提供了一种用于验证待测设计的接口连接方法及相关设备、程序产品,通过在验证环境中对接口进行封装,并采用bind语句完成验证环境与待测设计的连接,以及通过配置数据库将本层次的接口连接配置向下一验证环境进行传递,从而自动完成多层次的接口声明、连接和配置传递,提升了验证平台的开发效率,减少了重复性开发工作,提升了开发人员的工作效率,起到了加速项目进度的作用,从而保证芯片项目的流片时间。
参见图2,图2示出了根据本公开实施例的验证环境结构与RTL设计结构的示意性框图。图2中,验证环境接口包括:顶层验证环境top_env,对应于RTL设计中的顶层模块top_module,顶层验证环境top_env用于对顶层模块top_module进行验证,属于同一层次。顶层验证环境top_env中嵌套有底层验证环境env,对应于RTL设计中的子模块sub_module,子模块sub_module嵌套在顶层模块top_module中,底层验证环境env用于对子模块sub_module进行验证,属于同一层次。其中,顶层模块top_module可以例化子模块sub_module。底层验证环境env的agent组件与RTL设计结构的接口一一对应,例如,3个底层验证环境env与3个子模块sub_module一一对应,每个底层验证环境env中的2个agent组件分别对应于子模块sub_module的输入接口和输出接口。
对于图2中的底层验证环境env与对应的模块的对应关系可以如图3和图4所示,图3示出了根据本公开实施例的待测设计中模块的示意性原理图,图4示出了根据本公开实施例的验证环境env的示意性原理图。图3中,待测设计中的一模块module,可以包括:输入端接口,用来获取外部的输入激励,如图3中的data_in;行为功能,用于对输入激励进行相应的逻辑运算,如图3中的module模块内部的运算逻辑,例如,可以包括组合和时序逻辑电路;输出端接口,用来将运算后的结果输出,如图3的data_out。
那么可以将上述输入端接口、行为功能和输出端接口进行封装得到如图4所示的验证环境env。图4中,对输入端data_in的接口可以封装成agent1组件,对输出端data_out的接口可以封装成agent2组件。其中,agent1组件的驱动器(driver)拿到接口句柄,然后将需要的激励事务(transaction)驱动到接口上,作为后续模块的输入激励,agent2组件里的monitor监测采样对应接口的信号,封装成事务(transaction)以传递给验证环境,以供后续组件的处理。同时,上述两个agent组件可以封装在env验证环境里,并在该层次下编写参考模块(reference model)和一些分析组件,以及开始编写测试用例对该模块module进行验证。需要说明的是,如图2的顶层验证环境top_env中,需要对data_in和data_out对应的接口进行声明、连接和配置传递。例如,顶层验证环境top_env例化包含了两个module,一个是rtl_inst_top,用来例化RTL设计,另一个是env_inst_top,用来对所有的接口进行声明、连接和配置传递。然而如果RTL设计更加复杂,那么在验证平台里就需要完成对所有底层验证环境中agent组件所封装的接口进行声明、连接和配置传递。此时,在验证平台对接口进行声明、连接和配置传递已经变得比较复杂,然而如果RTL设计层次更加复杂,例如图2中所示的RTL设计,则需要在验证平台中继续对所有agent组件所封装的接口进行声明、连接和配置传递,再加上路径层次和代码语句会变得非常冗长复杂,很容易出错。在一个复杂的RTL设计模块中,这几乎是不可能完成的工作。
基于上述考虑,参见图5,图5示出了根据本公开实施例的用于验证待测设计的接口连接方法的示意性流程图。其中,验证环境和待测设计可以如图2中所示,第一层验证环境env嵌套在第二层验证环境top_env中,所述第一层模块sub_module嵌套于所述第二层模块top_module中,第一层验证环境env用于对第一层模块sub_module进行封装,以提供给第二层验证环境top_env进行例化和重用,第二层验证环境top_env用于对所述第二层模块top_module进行封装,以提供给更顶层验证环境进行例化和重用;基于每层验证环境,可以在其上编写测试用例以对待测设计的对应层次的模块进行仿真调试,从而完成对待测设计DUT的验证。
具体实施中,第一层模块sub_module的示例性程序代码包括:
以及第二层模块top_module的RTL示例性程序代码包括:
如图5所示,用于验证待测设计的接口连接方法500,包括:
步骤S510,调用第一层验证环境的第一接口文件。
其中,第一接口文件可以包括第一层验证环境与第一层模块对应的端口及其连接方法。
在一些实施例中,在步骤S 510之前还可以包括:
基于所述第一层验证环境的agent组件配置所述接口的声明方式,所述agent组件嵌套在所述第一层验证环境中;
基于所述接口的声明方式和预设接口连接方法在所述第一层验证环境中生成所述第一接口文件。
在一些实施例中,基于所述第一层验证环境的agent组件配置所述接口的声明方式,包括:在端口声明列表中配置所述agent组件中的数据类型成员。具体实施中,可以采用如下程序代码实现:
相比于传统方式中的端口声明列表,根据本公开实施例,端口声明列表中增加了数据类型成员data。传统方式中的端口声明列表的程序代码如下:
具体实施中,在第一层模块sub_module对应的第一层验证环境env中,新增第一接口文件demo_env_interface_wrapper,完成对待测设计中包含的接口的声明和配置传递,第一接口文件可以采用如下程序代码实现:
其中,可以看出,第一接口文件中的接口连接方法包括set_vif函数。
步骤S520,基于所述第一接口文件和bind语句生成第一连接文件,并基于第一连接文件将所述第一层验证环境连接至所述待测设计对应的第一层模块,以实现所述第一层验证环境与述第一层模块之间的数据传输。
具体实施中,可以采用第一接口文件中的接口连接方法即set_vif函数进行第一层次的接口配置传递,可以采用如下示例性程序代码实现:
接着,可以采用bind语句将第一层模块sub_module与第一接口文件demo_env_interface_wrapper套接,生成第一连接文件,以实现第一层模块与第一层验证环境的接口连接,从而实现数据传输和对第一层模块sub_module的验证。第一连接文件module tb_rtl_inst_top可以采用如下示例性程序代码实现:
步骤S530,基于所述第一连接文件和所述第二层模块的接口设置生成第二层验证环境的接口配置文件,并将所述接口配置文件经由配置数据库传递至所述第二层验证环境。
在一些实施例中,所述接口配置文件包括接口配置宏和可重用连接文件,基于所述第一连接文件生成第二层验证环境的接口配置文件,包括:
基于所述第一连接文件生成所述可重用连接文件;
基于所述第一连接文件中的接口连接方法生成所述接口配置宏。
具体实施中,可重用连接文件用于实现第一连接文件的代码的可重用,可重用连接文件demo_env_interface_bind可以采用如下示例性程序代码实现:
还可以基于第一连接文件中的接口连接方法set_vif生成接口配置宏demo_env_defines,以将第一层次的接口连接方式通过配置数据库(如UVM平台中的config_db)传递至下一层次(如图2中的top_env)。配置宏demo_env_defines可以采用如下示例性代码实现:
在一些实施例中,方法500还可以包括:
在所述第二层验证环境中基于所述接口的声明方式和所述接口配置文件生成第二接口文件。
在一些实施例中,所述第二层模块的接口设置包括所述第二层模块设置有单独的接口;
在所述第二层验证环境中基于所述接口的声明方式和所述接口配置文件生成第二接口文件,包括:
基于所述接口的声明方式和所述接口配置宏生成所述第二接口文件。
在一些实施例中,所述第二层模块的接口设置包括所述第二层模块未设置单独的接口;
基于所述接口的声明方式生成所述第二接口文件。
具体实时中当第二层模块top_module没有设置单独的接口,只是用于例化第一层模块sub_module时,可以仅基于端口声明列表生成第二接口文件demo_env_top_interface_wrapper,可以采用如下示例性程序代码实现:
可以看到,这里接口端口连接到第二层模块top_module上,其中set_vif函数为空函数,因为top_module没有单独的接口,只是负责例化连接第一层模块sub_module。
当第二层模块top_module设置有单独的接口时,上述第二接口文件demo_env_top_interface_wrapper的示例性程序代码中的set_vif函数可以不为空函数,该set_vif函数可以与第一接口文件demo_env_interface_wrapper中的set_vif函数类似,在此不再赘述。
在一些实施例中,方法500还可以包括:
基于所述第二接口文件和bind语句生成第二连接文件,并基于第二连接文件将所述第二层验证环境连接至所述待测设计对应的第二层模块,以实现所述第二层验证环境与述第二层模块之间的数据传输。
具体实施中,可以采用第二接口文件中的接口连接方法即set_vif函数进行第二层次的接口配置传递,然而,图2中的第二层模块top_module没有设置单独的接口,那么可以采用第一层模块sub_module对应的第一层验证环境env中的接口配置宏,进行第二层次的接口配置传递,可以采用如下示例性程序代码实现:
接着,为了实现第二连接文件的代码的可重用性,生成第二层次的可重用连接文件demo_env_top_interface_bind,可以采用如下示例性程序代码实现:
以及当第二层模块top_module设置有单独接口时,可以基于第二连接文件中的接口连接方法set_vif生成第二层次的接口配置宏;当第二层模块top_module没有设置单独的接口,如图2所示,那么可以采用第一层模块sub_module对应的第一层验证环境env中的接口配置宏以将其通过配置数据库(如UVM平台中的config_db)传递至下一层次。第二层次的配置宏demo_env_top_defines可以采用如下示例性代码实现:
还基于可以采用第二层次的可重用连接文件demo_env_top_interface_bind将第二层模块top_module与第二接口文件demo_env_top_interface_wrapper套接,生成第二连接文件,以实现第二层模块与第二层验证环境的接口连接,从而实现数据传输和对第二层模块top_module的验证。第二连接文件module tb_rtl_inst_top可以采用如下示例性程序代码实现:
可以看到,相比于传统的接口连接方法,本公开实施例不需要再通过force或者assign语句手动连接接口,因为接口连接已经由bind语句已经完成了,而且不用考虑接口的连接方向(例如,VCS在运行时会根据驱动的情况自动转换方向)。即不断重复如图5中的步骤S510至步骤S530,层层封装和复用,以实现接口的自动声明、连接和配置传递,从而提升开发效率,加快项目进度。当然以上还可以通过脚本来实现,即实现接口连接配置部分代码的自动化,从而进一步提升开发效率,加快项目进度。
应了解,上述示例仅为以图2中的验证环境和待测设计进行说明,并旨在对验证环境和待测设计进行设置,验证环境和待测设计可以包括更多层次,在此不做限制。当验证环境和待测设计包括更多层次时,可以重复执行第一层验证环境和第二层验证环境中的接口的声明、连接和配置,直至完成所有的层次。
根据本公开实施例,还提供了一种待测设计的验证方法,包括:
根据本公开实施例所述的用于验证待测设计的接口连接方法对所述待测设计与对应的验证环境进行连接;
经由所述验证环境对待测设计发送激励信号,并接收所述待测设计的反馈信号;
比较所述反馈信号和预设参考信号是否一致,以确定所述待测设计的性能。
综上所述,本实施例通过对接口封装成wrapper,并采用bind方法,从而简化了接口的声明和连接过程,即不需要再通过诸如force或者assign等语句手动连接接口,而且消除了对于接口的连接方向的代码部分,从而在简化开发环境的同时,大大降低出错的概率。以及通过层层封装宏函数的方式实现了对验证环境中涉及到的接口的配置传递以及bindinterface的操作,实现了该部分的代码可重用。本实施例具有如下优点:
(1)实现了对复杂RTL设计中涉及到的接口的快速声明、连接和配置传递,提升验证平台的开发效率;
(2)实现了对验证平台的接口的声明、连接和配置传递的代码可重用,降低了重复性开发工作;
(3)不再需要手动或者通过脚本来实现对DUT模块中所有的接口的信号连接,因为我们可以利用VCS在运行时会根据驱动的情况自动转换方向的特性,从而降低了代码量,提升了开发效率;
(4)消除了设计主从模块以及模块输入接口驱动源不同导致的需要根据端口的方向特性来进行连接的复杂性,从而进一步提升了开发效率;
(5)规范了UVM开发框架,方便团队协作和项目管理。
因此,根据本公开实施例能够大大提升开发人员的工作效率,起到了加速项目进度的作用,从而保证芯片项目的流片时间。
需要说明的是,本公开实施例的方法可以由单个设备执行,例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下,由多台设备相互配合来完成。在这种分布式场景的情况下,这多台设备中的一台设备可以只执行本公开实施例的方法中的某一个或多个步骤,这多台设备相互之间会进行交互以完成所述的方法。
需要说明的是,上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
根据本公开实施例,与上述任意实施例方法相对应的,本公开还提供了一种用于验证待测设计的接口连接装置。参见图6,用于验证待测设计的接口连接装置,包括:
第一层验证模块,用于调用第一层验证环境的第一接口文件;
以及基于所述第一接口文件和bind语句生成第一连接文件,并基于第一连接文件将所述第一层验证环境连接至所述待测设计对应的第一层模块,以实现所述第一层验证环境与述第一层模块之间的数据传输;
以及基于所述第一连接文件和所述第二层模块的接口设置生成第二层验证环境的接口配置文件,并将所述接口配置文件经由配置数据库传递至所述第二层验证环境;
其中,所述第一层验证环境嵌套在所述第二层验证环境中,所述第一层模块嵌套于所述第二层模块中,所述第一层验证环境用于对所述第一层模块进行封装,以提供给所述第二层验证环境进行例化和重用,所述第二层验证环境用于对所述第二层模块进行封装,以提供给更顶层验证环境进行例化和重用;基于每层验证环境,编写测试用例以对所述待测设计中与所述每层验证环境所对应层次的模块进行仿真调试,从而完成对待测设计的验证。
在一些实施例中,用于验证待测设计的接口连接装置还包括:
第二层验证模块,用于在所述第二层验证环境中基于所述接口的声明方式和所述接口配置文件生成第二接口文件;
基于所述第二接口文件和bind语句生成第二连接文件,并基于第二连接文件将所述第二层验证环境连接至所述待测设计对应的第二层模块,以实现所述第二层验证环境与述第二层模块之间的数据传输。
应了解,根据本公开实施例还可以包括更多层验证模块,在此不再赘述。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
上述实施例的装置用于实现前述任一实施例中相应的验证环境中的接口连接方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
根据本公开实施例,与上述任意实施例方法相对应的,本公开还提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上任意一实施例所述的用于验证待测设计的接口连接方法。
图7示出了根据本公开实施例的电子设备的示意性框图。该设备可以包括:处理器710、存储器720、输入/输出接口730、通信接口740和总线750。其中处理器710、存储器720、输入/输出接口730和通信接口740通过总线750实现彼此之间在设备内部的通信连接。
处理器710可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本说明书实施例所提供的技术方案。
存储器720可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器720可以存储操作系统和其他应用程序,在通过软件或者固件来实现本说明书实施例所提供的技术方案时,相关的程序代码保存在存储器720中,并由处理器710来调用执行。
输入/输出接口730用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口740用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线750包括一通路,在设备的各个组件(例如处理器710、存储器720、输入/输出接口730和通信接口740)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器710、存储器720、输入/输出接口730、通信接口740以及总线750,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本说明书实施例方案所必需的组件,而不必包含图中所示的全部组件。
上述实施例的电子设备用于实现前述任一实施例中相应的用于验证待测设计的接口连接方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
根据本公开实施例,与上述任意实施例方法相对应的,本本公开还提供了一种计算机程序产品,所述计算机程序产品包括存储有指令的计算机可读存储介质,所述指令在被执行时使得计算设备的至少一个中央处理器单元执行根据本公开实施例的用于验证待测设计的接口连接所述的方法。
根据本公开实施例,与上述任意实施例方法相对应的,本公开还提供了一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令用于使所述计算机执行如上任一实施例所述的用于验证待测设计的接口连接方法。
本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。
上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的用于验证待测设计的接口连接方法,并且具有相应的方法实施例的有益效果,在此不再赘述。
所属领域的普通技术人员应当理解:以上任何实施例的讨论仅为示例性的,并非旨在暗示本公开的范围(包括权利要求)被限于这些例子;在本公开的思路下,以上实施例或者不同实施例中的技术特征之间也可以进行组合,步骤可以以任意顺序实现,并存在如上所述的本公开实施例的不同方面的许多其它变化,为了简明它们没有在细节中提供。
另外,为简化说明和讨论,并且为了不会使本公开实施例难以理解,在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外,可以以框图的形式示出装置,以便避免使本公开实施例难以理解,并且这也考虑了以下事实,即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即,这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如,电路)以描述本公开的示例性实施例的情况下,对本领域技术人员来说显而易见的是,可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此,这些描述应被认为是说明性的而不是限制性的。
尽管已经结合了本公开的具体实施例对本公开进行了描述,但是根据前面的描述,这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如,其它存储器架构(例如,动态RAM(DRAM))可以使用所讨论的实施例。
本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此,凡在本公开实施例的精神和原则之内,所做的任何省略、修改、等同替换、改进等,均应包含在本公开的保护范围之内。