CN112241347A - 实现SystemC验证的方法和验证平台组件架构 - Google Patents

Abstract

本申请提供一种实现SystemC验证的方法和验证平台组件架构，方法包括：通过TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接；按照仿真系统和TLI手册的要求，配置TLI接口以及SystemC文件名，并配置SystemC设计与已有Verilog RTL验证平台之间的调用函数；调用函数用于从已有Verilog RTL验证平台处调用验证环境要素；根据配置的TLI接口、SystemC文件名以及调用函数编译仿真脚本；在SystemC设计完成后，执行仿真脚本进行仿真验证。这样，实现对于已有验证平台的复用，降低了对芯片验证工程师的要求，降低了实现SystemC验证的难度。

Description

实现SystemC验证的方法和验证平台组件架构

技术领域

本申请涉及芯片验证技术领域，具体而言，涉及一种实现SystemC验证的方法和验证平台组件架构。

背景技术

随着SOC(System on Chip，系统级芯片)规模越来越大，复杂度越来越高，SOC前期需要进行架构分析和性能优化，高质量的SystemC建模能起到非常重要的作用，为SOC更准确的分析/评估提供了重要的参考依据。

目前在实际工作中，出现了在进行了Verilog RTL(Register-transfer Level，寄存器传输级)验证后，还需要进行SystemC验证的情况。

但重新搭建SystemC的验证环境，需要耗费大量额外的人力和时间，且大部分芯片验证工程师对SystemC语法不熟悉，需要一边学习研究SystemC语法一边投入项目搭建环境。而即使对语法熟悉，最终在评估SystemC RTL验证完备性时也存在一定的困难。例如，无法充分分析SystemC RTL建模的code(代码)或function(功能)的质量。为此，需要提供一种更为简单可靠的实现SystemC验证的方法，以降低实现SystemC验证的难度。

发明内容

本申请实施例的目的在于提供一种实现SystemC验证的方法和验证平台组件架构，用以降低实现SystemC验证的难度。

本申请实施例提供了一种实现SystemC验证的方法，包括：通过TLI接口(Transaction-Level Interface，事务级接口)实现待验证的SystemC设计与已有VerilogRTL验证平台的连接；所述已有Verilog RTL验证平台为已实现过所述SystemC设计对应的Verilog设计的验证的验证平台；按照仿真系统和TLI手册的要求，配置TLI接口以及SystemC文件名，并配置SystemC设计与已有Verilog RTL验证平台之间的调用函数；所述调用函数用于从已有Verilog RTL验证平台处调用验证环境要素；根据配置的所述TLI接口、SystemC文件名以及调用函数编译仿真脚本；在SystemC设计完成后，执行所述仿真脚本进行仿真验证。

在上述实现过程中，基于已有的Verilog RTL验证平台，通过TLI接口将待验证的SystemC设计接入该已有的Verilog RTL验证平台中，并按照相关手册要求配置好接口、文件名以及调用函数，从而实现从已有Verilog RTL验证平台处调用验证环境要素，实现对于已有Verilog RTL验证平台处的验证环境的复用。这样就降低了对芯片验证工程师的要求，使得芯片验证工程师只需要了解TLI接口相关配置知识以及基本的SystemC设计知识，降低了实现SystemC验证的难度。同时，由于已有Verilog RTL验证平台已经验证过VerilogRTL，因此已有Verilog RTL验证平台的验证效果通常是可靠的，因此结合Verilog RTL验证平台也可以更为有效地评价SystemC验证的效果。

进一步地，通过TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接，包括：通过第一TLI接口连接所述待验证的SystemC设计的输入端与所述已有Verilog RTL验证平台的激励源。

在上述实现过程中，通过TLI接口接入激励源，即实现了对于激励源的复用，不需要重新搭建激励源，降低了对于芯片验证工程师的要求。

进一步地，所述已有Verilog RTL验证平台中，激励源通过Master(主)VIP(verification IP，已经申请知识产权保护的验证模块)模块传输给所述已有Verilog RTL验证平台中的Verilog设计；通过第一TLI接口连接所述待验证的SystemC设计的输入端与所述已有Verilog RTL验证平台的激励源，包括：通过第一TLI接口连接所述待验证的SystemC设计的输入端与所述Master VIP模块。

