CN114707450A - 基于SystemC的虚拟模型生成方法、系统、介质及设备 - Google Patents

Abstract

本发明提供了一种基于SystemC的虚拟模型生成方法、系统、介质及设备，方法包括：接收用户输入的硬件模块的名称，并基于硬件模块执行第一脚本，以生成模型目录结构；接收用户输入的寄存器描述文件，通过第二脚本解析寄存器描述文件，以在模型目录结构中生成基于SystemC的寄存器模型；执行第三脚本，以基于寄存器模型在模型目录结构中生成硬件模块的虚拟模型的源码文件；接收用户在源码文件上添加的针对硬件模块的自定义功能信息，以得到实现自定义功能的虚拟模型。本发明极大缩短了硬件模块虚拟模型的开发时间。

Description

基于SystemC的虚拟模型生成方法、系统、介质及设备

技术领域

本发明涉及建模技术领域，尤其涉及一种基于SystemC的虚拟模型生成方法、系统、介质及设备。

背景技术

随着集成电路设计技术的迅速发展，集成电路的集成规模越来越大，片上系统的设计复杂度不断提高，设计复杂度的提高需要设计工具、设计方法的强有力支持，而之前的设计工具和设计方法显得有些力不从心。软硬件协同设计是目前片上系统设计的新型方法，其方法依据系统目标要求，通过综合分析系统软硬件功能及现有资源，最大限度地挖掘系统软硬件之间的并发性，协同设计软硬件体系结构，使得系统能工作在最佳状态。因此，建立系统级模型对系统功能进行抽象描述是实现软硬件协同设计的关键。目前存在多种建模方法，但是都有其局限性，如采用UML语言建模，可以方便地进行需求分析、系统功能描述，但UML不能对系统硬件进行描述，无法精确和严格地描述模型的行为；采用C/C++等描述语言时，在设计细化阶段，原始的C/C++描述必须手工转换为VHDL或Verilog语言，容易产生不一致性，使系统综合变得复杂。研究表明，具有较高的抽象能力，同时能体现出硬件设计中的信号同步、时间延迟、状态转换等物理信息的语言，才能给工程师提供一个系统级设计的公共基础平台。在常用的设计语言中，C、C++和Java等高级编程语言有较高的抽象能力，但由于不能体现硬件设计的物理特性，硬件模块部分需重新用硬件描述语言设计，使得后续设计缺乏连贯性；而VHDL、Verilog最初目的并不是进行电路设计，前者是用来描述电路的，而后者起源于板级系统仿真，因此它们并不适合进行系统级的软件和算法设计，特别是现在系统中的功能越来越多的由软件来完成。

SystemC是在C++的基础上扩展了硬件类和仿真核形成的，由于结合了面向对象编程和硬件建模机制原理两方面的优点，这可以使SystemC在不同的层次进行系统设计。对一个片上系统在不同的层次进行描述，按照其抽象程度由高到低，可分为功能级(functionlevel，也称为系统级)、事务级(transaction level，也称为行为级或算法级)、寄存器传输级(RTL，register transfer level)、门级(gate level)和开关级(switch level)。其中功能级主要完成对整个系统功能的定义和结构的探索；事务级确保一些核心算法和系统行为的正确；寄存器传输级利用组合逻辑和时序逻辑来描述电路；而门级主要偏重利用工艺库的原件进行描述。在片上系统设计建模中，事务(transaction)是一个十分重要的概念。一般来说，事务可以理解为系统模型中两个组件之间的一次数据交换。一个数据交易可能是在系统组件之间传输的单个字、一列字或者整个数据结构。例如，一个DMA(Direct MemoryAccess，直接存储器访问)主设备能够发出请求，从存储器中读入一个数据。它首先要发出一个读交易，指定目标存储器的地址。另外一种情况是，当嵌入式的软件要向DMA控制器中写入控制字时，就会发出一个写交易。为保证片上系统的模块之间的同步所做的操作可以被看作是一个事件交易；而组件之间的中断也可以被视为一个交易。事务级模型(TLM，Transaction Level Model)中的各个模块代表了最终要实现的硬件设备(如存储器、ASIC、系统总线等等)，或者是将要运行在处理器上的软件。有关事务级建模的研究乃是当今学术界和产业界的一个热点。