在上述实现过程中，可以复用Verilog RTL验证平台的激励源以及Master VIP，从而可以降低对于芯片验证工程师的要求。

进一步地，所述已有Verilog RTL验证平台中的Verilog设计连接有从VIP模块；通过TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接，包括：通过第二TLI接口连接所述待验证的SystemC设计与所述已有Verilog RTL验证平台的Slave(从)VIP模块。

进一步地，所述方法还包括：配置第一核验模块；将所述SystemC设计的输出和所述已有Verilog RTL验证平台中的Verilog设计的输出输入到所述第一核验模块，以使所述第一核验模块对所述SystemC设计的输出进行核验。

在本申请实施例中，通过将SystemC设计的验证结果和已有Verilog RTL验证平台中的Verilog设计的输出输入到第一核验模块，从而结合已有Verilog设计的输出来辅助核验SystemC设计的输出，从而也可以更为有效地评价SystemC验证的效果。

进一步地，所述方还包括：配置第二核验模块；将所述SystemC设计的输入和所述SystemC设计的输出输入到所述第二核验模块，以使所述第二核验模块对所述SystemC设计的输出进行核验。

在本申请实施例中，通过将SystemC设计的输入和SystemC设计的验证结果输出至第二核验模块，从而对SystemC设计的输出进行核验，从而可以有效确定对SystemC设计的验证效果。

进一步地，在配置TLI接口以及SystemC文件名之前，所述方法还包括：规划验证环境目录结构；所述按照仿真系统和TLI手册的要求，配置TLI接口以及SystemC文件名包括：按照所述验证环境目录结构，并按照所述仿真系统和所述TLI手册的要求，配置TLI接口以及SystemC文件名。

在本申请实施例中，通过规划验证环境目录结构，从而按照验证环境目录结构配置值相关TLI接口以及SystemC文件名，从而使得搭建的对于SystemC的验证平台的相关数据便于管理。

进一步地，配置SystemC文件名，包括：配置所有接口信号的输入文件以及输出文件，以及SystemC头文件和顶层Top文件。

进一步地，所述已有Verilog RTL验证平台为以下之一：

SystemVerilog验证平台；

OVM(Open Verification Methodology，开放式验证方法学)验证平台；

VMM(Verification Methodology Manual，验证方法学手册)验证平台；

UVM(Universal Verification Methodology，通用验证方法学)验证平台。

进一步地，所述验证环境要素包括以下至少之一：

激励源；

Master VIP；

SlaveVIP。

本申请实施例还提供了一种用于实现SystemC验证的验证平台组件架构，包括：待验证的SystemC设计；已实现过Verilog设计的验证的已有Verilog RTL验证平台；事务级TLI接口，连接所述待验证的SystemC设计与所述已有Verilog RTL验证平台；其中，所述TLI接口，以及验证所述SystemC设计涉及到的SystemC文件名和用于实现验证环境要素调用的调用函数，按照仿真系统和TLI手册的要求进行配置，并编译至仿真脚本中。

上述用于实现SystemC验证的验证平台组件架构，基于已有Verilog RTL验证平台实现，不需要再重新完整搭建整个验证平台，在按照仿真系统和TLI手册的要求配置TLI接口、SystemC文件名、以及SystemC设计与已有Verilog RTL验证平台之间的调用函数之后，即可实现对于已有Verilog RTL验证平台的验证环境的复用，从而降低了对芯片验证工程师的要求，使得芯片验证工程师只需要了解TLI接口相关配置知识以及基本的SystemC设计知识，降低了实现SystemC验证的难度。同时，由于已有Verilog RTL验证平台已经验证过Verilog RTL，因此已有Verilog RTL验证平台的验证效果通常是可靠的，因此结合VerilogRTL验证平台也可以更为有效地评价SystemC验证的效果。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种实现SystemC验证的方法的基本流程示意图；

图2为本申请实施例提供的一种基本的组件架构结构示意图；

图3为本申请实施例提供的一种复用激励源的组件架构结构示意图；

图4为本申请实施例提供的一种通过复用主VIP实现复用激励源的组件架构结构示意图；

图5为本申请实施例提供的一种复用主VIP和从VIP的组件架构结构示意图；

图6为本申请实施例提供的一种设置核验模块的组件架构结构示意图；

图7为本申请实施例提供的一种具体的验证平台组件架构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

实施例一：

目前在实际工作中，出现了在进行了Verilog RTL验证后，还需要进行SystemC验证的情况。对于此需求，若重新搭建SystemC验证环境，那么对于资源的消耗量则较大，项目验证环境搭建耗时较长，影响项目推进，同时搭建SystemC验证环境对于芯片验证工程的专业化要求也较高。

为此，本申请实施例中提供了一种基于已有的Verilog RTL验证平台实现SystemC验证的方法。参见图1所示，包括：

S101：通过TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接。

需要说明的是，SystemC是一种软/硬件协同设计语言，一种新的系统级建模语言。SystemC是在C++的基础上扩展了硬件类和仿真核形成的，结合了面向对象编程和硬件建模机制原理两方面的优点。SystemC可以在抽象层次的不同级进行系统设计。系统硬件部分可以用SystemC类来描述，其基本单元是模块，模块内可包含子模块、端口和过程，模块之间通过端口和信号进行连接和通讯。因此，SystemC被广泛应用在芯片验证领域，能很大地提高芯片验证效率。

而Verilog是一种硬件描述语言，用于从算法级、门级到开关级的多种抽象设计层次的数字系统建模。目前，基于Verilog的验证平台有SystemVerilog验证平台、OVM验证平台、VMM验证平台、UVM验证平台等，其可以实现基于Verilog(包括SystemVerilog)建模的芯片验证，并支持事务级传输模型的接口通信。

因此，在本申请实施例中可以通过TLI接口将待验证的SystemC设计与已有Verilog RTL验证平台连接起来。可参见图2所示。

需要注意的是，本申请实施例中所述的已有Verilog RTL验证平台为已实现过所述SystemC设计对应的Verilog设计的验证的验证平台。示例性的，可以在针对芯片先进行了Verilog设计的验证之后，将验证成功后的验证平台作为本申请实施例的已有VerilogRTL验证平台，以确保对SystemC设计的验证的可靠性。

而为了使得TLI接口能够被正确调用，并能够像待验证的SystemC设计传输相关验证所需的数据，则需要按照仿真系统(如VCS、VCSMX等)和TLI手册的要求进行相关接口、文件名以及函数的设置。

需要说明的是，本申请实施例中所述的已有Verilog RTL验证平台是指，之前已搭建好的，用于对Verilog设计成功进行验证的Verilog RTL验证平台。

S102：按照仿真系统和TLI手册的要求，配置TLI接口以及SystemC文件名，并配置SystemC设计与已有Verilog RTL验证平台之间的调用函数。

在本申请实施例中，所需配置的TLI接口应包括有从SystemC设计到已有VerilogRTL验证平台的TLI接口，以及从已有Verilog RTL验证平台到SystemC设计的TLI接口，从而实现验证所需信息接收与响应。

在本申请实施例中，配置TLI接口主要是按照仿真系统和TLI手册的要求，配置好TLI接口名，定义好各TLI接口的作用。

在本申请实施例中，参见图3所示，TLI接口可以包括第一TLI接口，通过第一TLI接口连接待验证的SystemC设计的输入端与已有Verilog RTL验证平台的激励源，从而实现对于激励源的复用。

此外，在本申请实施例中，已有Verilog RTL验证平台，如SystemVerilog验证平台等，其通常是通过Master(主)VIP模块实现的激励源到Verilog设计的输入，而Master VIP模块同样可以作为验证环境要素在进行SystemC设计的验证时进行复用。因此，在本申请实施例中，可以参见图4所示，可以通过第一TLI接口连接待验证的SystemC设计的输入端与已有Verilog RTL验证平台的Master VIP模块，从而同时实现对于激励源和Master VIP模块的复用。

应理解，对于已有Verilog RTL验证平台，如SystemVerilog验证平台等，Slaver(从)VIP模块同样是实现Verilog设计的验证的验证环境之一。在本申请实施例中，可参见图5所示，TLI接口可以包括第二TLI接口，通过第二TLI接口连接待验证的SystemC设计与已有Verilog RTL验证平台的Slaver VIP模块。