现代的片上系统芯片包含硬件和软件，软件部分可以是固件或者驱动；芯片市场是一个充满竞争的市场，几乎所有的芯片公司对产品都有严格时间规划；如何让产品尽快面市，如何减少产品缺陷几乎是所有芯片公司都需要面对的难题，SystemC可以让软硬件并行开发，加快产品面市时间。

传统的设计流程中在FPGA(Field Programmable Gate Array，现场可编程逻辑门阵列)原型出来之前，硬件和软件开发之间几乎没有交流；只有在经过漫长的“设计-验证-综合”流程后(一般几个月)，软件才能在FPGA平台上测试自己的代码，由于软件设计时没有平台测试，此时测试必然有很多错误，这种错误需要修改硬件或软件，并重新迭代，这将浪费大量的时间。显然，传统的设计流程与此目标不符。因此，在软硬件设计之前，先开发抽象的基于SystemC的虚拟原型，然后硬件部门将此模型转化为RTL(Register TransferLevel，寄存器转换级电路)，软件部门在此模型上开发软件，如此一来，软硬件的任何错误都能尽早被发现并修改，大大节省了开发时间。

一个片上系统可以看作是由一个或多个主模块(如CPU)、一个或多个NOC(片上网络)、多个从模块(硬件设备)组成的系统，每个主模块可以通过特定的路径访问其中一个或多个从模块。对于主模块，主流CPU(中央处理器)厂商如ARM提供对于其ARM CPU的SystemC模型；对于NOC，厂商也有其NOC的SystemC模型；而对于硬件设备，由于其在形态、功能、复杂度、应用等各方面多种多样，目前没有一个标准的虚拟模型开发流程。

发明内容

有鉴于此，本发明的目的在于提出一种基于SystemC的虚拟模型生成方法、系统、介质及设备，用以解决目前对于硬件设备缺乏标准的虚拟模型开发的问题。

基于上述目的，本发明提供了一种基于SystemC的虚拟模型生成方法，包括以下步骤：

接收用户输入的硬件模块的名称，并基于硬件模块执行第一脚本，以生成模型目录结构；

接收用户输入的寄存器描述文件，通过第二脚本解析寄存器描述文件，以在模型目录结构中生成基于SystemC的寄存器模型；

执行第三脚本，以基于寄存器模型在模型目录结构中生成硬件模块的虚拟模型的源码文件；

接收用户在源码文件上添加的针对硬件模块的自定义功能信息，以得到实现自定义功能的虚拟模型。

在一些实施例中，方法还包括：

搭建用于测试自定义功能的测试平台，并将测试平台的代码填入模型目录结构中相应的目录文件内。

在一些实施例中，寄存器模型对应的生成文件包括定义型文件和操作型文件，定义型文件包括寄存器模型类及相关常量参数，操作型文件包括针对寄存器的域的读操作函数及写操作函数。

在一些实施例中，操作型文件还包括值获取函数，值获取函数用于获取寄存器的所有位的原始值。

在一些实施例中，读操作函数用于对原始值中属于指定域所在位的值进行读操作；写操作函数用于对原始值中属于指定域所在位的值进行写操作。

在一些实施例中，源码文件中具有读回调函数和写回调函数。

在一些实施例中，方法还包括：

响应于应用软件通过接口发出读寄存器指令，基于读寄存器指令调用读回调函数；

响应于应用软件通过接口发出写寄存器指令，基于写寄存器指令调用写回调函数。

本发明的另一方面，还提供了一种基于SystemC的虚拟模型生成系统，包括：

模型目录结构生成模块，配置用于接收用户输入的硬件模块的名称，并基于硬件模块执行第一脚本，以生成模型目录结构；

寄存器模型生成模块，配置用于接收用户输入的寄存器描述文件，通过第二脚本解析寄存器描述文件，以在模型目录结构中生成基于SystemC的寄存器模型；