需要理解的是，在本申请实施例中，Master VIP模块可以采用AXI(AdvancedeXtensible Interface，先进可扩展接口)Master VIP模块来实现，而Slaver VIP模块则可以采用DRAMC(DRAM controller，动态随机存取存储控制器)Slaver VIP模块来实现。

而对于SystemC文件名，则可以配置所有接口信号的输入文件以及输出文件，以及SystemC头文件和顶层Top文件。具体而言，可以根据仿真系统关于TLI的要求，制定对应的.idf文件(所有接口信号的输入文件、输出文件，以及顶层Top文件)以及对应的SystemC头文件。

需要理解的是，对于TLI接口以及SystemC文件名的配置根据仿真系统和TLI手册的要求进行配置即可，其配置方式为现有方式，在此不进行赘述。

需要注意的是，在本申请实施例中，调用函数是用于从已有Verilog RTL验证平台处调用验证环境要素。调用函数的配置同样需要按照仿真系统的要求进行配置，从而满足仿真要求。

在本申请实施例中，配置的调用函数包括但不限于：将已有Verilog RTL验证平台激励发送至SystemC设计的函数，配置寄存器的函数，systemC设计响应激励请求的函数。

在本申请实施例中，从已有Verilog RTL验证平台处调用验证环境要素包括但不限于以下至少之一：激励源、Master VIP、Slave VIP等。

需要注意的是，在本申请实施例中，芯片验证工程师可以首先规划验证环境目录结构，进而根据规划的验证环境目录结构来配置TLI接口以及SystemC文件名。验证环境目录结构的作用在于明确各TLI接口以及SystemC文件名直接的关联以及层级关系，从而便于进行TLI接口以及SystemC文件名的管理。

需要理解的是，在配置TLI接口、SystemC文件名以及调用函数时，可以先和芯片设计工程师沟通相关TLI接口、SystemC文件名的命名等相关事宜，从而便于在整个芯片设计过程中，能够使得涉及到的各方达成一致，从而便于整个芯片设计项目的推进。

S103：根据配置的TLI接口、SystemC文件名以及调用函数编译仿真脚本。

在本申请实施例中，在配置好TLI接口、SystemC文件名以及调用函数后，可以按照仿真系统的配置要求将配置的TLI接口、SystemC文件名以及调用函数编译到仿真脚本中，从而使得仿真脚本能够成功被执行。

需要理解的是，仿真脚本可以采用已有脚本，所谓编译可以理解为按照仿真系统的配置要求(比如VCS手册的要求)，将相关配置的TLI接口、SystemC文件名以及调用函数写入已有脚本的相应位置，从而使得脚本执行时能够正确调用相应的接口、文件以及函数。

S104：在SystemC设计完成后，仿真系统执行仿真脚本进行仿真验证。

需要理解的是，本申请实施例中，步骤S101至步骤S103可以在SystemC设计完成之前即执行，当然，也可以在SystemC设计完成之后再执行，步骤S101至步骤S103对于SystemC设计的完成与否并无要求。

在本申请实施例中，可以配置相应的核验模块(比如计分板)，来对SystemC设计的仿真结果进行核验。

示例性的，参见图6所示，可以在SystemC设计的输出端和已有Verilog RTL验证平台中的Verilog设计的输出端设置第一核验模块，从而将SystemC设计的输出和已有Verilog RTL验证平台中的Verilog设计的输出输入到第一核验模块，以使第一核验模块对SystemC设计的输出进行核验。

示例性的，在同样激励的情况下，第一核验模块可以通过比较verilog设计的输出和SystemC设计的输出是否一致，从而实现核验。

此外，本申请实施例中也可以在SystemC设计的输入端和输出端之间设置第二核验模块，从而将SystemC设计的输入和SystemC设计的输出输入到第二核验模块，以使第二核验模块对SystemC设计的输出进行核验。

示例性的，可以编写systemC记分板来作为第二核验模块，通过比较SystemC设计的输出是否符合SystemC设计的输入的预期，从而实现核验。该核验方式可参考对verilog设计的核验来实现。

应理解，前述第一核验模块和第二核验模块可以仅设置其中一种，但是也可以如图6所示，同时设置第一核验模块和第二核验模块。

需要说明的是，在本申请实施例中，由于涉及到SystemC这一语言，在调试过程中可能会遇到困难。

为此，在本申请实施例中，可以采用DVE软件中的协同C语言的功能来进行调试。应理解，DVE有协同C语言进行调试的功能，可以打开这个功能，从而很方便地进行仿真调试。

此外，在本申请实施例中也可以直接使用DVE gui模块来进行调试，调试过程如下：

simv-gui

Simulator>Setup

Simulator>C/C++Debugger

如果想设置断点，则按照下述方式设置：

File>Open File

Simulator>BreakPoints

Simulator>Start/Continue

Simulator>Step or Next

需要说明的是，以上英文内容为DVE工具的选项，“>”表示操作顺序，段落顺序也表征操作顺序。

在本申请实施例中，也可以不用DVE gui模块来进行调试。示例性的，可以在仿真打开VPD(VCDPlus Dumping，是一种波形文件格式)文件时，在波形中看到transaction(事务)信息，可以在相应的SystemC文件中加入informationcodes(信息代码)(比如tblog或者msglog)。通过这种方式，可以在仿真结束后，打开相应VPD文件，把相应的transaction信息移动到波形中去，实现仿真调试。

本申请实施例中提供的实现SystemC验证的方法，基于已有的Verilog RTL验证平台，通过TLI接口将待验证的SystemC设计接入该已有的Verilog RTL验证平台中，并按照相关手册要求配置好接口、文件名以及调用函数，从而实现从已有Verilog RTL验证平台处调用验证环境要素，实现对于已有Verilog RTL验证平台处的验证环境的复用。这样就降低了对芯片验证工程师的要求，使得芯片验证工程师只需要了解TLI接口相关配置知识以及基本的SystemC设计知识，降低了实现SystemC验证的难度。同时，由于已有Verilog RTL验证平台已经验证过Verilog RTL，因此已有Verilog RTL验证平台的验证效果通常是可靠的，因此结合Verilog RTL验证平台也可以更为有效地评价SystemC验证的效果。

实施例二：

本申请实施例提供了一种用于实现SystemC验证的验证平台组件架构，参见图2所示，包括：

待验证的SystemC设计，已实现过Verilog设计的验证的已有Verilog RTL验证平台以及TLI接口。其中，TLI接口连接待验证的SystemC设计与所述已有Verilog RTL验证平台。

应理解，仅是该验证平台组件架构并不能实现对于SystemC设计的验证，需要对相应的TLI接口进行配置、SystemC文件名以及调用函数，并将配置的这些TLI接口、SystemC文件名以及调用函数编译到仿真脚本中才行。

在本申请实施例中，参见实施例一的介绍，需要按照仿真平台以及TLI手册的要求进行TLI接口、SystemC文件名以及调用函数的调用以及仿真脚本编译。

在本申请实施例中，SystemC设计由工程师进行设计得到。

在本申请实施例所提供的验证平台组件架构中，可参见图3所示，TLI接口可以包括第一TLI接口，通过第一TLI接口连接待验证的SystemC设计的输入端与已有Verilog RTL验证平台的激励源，从而实现对于激励源的复用。

在本申请实施例所提供的验证平台组件架构中，也可参见图4所示，已有VerilogRTL验证平台中，激励源通过主VIP模块与已有Verilog RTL验证平台中的Verilog设计连接。而第一TLI接口则连接于待验证的SystemC设计与已有Verilog RTL验证平台的MasterVIP模块之间，从而同时实现对于激励源和Master VIP模块的复用。

在本申请实施例所提供的验证平台组件架构中，可参见图5所示，已有VerilogRTL验证平台中，Verilog设计输出端与Slaver VIP模块连接。而TLI接口可以包括第二TLI接口，第二TLI接口与Slaver VIP模块连接，从而实现对于Slaver VIP模块的复用。

需要理解的是，在本申请实施例中，Master VIP模块可以采用AXI Master VIP模块来实现，而Slaver VIP模块则可以采用DRAMC Slaver VIP模块来实现。

此外，在本申请实施例所提供的验证平台组件架构中，还可以配置核验模块(比如计分板等模块)，来实现对于SystemC设计的仿真结果进行核验。

示例性的，可参见图6所示，可以在SystemC设计的输出端和已有Verilog RTL验证平台中的Verilog设计的输出端设置第一核验模块，从而将SystemC设计的输出和已有Verilog RTL验证平台中的Verilog设计的输出输入到第一核验模块，以使第一核验模块对SystemC设计的输出进行核验。