源码文件生成模块，配置用于执行第三脚本，以基于寄存器模型在模型目录结构中生成硬件模块的虚拟模型的源码文件；以及

虚拟模型生成模块，配置用于接收用户在源码文件上添加的针对硬件模块的自定义功能信息，以得到实现自定义功能的虚拟模型。

本发明的又一方面，还提供了一种计算机可读存储介质，存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述方法。

本发明的再一方面，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该计算机程序被处理器执行时执行上述方法。

本发明至少具有以下有益技术效果：

本发明的基于SystemC的虚拟模型生成方法，使硬件模块的虚拟模型的开发人员只需要添加需要的功能，即可完成模块的虚拟模型的开发；通过快速生成硬件模块的虚拟模型框架，极大缩短了硬件模块虚拟模型的开发时间，从而有效节省了芯片的开发时间；另外，在片上系统开发的前期，架构人员用此虚拟模型进行硬件架构探索，评估算法性能，软件开发人员可将其作为软件开发的硬件原型，使软件可以提前开发；与传统的方法相比可以更为快速有效地进行系统软硬件协同仿真和优化，提高了片上系统设计的开发效率，加速了产品的面世。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的实施例。

图1为根据本发明实施例提供的基于SystemC的虚拟模型生成方法的示意图；

图2为根据本发明实施例提供的基于SystemC的虚拟模型生成系统的示意图；

图3为根据本发明实施例提供的实现基于SystemC的虚拟模型生成方法的计算机可读存储介质的示意图；

图4为根据本发明实施例提供的执行基于SystemC的虚拟模型生成方法的计算机设备的硬件结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明实施例进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称的非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备固有的其他步骤或单元。

基于上述目的，本发明实施例的第一个方面，提出了一种基于SystemC的虚拟模型生成方法的实施例。图1示出的是本发明提供的基于SystemC的虚拟模型生成方法的实施例的示意图。如图1所示，本发明实施例包括如下步骤：

步骤S10、接收用户输入的硬件模块的名称，并基于硬件模块执行第一脚本，以生成模型目录结构；

步骤S20、接收用户输入的寄存器描述文件，通过第二脚本解析寄存器描述文件，以在模型目录结构中生成基于SystemC的寄存器模型；

步骤S30、执行第三脚本，以基于寄存器模型在模型目录结构中生成硬件模块的虚拟模型的源码文件；

步骤S40、接收用户在源码文件上添加的针对硬件模块的自定义功能信息，以得到实现自定义功能的虚拟模型。

本实施例中，SystemC是一种软/硬件协同设计语言，一种新的系统级建模语言。它包含了一系列C++的类和宏，并且提供了一个事件驱动的模拟核，使得系统的设计者能够用C++的词法模拟并行的进程，特别是在片上系统中。

本发明实施例使得硬件模块的虚拟模型的开发人员只需要添加需要的功能，即可完成模块的虚拟模型的开发；通过快速生成硬件模块的虚拟模型框架，极大缩短了硬件模块虚拟模型的开发时间，从而有效节省了芯片的开发时间；在片上系统开发的前期，架构人员用此虚拟模型进行硬件架构探索，评估算法性能，软件开发人员可将其作为软件开发的硬件原型，使软件可以提前开发；与传统的方法相比可以更为快速有效地进行系统软硬件协同仿真和优化，提高了片上系统设计的开发效率，加速产品的面世。

在一些实施例中，方法还包括：搭建用于测试自定义功能的测试平台，并将测试平台的代码填入模型目录结构中相应的目录文件内。

在一些实施例中，寄存器模型对应的生成文件包括定义型文件和操作型文件，定义型文件包括寄存器模型类及相关常量参数，操作型文件包括针对寄存器的域的读操作函数及写操作函数。

在一些实施例中，操作型文件还包括值获取函数，值获取函数用于获取寄存器的所有位的原始值。

在一些实施例中，读操作函数用于对原始值中属于指定域所在位的值进行读操作；写操作函数用于对原始值中属于指定域所在位的值进行写操作。

在一些实施例中，源码文件中具有读回调函数和写回调函数。

在一些实施例中，方法还包括：响应于应用软件通过接口发出读寄存器指令，基于读寄存器指令调用读回调函数；响应于应用软件通过接口发出写寄存器指令，基于写寄存器指令调用写回调函数。

以下为本发明的基于SystemC的虚拟模型生成方法的具体实施例：

1.生成模型的文件框架

根据用户输入的模块名称，执行第一脚本，快速生成相应的模型模块目录层级及文件。生成的模型的顶层目录以模块名来命名，<module>表示用户输入的模块名称。

自动生成的模型目录结构说明如下表：

2.生成寄存器模型

本发明可以通过预先定义好的寄存器文件，如符合业界标准的RDL、RALF、XML作为唯一的输入文件，也提供了自定义CSV文件来描述寄存器的定义。以寄存器描述文件作为输入，通过第二脚本进行解析，按照要求产生基于SystemC的寄存器模型。

例如，假设某个模块名为mymod，则生成的寄存器模型的类名为mymod_regs_stub，生成的文件包括mymod_regs_stub.h和mymod_regs_stub.cpp文件，mymod_regs_stub.h中定义模块寄存器类及相关常量参数，mymod_regs_stub.cpp文件实现模块寄存器的相关操作。

寄存器模型类基于自研库的vp_bus_slave类而派生，主要包括以下部分：

(1)常量定义

常量包括各寄存器的偏移地址、寄存器中硬件/软件可读/可写的位屏蔽标志、寄存器默认值、寄存器中每个域的位偏移和位屏蔽标志等，用于对寄存器或寄存器域的各种操作中。由于一个寄存器中并不一定所有的位都可读可写，需要通过相应的读写屏蔽位标志来过滤可读/可写的位。

假设模块中包含一个寄存器EX1，寄存器中有2个域，BFD1和BFD2，其中BFD1占用1位，在32位寄存器的bit0，BFD2占用2位，在32位寄存器的bit2和bit1，则常量定义如下：

static const SC_BSX::uint32 EX1_REG_OFFS＝0x0；

static const SC_BSX::uint32 EX1_REG_HW_WRITE_MASK＝0x7；

static const SC_BSX::uint32 EX1_REG_SW_READ_MASK＝0x7；

static const SC_BSX::uint32 EX1_REG_SW_WRITE_MASK＝0x7；

static const SC_BSX::uint32 EX1_REG_RST_VAL＝0x0；

static const SC_BSX::uint32 EX1_BFD1_MASK＝0x1；

static const SC_BSX::uint32 EX1_BFD1_OFFSET＝0；

static const SC_BSX::uint32 EX1_BFD2_MASK＝0x3；

static const SC_BSX::uint32 EX1_BFD2_OFFSET＝1；

其中SC_BSX为命名空间(namespace)的名称，本实施例实现的建模基本库的所有内容均定义在SC_BSX命名空间中，所有引用建模基本库的部分均使用SC_BSX::来引用。上述SC_BSX::uint32即为命名空间SC_BSX中的uint32类型。

(2)模块寄存器定义

模块的每个寄存器均为该模块的寄存器模型类的成员变量。

本示例模块只包含一个寄存器EX1，对应的成员变量名为EX1_REG，定义如下：

SC_BSX::Register32 EX1_REG；

其中Register32是本实施例实现的建模基本库中的32位寄存器类型定义。

(3)模块寄存器的域读写操作的实现

为每个寄存器的每个域定义读(get)和写(set)操作，基本格式为：

读：get<reg_name>_REG_<bitfield_name>；

写：set<reg_name>_REG_<bitfield_name>；

其中<reg_name>为寄存器名，<bitfield_name>为寄存器中的域的名字。

每个域的读/写操作均为模块的寄存器模型类的一个成员函数。

对于本示例模块的EX1寄存器的BFD1域，定义如下：

SC_BSX::uint32 getEX1_REG_BFD1()const{

return(EX1_REG.getRawValue()>>0)&0x1；

}

void setEX1_REG_BFD1(const SC_BSX::uint32 val){

EX1_REG＝(EX1_REG.getRawValue()&～(0x1<<0))|((val&0x1)<<0)；

}