此外，本申请实施例中也可以在SystemC设计的输入端和输出端之间设置第二核验模块，从而将将SystemC设计的输入和SystemC设计的输出输入到第二核验模块，以使第二核验模块对SystemC设计的输出进行核验。

应理解，前述第一核验模块和第二核验模块可以仅设置其中一种，但是也可以同时设置第一核验模块和第二核验模块。

本申请实施例中提供的用于实现SystemC验证的验证平台组件架构，基于已有Verilog RTL验证平台实现，不需要再重新完整搭建整个验证平台，在按照仿真系统和TLI手册的要求配置TLI接口、SystemC文件名、以及SystemC设计与已有Verilog RTL验证平台之间的调用函数之后，即可实现对于已有Verilog RTL验证平台的验证环境的复用，从而降低了对芯片验证工程师的要求，使得芯片验证工程师只需要了解TLI接口相关配置知识以及基本的SystemC设计知识，降低了实现SystemC验证的难度。同时，由于已有Verilog RTL验证平台已经验证过Verilog RTL，因此已有Verilog RTL验证平台的验证效果通常是可靠的，因此结合Verilog RTL验证平台也可以更为有效地评价SystemC验证的效果。

实施例三：

本实施例在前述实施例的基础上，以一种具体的实现SystemC验证的过程为例，对本申请的方案进行示例说明。

假设，仿真系统为VCS，已有Verilog RTL验证平台为SystemVerilog平台，MasterVIP模块为AXI Master VIP模块，Slaver VIP模块为DRAMC Slaver VIP模块。

实现SystemC验证的过程包括以下7步：

1.规划验证平台组件架构。

参见图7所示，图7中，核验模块为计分器，SC为SystemC的简称(后文相同)，SV为SystemVerilog的简称(后文相同)。EMI SC表征SystemC设计，而EMI SV表征SystemVerilog设计。

其中，图7中线框内的部分即为已有的SystemVerilog平台。

2.规划验证环境目录结构，并和SystemC RTL设计工程师讨论沟通，确定接口，SystemC文件名等相关事宜，直至双方达成一致。

3.配置所有TLI接口：

1)、定义AXI->EMI(0～6masters)(定义AXI到EMI的7个AXI master的TLI接口名，可以理解为定义用于传输激励的“传送带”)：

axi0_if_adapt_vlog

axi1_if_adapt_vlog

axi2_if_adapt_vlog

axi3_if_adapt_vlog

axi4_if_adapt_vlog

axi5_if_adapt_vlog

axi6_if_adapt_vlog

2)、定义EMI->AXI(0～6masters)(定义EMI到AXI的7个响应AXI master请求的TLI接口名，可以理解为定义用于响应激励的“传送带”)

axi_s0_if_adapt_sc

axi_s1_if_adapt_sc

axi_s2_if_adapt_sc

axi_s3_if_adapt_sc

axi_s4_if_adapt_sc

axi_s5_if_adapt_sc

axi_s6_if_adapt_sc

3)、EMI->DRAMC(定义EMI到DRAMC的TLI接口名，可以理解为定义用于传输设计输出的“传送带”)

emi_chn0_if_adapt_sc

emi_chn1_if_adapt_sc

4)、DRAMC->EMI(定义DRMAC到EMI响应请求的TLI接口名，可以理解为定义用于传输设计输出响应的“传送带”)

dramc_chn0_if_adapt_vlog

dramc_chn1_if_adapt_vlog

dramc_rsp0_if_adapt_vlog

dramc_rsp1_if_adapt_vlog

5)、Register configuration interface(定义寄存器配置的TLI接口名)

apb2emi_if_adapt_vlog

4.配置所有接口的.idf文件(实际包括所有接口信号的输入/输出文件，以及SystemC头文件和顶层Top文件)：

1)、axi0_if.idf:(根据VCS手册关于TLI的要求，指定对应的.idf文件)

input byte aid

input bit[3:0]len

input bit wr

input bit[15:0][63:0]data

2)、axi0_if.h：(根据VCS手册关于TLI的要求，指定对应的SystemC头文件)

char aid

svBitVec32len