其中getRawValue函数为寄存器类的成员函数，用于获取寄存器的原始值，即整个32位寄存器的取值。在寄存器原始值的基础上通过屏蔽其它无关的位来实现对指定域所在位的读写操作。

3.模型功能实现

在生成寄存器模型之后，执行产生模型功能模板的脚本，可产生模型的源码文件，用户只需在此基础上添加相应的自定义的模块特有功能，便可实现此模块的虚拟模型。

例如对于上述模块mymod，生成的模型文件包括mymod.h和mymod.cpp，其中mymod.h中定义模块模型，mymod.cpp中为模块模型的具体实现。

(1)模型的定义

模型的定义在mymod.h文件中，模型的类mymod基于模块的寄存器模型类mymod_regs_stub而派生。主要关注的部分内容大致如下：

class mymod:public SC_BSX::mymod_regs_stub{

private:

//模块复位响应函数

void mymod_reset(void)；

//模块各寄存器的读写回调函数

ret_t EX1_REG_WriteCB(tlm_generic_payload&)；

ret_t EX1_REG_ReadCB(tlm_generic_payload&)；

}；

其中，模块复位响应函数、各寄存器的读写回调函数需要用户根据模块的实际功能，在模型实现部分添加。

(2)模型的实现

模型的实现在mymod.cpp文件中，主要包括以下内容：

①初始化时设置每个寄存器的读、写回调函数：

EX1_REG.setWriteCB(this,&mymod::EX1_REG_WriteCB)；

EX1_REG.setReadCB(this,&mymod::EX1_REG_ReadCB)；

其中setWriteCB和setReadCB函数是寄存器类的成员函数，分别实现设置寄存器写回调函数和设置寄存器读回调函数的功能。上述代码将EX1_REG_WriteCB函数设置为寄存器EX1_REG的写回调函数，将EX1_REG_ReadCB函数设置为寄存器EX1_REG的读回调函数。当寄存器EX1_REG被写入时，EX1_REG_WriteCB函数被调用；当寄存器EX1_REG被读取时，EX1_REG_ReadCB函数被调用。

②寄存器读写回调函数的具体实现：

读回调函数是在寄存器被软件读取时调用，实现如下：

ret_t mymod::EX1_REG_ReadCB(tlm_generic_payload&gp){

//Custom pre access functionality here

ret_t status＝EX1_REG.read(gp)；

//Custom post access functionality here

return status；

}

默认的读回调函数调用寄存器类的read函数，该函数将寄存器中软件可读的位的数据读取出来，写入参数gp中数据指针所指向的位置。如果该寄存器被读取时还会触发其它操作，则需要用户根据实际需求添加相关代码实现。例如，对于读清(Read Clear)的寄存器，当该寄存器被软件读取时，除了将该寄存器的数据送出之外，还需要将其清零，即读完之后将该寄存器的值设置为零。那么就需要在上述默认的读回调函数中的寄存器类的read函数调用之后添加将寄存器清零的操作。

写回调函数是在寄存器被软件写入时调用，实现如下：

ret_t mymod::EX1_REG_WriteCB(tlm_generic_payload&gp){

//Custom pre access functionality here

ret_t status＝EX1_REG.write(gp)；

//Custom post access functionality here

return status；

}

默认的写回调函数调用寄存器类的write函数，该函数向寄存器中软件可写的位写入指定的数据，要写入的数据由参数gp中数据指针所指向。如果该寄存器被写入时还会触发其它操作，则需要用户根据实际需求添加相关代码实现。例如，对于一些控制寄存器，当该寄存器被软件写入时，除了将指定的数据写入寄存器之外，还会触发硬件操作，如计数器开始计数，那么就需要在默认的写回调函数中的寄存器类的write函数调用之后添加开始计数的相关操作。

对于一个硬件模块来说，每个寄存器都是其功能的一部分，需要根据寄存器的实际功能决定是否需要修改默认的读写回调函数，以及如何修改。

③模块复位响应函数的实现

硬件模块需要能够被复位，当复位信号到来时，硬件模块恢复到初始状态或预先定义的复位状态。自动生成的模块模型定义了一个复位响应函数，用户需要根据模块的实际复位状态来实现这个函数。生成的代码框架如下：

void mymod::mymod_reset(void)

{

}

上述工作完成之后，模块的模型开发便完成了，模块提供了一个符合标准TLM2.0接口的target socket变量m_target_socket，用于与initiator模块的initiator socket进行绑定，从而实现基于TLM的通信。

4.测试平台实现

在功能模型实现之后，需要搭建测试平台对其功能进行测试。本发明自动生成测试平台，位于<module>/source/sc/tb目录下。

测试平台文件说明如下：

测试平台框架、相关组件连接、基础测试用例和测试用例示例均已自动生成，如果没有特殊需求，用户只需要根据实际模块的功能，仿照测试用例示例添加相应的测试用例即可。完成后在<module>/sc_sim目录下执行相应的命令进行编译和仿真，即可对模块功能进行测试。

本发明实施例的第二个方面，还提供了一种基于SystemC的虚拟模型生成系统。图2示出的是本发明提供的基于SystemC的虚拟模型生成系统的实施例的示意图。如图2所示，一种基于SystemC的虚拟模型生成系统包括：模型目录结构生成模块10，配置用于接收用户输入的硬件模块的名称，并基于硬件模块执行第一脚本，以生成模型目录结构；寄存器模型生成模块20，配置用于接收用户输入的寄存器描述文件，通过第二脚本解析寄存器描述文件，以在模型目录结构中生成基于SystemC的寄存器模型；源码文件生成模块30，配置用于执行第三脚本，以基于寄存器模型在模型目录结构中生成硬件模块的虚拟模型的源码文件；以及虚拟模型生成模块40，配置用于接收用户在源码文件上添加的针对硬件模块的自定义功能信息，以得到实现自定义功能的虚拟模型。

本发明实施例的第三个方面，还提供了一种计算机可读存储介质，图3示出了根据本发明实施例提供的实现基于SystemC的虚拟模型生成方法的计算机可读存储介质的示意图。如图3所示，计算机可读存储介质3存储有计算机程序指令31。该计算机程序指令31被处理器执行时实现上述任意一项实施例的方法。

应当理解，在相互不冲突的情况下，以上针对根据本发明的基于SystemC的虚拟模型生成方法阐述的所有实施方式、特征和优势同样地适用于根据本发明的基于SystemC的虚拟模型生成系统和存储介质。

本发明实施例的第四个方面，还提供了一种计算机设备，包括如图4所示的存储器402和处理器401，该存储器402中存储有计算机程序，该计算机程序被该处理器401执行时实现上述任意一项实施例的方法。

如图4所示，为本发明提供的执行基于SystemC的虚拟模型生成方法的计算机设备的一个实施例的硬件结构示意图。以如图4所示的计算机设备为例，在该计算机设备中包括一个处理器401以及一个存储器402，并还可以包括：输入装置403和输出装置404。处理器401、存储器402、输入装置403和输出装置404可以通过总线或者其他方式连接，图4中以通过总线连接为例。输入装置403可接收输入的数字或字符信息，以及产生与基于SystemC的虚拟模型生成系统的用户设置以及功能控制有关的键信号输入。输出装置404可包括显示屏等显示设备。

存储器402作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的基于SystemC的虚拟模型生成方法对应的程序指令/模块。存储器402可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储基于SystemC的虚拟模型生成方法的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器402可选包括相对于处理器401远程设置的存储器，这些远程存储器可以通过网络连接至本地模块。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

处理器401通过运行存储在存储器402中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的基于SystemC的虚拟模型生成方法。