unsigned char wr

viod*data

5.配置所有SV_call_SC以及SC_call_SV的事项任务(本申请中称为调用函数)

1)、SV_call_SC(SV至SC的调用函数)

1.1)new_transaction(output byte aid,bit[3:0]len,bit[2:0]size,bit[2:0]prot,bit[1:0]burst,bit[1:0]lock,int sideband,bit wr,intaddr,bit[15:0][63:0]data,bit[15:0][7:0]strb,int avalid2wvalid_delay,intbvalidbready_delay,bit[15:0][31:0]rvalidrready_delay,bit[15:0][31:0]new_wvalid_delay)(该代码表征复用已有验证平台激励所制定的发送到SystemC设计的函数/数据)

1.1.1)avalid2wvalid_delay:it’s the delay between transfer of thefirst beat of the w data and the address phase

1.1.2)new_wvalid_delay:it’s the delay between individual wvalid bustof write traffics

1.1.3)bvalidbready_delay:it’s the delay between bvalid and bready

1.1.4)rvalidrready_delay:it’s the delay between rvalid and rready

1.1.5)For port0～2:data is 64bit bit[15:0][63:0]data,strb is 8bit bit[15:0][7:0]strb

1.1.6)For port3～6:data is 128bit bit[15:0][127:0]data,strb is 16bitbit[15:0][15:0]strb

1.2)config_register(output intaddr,intwdata)(该代码表征制定配置寄存器的函数/数据)

2)、SC_call_SV(SC至SV的调用函数)

2.1)transaction_complete(input byte rid,bit[1023:0]data,bit[1:0]rsp,bit wr,intrsp_delay,intaready_delay)(该代码表征制定systemC设计响应激励请求的函数/数据)

2.1.1)Rsp_delay:it’s the delay between received cmd and response toaxi

2.1.2)Aready_delay:it’s the delay between avalid and aready

6.等待systemC设计完成

7.脚本开始编译仿真

syscan-full64-idf../../tli/apb2emi_if.idf(该代码表征根据VCS手册要求编译所有定义的idf文件)

syscan-cflags-g

syscan-sysc＝2.2-cpp g++-cflags“-I/*/systemc/2.2.0/i686/include-I/*/systemc/2.2.0/i686/include/tlm-I/*/systemc/2.2.0/i686/include/tlm/tlm_utils”-cflags-m64-cflags-I../../SC-cflags-I../../tli-cflags-I/*/VCS/1006SP1-4/include-full64-cflags“-g”../../sim/vmm/axi_s*_if_adapt_sc.cpp(该代码表征根据VCS手册要求编译SC call SV的cpp文件)

syscan-sysc＝2.2-cpp g++-cflags“-I/*/systemc/2.2.0/i686/include-I/*/systemc/2.2.0/i686/include/tlm-I/*/systemc/2.2.0/i686/include/tlm/tlm_utils”-cflags-m64-cflags-I../../SC-cflags-I../../tli-cflags-I/*/VCS/1006SP1-4/include-full64-cflags“-g”../../sim/vmm/axi0_if_adapt_sc.cpp../../sc/axi0.cpp../../tli/Top.cpp(该代码表征根据VCS手册要求编译SC call SV的cpp文件)