最后需要说明的是，本文的计算机可读存储介质(例如，存储器)可以是易失性存储器或非易失性存储器，或者可以包括易失性存储器和非易失性存储器两者。作为例子而非限制性的，非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦写可编程ROM(EEPROM)或快闪存储器。易失性存储器可以包括随机存取存储器(RAM)，该RAM可以充当外部高速缓存存储器。作为例子而非限制性的，RAM可以以多种形式获得，比如同步RAM(DRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据速率SDRAM(DDRSDRAM)、增强SDRAM(ESDRAM)、同步链路DRAM(SLDRAM)、以及直接Rambus RAM(DRRAM)。所公开的方面的存储设备意在包括但不限于这些和其它合适类型的存储器。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。为了清楚地说明硬件和软件的这种可互换性，已经就各种示意性组件、方块、模块、电路和步骤的功能对其进行了一般性的描述。这种功能是被实现为软件还是被实现为硬件取决于具体应用以及施加给整个系统的设计约束。本领域技术人员可以针对每种具体应用以各种方式来实现的功能，但是这种实现决定不应被解释为导致脱离本发明实施例公开的范围。

以上是本发明公开的示例性实施例，但是应当注意，在不背离权利要求限定的本发明实施例公开的范围的前提下，可以进行多种改变和修改。根据这里描述的公开实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外，尽管本发明实施例公开的元素可以以个体形式描述或要求，但除非明确限制为单数，也可以理解为多个。

应当理解的是，在本文中使用的，除非上下文清楚地支持例外情况，单数形式“一个”旨在也包括复数形式。还应当理解的是，在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。上述本发明实施例公开实施例序号仅仅为了描述，不代表实施例的优劣。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子；在本发明实施例的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，并存在如上的本发明实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。因此，凡在本发明实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。

Claims (10)

1.一种基于SystemC的虚拟模型生成方法，其特征在于，包括以下步骤：

接收用户输入的硬件模块的名称，并基于所述硬件模块执行第一脚本，以生成模型目录结构；

接收用户输入的寄存器描述文件，通过第二脚本解析所述寄存器描述文件，以在所述模型目录结构中生成基于SystemC的寄存器模型；

执行第三脚本，以基于所述寄存器模型在所述模型目录结构中生成所述硬件模块的虚拟模型的源码文件；

接收用户在所述源码文件上添加的针对所述硬件模块的自定义功能信息，以得到实现所述自定义功能的所述虚拟模型。

2.根据权利要求1所述的方法，其特征在于，还包括：

搭建用于测试所述自定义功能的测试平台，并将所述测试平台的代码填入所述模型目录结构中相应的目录文件内。

3.根据权利要求1所述的方法，其特征在于，所述寄存器模型对应的生成文件包括定义型文件和操作型文件，所述定义型文件包括寄存器模型类及相关常量参数，所述操作型文件包括针对寄存器的域的读操作函数及写操作函数。

4.根据权利要求3所述的方法，其特征在于，所述操作型文件还包括值获取函数，所述值获取函数用于获取所述寄存器的所有位的原始值。

5.根据权利要求4所述的方法，其特征在于，所述读操作函数用于对所述原始值中属于指定域所在位的值进行读操作；所述写操作函数用于对所述原始值中属于所述指定域所在位的值进行写操作。

6.根据权利要求1所述的方法，其特征在于，所述源码文件中具有读回调函数和写回调函数。

7.根据权利要求6所述的方法，其特征在于，还包括：

响应于应用软件通过接口发出读寄存器指令，基于所述读寄存器指令调用所述读回调函数；

响应于所述应用软件通过所述接口发出写寄存器指令，基于所述写寄存器指令调用所述写回调函数。

8.一种基于SystemC的虚拟模型生成系统，其特征在于，包括：

模型目录结构生成模块，配置用于接收用户输入的硬件模块的名称，并基于所述硬件模块执行第一脚本，以生成模型目录结构；

寄存器模型生成模块，配置用于接收用户输入的寄存器描述文件，通过第二脚本解析所述寄存器描述文件，以在所述模型目录结构中生成基于SystemC的寄存器模型；

源码文件生成模块，配置用于执行第三脚本，以基于所述寄存器模型在所述模型目录结构中生成所述硬件模块的虚拟模型的源码文件；以及

虚拟模型生成模块，配置用于接收用户在所述源码文件上添加的针对所述硬件模块的自定义功能信息，以得到实现所述自定义功能的所述虚拟模型。

9.一种计算机可读存储介质，其特征在于，存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-7任意一项所述的方法。

10.一种计算机设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时执行如权利要求1-7任意一项所述的方法。

Images