vcs-sysc＝2.2-cpp g++-cc gcc-cflags-g-cflags“-I/*/systemc/2.2.0/i686/include-I/*/systemc/2.2.0/i686/include/tlm-I/*/systemc/2.2.0/i686/include/tlm/tlm_utils”-cflags-m64-full64-sverilog-sysc-debug_all+vcs+lic+wait-timescale＝1ns/1ps-l vcs.log+acc+vcsd+vpi-lca-cm_hier-cm line+cond+fsm+define+NTB-ntb_optsoptmem-assert enable_diag+define+SVA_ON+SVA_VMM_LOG_0-CFLAGS-DVCS axi_s0_if_adapt_vlog.sv../axi_so.v......(所有SC的文件)axi0_if_adapt_vlog.sv......(所有SV_call_SC的文件)-f./filelist/list_tba.f(该代码表征根据VCS手册要求编译SV call SC的sv文件以及所有SC的so库文件)

simv(仿真)

通过本申请实施例的方案，可以有效复用已有资源(仿真平台+验证过的VerilogRTL)，从而用简单高效的方式实现了对重构SystemC RTL建模设计的充分验证，最大程度节约人力，缩短项目周期，为SOC利用SystemC建模进行架构分析和性能优化奠定了充分的基础。

在本申请所提供的实施例中，应该理解到，所揭露方法，可以通过其它的方式实现。以上所描述的实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

在本文中，多个是指两个或两个以上。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种实现SystemC验证的方法，其特征在于，包括：

通过事务级TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接；所述已有Verilog RTL验证平台为已实现过所述SystemC设计对应的Verilog设计的验证的验证平台；

按照仿真系统和TLI手册的要求，配置所述TLI接口以及SystemC文件名，并配置所述SystemC设计与所述已有Verilog RTL验证平台之间的调用函数；所述调用函数用于从所述已有Verilog RTL验证平台处调用验证环境要素；

根据配置的所述TLI接口、所述SystemC文件名以及所述调用函数编译仿真脚本；

在SystemC设计完成后，所述仿真系统执行所述仿真脚本进行仿真验证。

2.如权利要求1所述的实现SystemC验证的方法，其特征在于，通过TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接，包括：

通过第一TLI接口连接所述待验证的SystemC设计的输入端与所述已有Verilog RTL验证平台的激励源。

3.如权利要求2所述的实现SystemC验证的方法，其特征在于，所述已有Verilog RTL验证平台中，激励源通过主VIP模块传输给所述已有Verilog RTL验证平台中的Verilog设计；

通过第一TLI接口连接所述待验证的SystemC设计的输入端与所述已有Verilog RTL验证平台的激励源，包括：

通过第一TLI接口连接所述待验证的SystemC设计的输入端与所述主VIP模块。

4.如权利要求1所述的实现SystemC验证的方法，其特征在于，所述已有Verilog RTL验证平台中的Verilog设计连接有从VIP模块；

通过TLI接口实现待验证的SystemC设计与已有Verilog RTL验证平台的连接，包括：

通过第二TLI接口连接所述待验证的SystemC设计与所述已有Verilog RTL验证平台的从VIP模块。

5.如权利要求1所述的实现SystemC验证的方法，其特征在于，所述方法还包括：

配置第一核验模块；

将所述SystemC设计的输出和所述已有Verilog RTL验证平台中的Verilog设计的输出输入到所述第一核验模块，以使所述第一核验模块对所述SystemC设计的输出进行核验。

6.如权利要求1所述的实现SystemC验证的方法，其特征在于，所述方还包括：

配置第二核验模块；

将所述SystemC设计的输入和所述SystemC设计的输出输入到所述第二核验模块，以使所述第二核验模块对所述SystemC设计的输出进行核验。

7.如权利要求1所述的实现SystemC验证的方法，其特征在于，在配置TLI接口以及SystemC文件名之前，所述方法还包括：

规划验证环境目录结构；

所述按照仿真系统和TLI手册的要求，配置TLI接口以及SystemC文件名包括：

按照所述验证环境目录结构，并按照所述仿真系统和所述TLI手册的要求，配置TLI接口以及SystemC文件名。

8.如权利要求1所述的实现SystemC验证的方法，其特征在于，配置SystemC文件名，包括：

配置所有接口信号的输入文件以及输出文件，以及SystemC头文件和顶层Top文件。

9.如权利要求1-8任一项所述的实现SystemC验证的方法，其特征在于，所述已有Verilog RTL验证平台为以下之一：

SystemVerilog验证平台；

OVM验证平台；

VMM验证平台；

UVM验证平台。

10.如权利要求1-8任一项所述的实现SystemC验证的方法，其特征在于，所述验证环境要素包括以下至少之一：

激励源；

主VIP；

从VIP。

11.一种用于实现SystemC验证的验证平台组件架构，其特征在于，包括：

待验证的SystemC设计；

已实现过Verilog设计的验证的已有Verilog RTL验证平台；

事务级TLI接口，连接所述待验证的SystemC设计与所述已有Verilog RTL验证平台；其中，

所述TLI接口，以及验证所述SystemC设计涉及到的SystemC文件名和用于实现验证环境要素调用的调用函数，按照仿真系统和TLI手册的要求进行配置，并编译至仿真脚本中。

Images