Systemc-based virtual model generation method, system, medium and device

Abstract

The application provides a SystemC-based virtual model generation method, system, medium and equipment, the method comprises the following steps: receiving the name of a hardware module input by a user, and executing a first script based on the hardware module to generate a model directory structure; receiving a register description file input by the user, and parsing the register description file through a second script to generate a SystemC-based register model in the model directory structure; executing a third script to generate a source code file of a virtual model of the hardware module in the model directory structure based on the register model; receiving custom function information for the hardware module added by the user on the source code file to obtain a virtual model implementing the custom function. The application greatly shortens the development time of the virtual model of the hardware module.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of modeling, in particular to a virtual model generation method, system, medium and device based on SystemC. BACKGROUND

[0002] With the rapid development of integrated circuit design technology, the integrated scale of integrated circuits is getting larger and larger, and the design complexity of system on chip is increasing. The increase of design complexity requires strong support of design tools and design methods, and the previous design tools and design methods seem to be somewhat inadequate. Soft and hardware co-design is a new method for system on chip design, which is based on system target requirements, through comprehensive analysis of system software and hardware functions and existing resources, to maximize the concurrency between software and hardware, and to co-design the software and hardware architecture, so that the system can work in the best state. Therefore, the establishment of system-level model for abstract description of system function is the key to realize the soft and hardware co-design. At present, there are many modeling methods, but they all have their limitations, such as using UML language modeling, which can facilitate requirement analysis and system function description, but UML cannot describe system hardware, and cannot accurately and strictly describe the behavior of the model; when using C / C++ and other description languages, the original C / C++ description must be manually converted into VHDL or Verilog language at the design refinement stage, which is easy to produce inconsistency, making the system synthesis complex. Research shows that the language with high abstraction ability and reflecting the physical information of signal synchronization, time delay, state transition and other hardware design in the language can provide a common platform for system-level design for engineers. Among the commonly used design languages, C, C++ and Java have high abstraction ability, but they cannot reflect the physical characteristics of hardware design, so the hardware module part needs to be designed again with hardware description language, which makes the subsequent design lack of coherence; and VHDL and Verilog are not originally designed for circuit design, the former is used to describe circuits, and the latter originates from board-level system simulation, so they are not suitable for system-level software and algorithm design, especially now the functions in the system are more and more completed by software.

[0003] SystemC is a hardware class and simulation kernel extended on the basis of C++, which combines the advantages of object-oriented programming and hardware modeling mechanism, and can be used to design system at different levels. A system-on-chip can be described at different levels, from high to low, as function level (also called system level), transaction level (also called behavior level or algorithm level), register transfer level (RTL), gate level and switch level. The function level is mainly used to define the function and structure of the whole system; the transaction level is used to ensure the correctness of some core algorithms and system behaviors; the register transfer level is used to describe the circuit by using combinational logic and sequential logic; and the gate level is mainly used to describe the elements of the technology library. In the modeling of system-on-chip, transaction is a very important concept. Generally, transaction can be understood as a data exchange between two components in the system model. A data transaction can be a single word, a word list or an entire data structure transmitted between system components. For example, a DMA (Direct Memory Access) master can send a request to read a data from the memory. It first sends a read transaction to specify the address of the target memory. In another case, when the embedded software writes a control word to the DMA controller, a write transaction is sent. The operation for ensuring the synchronization between the modules of system-on-chip can be regarded as an event transaction; and the interruption between components can also be regarded as a transaction. The modules in the transaction level model (TLM) represent the hardware devices (such as memory, ASIC, system bus, etc.) to be implemented or the software to be run on the processor. The research on transaction level modeling is a hot topic in the academic and industrial fields.

[0004] Modern system-on-chip contains hardware and software, and the software part can be firmware or driver. The chip market is a competitive market, and almost all chip companies have strict time planning for products. How to make the product face the market as soon as possible and how to reduce product defects are difficult problems faced by almost all chip companies. SystemC can be used to develop software and hardware in parallel, and accelerate the time of product to face the market.

[0005] In the traditional design process, there is almost no communication between hardware and software development before the FPGA (Field Programmable Gate Array) prototype is out; only after a long "design-verification-combination" process (usually several months), the software can test its own code on the FPGA platform. Since the software is designed without platform testing, there will be many errors at this time, which need to modify the hardware or software and reiterate, which will waste a lot of time. Obviously, the traditional design process does not meet this goal. Therefore, before the software and hardware design, an abstract virtual prototype based on SystemC is developed first, and then the hardware department converts this model into RTL (Register Transfer Level), and the software department develops software on this model. In this way, any errors in software and hardware can be found and modified as soon as possible, greatly saving development time.

[0006] A system on chip can be regarded as a system composed of one or more master modules (such as CPU), one or more NOC (Network on Chip), and a plurality of slave modules (hardware devices), each master module can access one or more slave modules through a specific path. For master modules, mainstream CPU (Central Processing Unit) manufacturers such as ARM provide SystemC models for their ARM CPUs; for NOC, manufacturers also have SystemC models for their NOC; and for hardware devices, due to their various forms, functions, complexities, applications, etc., there is currently no standard virtual model development process. SUMMARY

[0007] Therefore, the purpose of the present application is to provide a SystemC-based virtual model generation method, system, medium and device to solve the problem of lack of standard virtual model development for hardware devices.

[0008] In order to achieve the above purpose, the present application provides a SystemC-based virtual model generation method, comprising the following steps:

[0009] Receiving the name of the hardware module input by the user, and executing a first script based on the hardware module to generate a model directory structure;

[0010] Receiving the register description file input by the user, and parsing the register description file through a second script to generate a SystemC-based register model in the model directory structure;

[0011] Executing a third script to generate a source code file of a virtual model of the hardware module in the model directory structure based on the register model;

[0012] Receiving custom function information added by a user on a source code file for a hardware module to obtain a virtual model for implementing the custom function.

[0013] In some embodiments, the method further comprises:

[0014] A test platform for testing the custom function is built, and codes of the test platform are filled into corresponding directory files in the model directory structure.

[0015] In some embodiments, the generated file corresponding to the register model comprises a definition file and an operation file, the definition file comprises a register model class and related constant parameters, and the operation file comprises a read operation function and a write operation function for a domain of the register.

[0016] In some embodiments, the operation file further comprises a value acquisition function, and the value acquisition function is used to acquire original values of all bits of the register.

[0017] In some embodiments, the read operation function is used to perform a read operation on values of bits belonging to the specified domain in the original values, and the write operation function is used to perform a write operation on values of bits belonging to the specified domain in the original values.

[0018] In some embodiments, the source code file comprises a read callback function and a write callback function.

[0019] In some embodiments, the method further comprises:

[0020] In response to the application software issuing a read register instruction through the interface, the read callback function is called based on the read register instruction.

[0021] In response to the application software issuing a write register instruction through the interface, the write callback function is called based on the write register instruction.

[0022] Another aspect of the present application also provides a SystemC-based virtual model generation system, comprising:

[0023] A model directory structure generation module configured to receive a name of a hardware module input by a user, and execute a first script based on the hardware module to generate a model directory structure.

[0024] A register model generation module configured to receive a register description file input by a user, and parse the register description file through a second script to generate a SystemC-based register model in the model directory structure.

[0025] A source code file generation module configured to execute a third script to generate a source code file of a virtual model of the hardware module in the model directory structure based on the register model; and

[0026] The virtual model generation module is configured to receive custom function information added by a user on a source code file for the hardware module to obtain a virtual model implementing the custom function.

[0027] Still another aspect of the present application provides a computer readable storage medium storing computer program instructions, which, when executed by a processor, implement the method described above.

[0028] Still another aspect of the present application provides a computer device comprising a memory and a processor, the memory storing a computer program, which, when executed by the processor, implements the method described above.

[0029] The present application has at least the following beneficial technical effects:

[0030] The virtual model generation method based on SystemC of the present application enables a developer of a virtual model of a hardware module to only add the required function to complete development of the virtual model of the module; the virtual model framework of the hardware module is quickly generated, which greatly shortens the development time of the virtual model of the hardware module, thereby effectively saving the development time of the chip; in addition, in the early stage of the development of the system on chip, an architect uses the virtual model to explore the hardware architecture and evaluate the algorithm performance, and a software developer uses the virtual model as a hardware prototype for software development, so that the software can be developed in advance; compared with the traditional method, the system software and hardware can be more quickly and effectively simulated and optimized, the development efficiency of the system on chip design is improved, and the product is accelerated to the market. BRIEF DESCRIPTION OF DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other embodiments can be obtained without creative labor on the basis of these drawings.

[0032] Figure 1 The schematic diagram of the virtual model generation method based on SystemC provided according to the embodiment of the present application;

[0033] Figure 2 The schematic diagram of the virtual model generation system based on SystemC provided according to the embodiment of the present application;

[0034] Figure 3 The schematic diagram of the computer readable storage medium implementing the virtual model generation method based on SystemC provided according to the embodiment of the present application;

[0035] Figure 4A hardware structure schematic diagram of a computer device for executing the SystemC-based virtual model generation method according to the embodiment of the present application is shown. DETAILED DESCRIPTION

[0036] In order to make the objects, technical solutions and advantages of the present application clearer, the embodiments of the present application are further described in detail below with reference to the drawings.

[0037] It should be noted that all the expressions of "first" and "second" in the embodiments of the present application are used to distinguish two non-identical entities or non-identical parameters with the same name, and it can be seen that "first" and "second" are only used for the convenience of description, and should not be understood as a limitation on the embodiments of the present application. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, the process, method, system, product or device inherently includes other steps or units.

[0038] Based on the above purpose, in a first aspect, an embodiment of a SystemC-based virtual model generation method is provided. Figure 1 An embodiment of the SystemC-based virtual model generation method provided by the present application is shown. As shown in the figure, Figure 1 The embodiment of the present application includes the following steps:

[0039] Step S10, receiving the name of the hardware module input by the user, and executing a first script based on the hardware module to generate a model directory structure;

[0040] Step S20, receiving the register description file input by the user, and parsing the register description file through a second script to generate a SystemC-based register model in the model directory structure;

[0041] Step S30, executing a third script to generate a source code file of a virtual model of the hardware module in the model directory structure based on the register model;

[0042] Step S40, receiving the custom function information for the hardware module added by the user on the source code file to obtain a virtual model implementing the custom function.

[0043] In the embodiment, SystemC is a soft / hardware co-design language, a new system-level modeling language. It contains a series of C++ classes and macros, and provides an event-driven simulation core, so that the designer of the system can simulate parallel processes with C++ syntax, especially in a system on chip.

[0044] The embodiment of the present application enables the developer of the virtual model of the hardware module to only add the required function, so as to complete the development of the virtual model of the module; the virtual model framework of the hardware module is quickly generated, so that the development time of the virtual model of the hardware module is greatly shortened, thereby effectively saving the development time of the chip; in the early stage of the development of the system on chip, the architecture personnel explores the hardware architecture and evaluates the algorithm performance by using the virtual model, and the software developer can take the virtual model as the hardware prototype of the software development, so that the software can be developed in advance; compared with the traditional method, the system software and hardware co-simulation and optimization can be more quickly and effectively performed, the development efficiency of the system on chip design is improved, and the product is accelerated to be put on the market.

[0045] In some embodiments, the method further comprises: building a test platform for testing the custom function, and filling the code of the test platform into the corresponding directory file in the model directory structure.

[0046] In some embodiments, the generated file corresponding to the register model comprises a definition type file and an operation type file, the definition type file comprises a register model class and related constant parameters, and the operation type file comprises a read operation function and a write operation function for the domain of the register.

[0047] In some embodiments, the operation type file further comprises a value acquisition function, and the value acquisition function is used to acquire the original value of all bits of the register.

[0048] In some embodiments, the read operation function is used to perform a read operation on the value of the bit belonging to the specified domain in the original value, and the write operation function is used to perform a write operation on the value of the bit belonging to the specified domain in the original value.

[0049] In some embodiments, the source code file has a read callback function and a write callback function.

[0050] In some embodiments, the method further comprises: in response to the application software issuing a read register instruction through the interface, calling the read callback function based on the read register instruction; and in response to the application software issuing a write register instruction through the interface, calling the write callback function based on the write register instruction.

[0051] The following is a specific embodiment of the virtual model generation method based on SystemC of the present application:

[0052] 1. Generating a file framework of a model

[0053] According to the module name input by a user, a first script is executed to quickly generate a corresponding model module directory level and file. The top directory of the generated model is named with the module name, <module>A module name representing a user input.

[0054] The automatically generated model directory structure is described in the following table:

[0055]

[0056] 2. Generating register model

[0057] The present application can take pre-defined register files, such as RDL, RALF, XML conforming to industry standards, as the only input file, and also provides a custom CSV file to describe the definition of the register. Taking the register description file as input, the second script is parsed to generate a SystemC-based register model according to the requirements.

[0058] For example, assuming that a module name is mymod, the class name of the generated register model is mymod_regs_stub, and the generated files include mymod_regs_stub.h and mymod_regs_stub.cpp files, mymod_regs_stub.h defines the module register class and related constant parameters, and mymod_regs_stub.cpp file implements the related operations of the module register.

[0059] The register model class is derived based on the vp_bus_slave class of the self-developed library, and mainly includes the following parts:

[0060] (1) Constant definition

[0061] The constants include the offset address of each register, the bit mask flag of the hardware / software readable / writable in the register, the default value of the register, the bit offset and bit mask flag of each domain in the register, etc., which are used in various operations on the register or register domain. Since not all bits in a register are necessarily readable and writable, the corresponding read / write mask flags are needed to filter the readable / writable bits.

[0062] Assuming that a module contains a register EX1, the register has 2 domains, BFD1 and BFD2, and BFD1 occupies 1 bit at bit0 of the 32-bit register, and BFD2 occupies 2 bits at bit2 and bit1 of the 32-bit register, then the constant definition is as follows:

[0063] static const SC_BSX::uint32 EX1_REG_OFFS = 0x0;

[0064] static const SC_BSX::uint32 EX1_REG_HW_WRITE_MASK = 0x7;

[0065] static const SC_BSX::uint32 EX1_REG_SW_READ_MASK = 0x7;

[0066] static const SC_BSX::uint32 EX1_REG_SW_WRITE_MASK = 0x7;

[0067] static const SC_BSX::uint32 EX1_REG_RST_VAL = 0x0;

[0068] static const SC_BSX::uint32 EX1_BFD1_MASK = 0x1;

[0069] static const SC_BSX::uint32 EX1_BFD1_OFFSET = 0;

[0070] static const SC_BSX::uint32 EX1_BFD2_MASK = 0x3;

[0071] static const SC_BSX::uint32 EX1_BFD2_OFFSET = 1;

[0072] Wherein SC_BSX is the name of namespace, all contents of modeling basic library implemented by the embodiment are defined in SC_BSX namespace, all parts referring to modeling basic library are referred by SC_BSX::. The above SC_BSX::uint32 is uint32 type in SC_BSX namespace.

[0073] (2) Module register definition

[0074] Each register of the module is a member variable of the register model class of the module.

[0075] The example module only contains one register EX1, and the corresponding member variable name is EX1_REG, which is defined as follows:

[0076] SC_BSX::Register32 EX1_REG;

[0077] Wherein Register32 is 32-bit register type definition in modeling basic library implemented by the embodiment.

[0078] (3) Implementation of domain read-write operation of module register

[0079] A get and a set operation are defined for each field of each register, with the basic format:

[0080] get: get<reg_name>_REG_<bitfield_name>;

[0081] set: set<reg_name>_REG_<bitfield_name>;

[0082] where <reg_name> is the name of the register and <bitfield_name> is the name of the field in the register.

[0083] Each get / set operation is a member function of the register model class of the module.

[0084] For the BFD1 field of the EX1 register of the example module, the following is defined:

[0085] SC_BSX::uint32 getEX1_REG_BFD1() const {

[0086] return (EX1_REG.getRawValue() >> 0) & 0x1;

[0087] }

[0088] void setEX1_REG_BFD1(const SC_BSX::uint32 val) {

[0089] EX1_REG = (EX1_REG.getRawValue() & ~(0x1 << 0)) | ((val & 0x1) << 0);

[0090] }

[0091] The getRawValue function is a member function of the register class, which is used to get the raw value of the register, i.e. the value of the entire 32-bit register. On the basis of the raw value of the register, the read / write operation on the bits of the specified field is implemented by masking other irrelevant bits.

[0092] 3. Model function implementation

[0093] After the register model is generated, the script for generating the model function template is executed to generate the source code file of the model. The user only needs to add the corresponding custom module-specific functions on this basis to realize the virtual model of the module.

[0094] For example, for the above module mymod, the generated model files include mymod.h and mymod.cpp, where the module model is defined in mymod.h and the specific implementation of the module model is in mymod.cpp.

[0095] (1) Definition of the model

[0096] The definition of the model is in the mymod.h file, and the class of the model mymod is derived from the register model class of the module mymod_regs_stub. The main content of interest is roughly as follows:

[0097] class mymod: public SC_BSX::mymod_regs_stub{

[0098] private:

[0099] / / Module reset response function

[0100] void mymod_reset(void);

[0101] / / Read and write callback functions of each register of the module

[0102] ret_t EX1_REG_WriteCB(tlm_generic_payload&);

[0103] ret_t EX1_REG_ReadCB(tlm_generic_payload&);

[0104] };

[0105] Among them, the module reset response function and the read and write callback functions of each register need to be added by the user according to the actual function of the module in the model implementation part.

[0106] (2) Implementation of the model

[0107] The implementation of the model is in the mymod.cpp file, which mainly includes the following contents:

[0108] ① Set the read and write callback functions of each register during initialization:

[0109] EX1_REG.setWriteCB(this, &mymod::EX1_REG_WriteCB);

[0110] EX1_REG.setReadCB(this, &mymod::EX1_REG_ReadCB);

[0111] EX1_REG. setWriteCB ( new EX1_REG_WriteCB ( ) ) ; EX1_REG. setReadCB ( new EX1_REG_ReadCB ( ) ) ; The above code sets the EX1_REG_WriteCB function as the write callback function of the register EX1_REG, and sets the EX1_REG_ReadCB function as the read callback function of the register EX1_REG. When the register EX1_REG is written, the EX1_REG_WriteCB function is called; when the register EX1_REG is read, the EX1_REG_ReadCB function is called.

[0112] 2. Implementation of the register read / write callback function:

[0113] The read callback function is called when the register is read by software, and is implemented as follows:

[0114] ret_t mymod::EX1_REG_ReadCB ( tlm_generic_payload & gp ) {

[0115] / / Custom pre access functionality here

[0116] ret_t status = EX1_REG. read ( gp ) ;

[0117] / / Custom post access functionality here

[0118] return status;

[0119] }

[0120] The default read callback function calls the read function of the register class, which reads the data of the software-readable bits in the register and writes it to the position pointed to by the data pointer in the parameter gp. If other operations are triggered when the register is read, the user needs to add relevant code to implement it according to the actual needs. For example, for a read clear register, when the register is read by software, in addition to sending out the data of the register, it also needs to be cleared, that is, after reading, the value of the register is set to zero. Therefore, it is necessary to add the operation of clearing the register after the call of the read function of the register class in the above default read callback function.

[0121] The write callback function is called when the register is written by software, and is implemented as follows:

[0122] ret_t mymod::EX1_REG_WriteCB(tlm_generic_payload& gp) {

[0123] / / Custom pre access functionality here

[0124] ret_t status = EX1_REG.write(gp);

[0125] / / Custom post access functionality here

[0126] return status;

[0127] }

[0128] The default write callback function calls the write function of the register class, which writes the specified data into the software writable bits of the register. The data to be written is pointed to by the data pointer in the parameter gp. If other operations are triggered when the register is written, the user needs to add relevant code implementation according to actual needs. For example, for some control registers, when the register is written by software, in addition to writing the specified data into the register, other operations such as starting the counter will also be triggered. Therefore, the user needs to add the relevant operation of starting the counter after the call of the write function of the register class in the default write callback function.

[0129] For a hardware module, each register is a part of its function, and whether to modify the default read and write callback functions and how to modify them need to be determined according to the actual function of the register.

[0130] ③Implementation of module reset response function

[0131] The hardware module needs to be able to be reset, and when the reset signal comes, the hardware module returns to the initial state or the pre-defined reset state. The automatically generated module model defines a reset response function, and the user needs to implement this function according to the actual reset state of the module. The generated code framework is as follows:

[0132] void mymod::mymod_reset(void)

[0133] {

[0134] }

[0135] After the above work is completed, the model development of the module is completed, and the module provides a target socket variable m_target_socket conforming to a standard TLM2.0 interface, which is used for binding with an initiator socket of an initiator module, so as to realize TLM-based communication.

[0136] 4. Test platform implementation

[0137] After the functional model is implemented, a test platform needs to be built to test the function. The application automatically generates a test platform, which is located in <module>Under / source / sc / tb directory.

[0138] The test platform file is described as follows:

[0139]

[0140] The test platform framework, related component connection, basic test case and test case example are all automatically generated. If there is no special requirement, the user only needs to add the corresponding test case according to the actual module function, imitating the test case example. After completion, the user can run the test case in the test platform, and the test result will be automatically recorded in the test report. <module>By executing the corresponding commands in the / sc_sim directory to compile and simulate, the functionality of the module can be tested.

[0141] A second aspect of this invention provides a virtual model generation system based on SystemC. Figure 2 The diagram shown is a schematic representation of an embodiment of the SystemC-based virtual model generation system provided by the present invention. Figure 2 As shown, a SystemC-based virtual model generation system includes: a model directory structure generation module 10, configured to receive the name of a hardware module input by a user, and execute a first script based on the hardware module to generate a model directory structure; a register model generation module 20, configured to receive a register description file input by a user, and parse the register description file through a second script to generate a SystemC-based register model in the model directory structure; a source code file generation module 30, configured to execute a third script to generate source code files of the virtual model of the hardware module in the model directory structure based on the register model; and a virtual model generation module 40, configured to receive custom function information for the hardware module added by the user to the source code file to obtain a virtual model that implements the custom function.

[0142] A third aspect of the present invention also provides a computer-readable storage medium. Figure 3 A schematic diagram of a computer-readable storage medium implementing a SystemC-based virtual model generation method according to an embodiment of the present invention is shown. Figure 3 As shown, the computer-readable storage medium 3 stores computer program instructions 31. When executed by a processor, the computer program instructions 31 implement the method of any of the above embodiments.

[0143] It should be understood that, where there is no conflict, all the embodiments, features and advantages described above for the SystemC-based virtual model generation method according to the present invention are equally applicable to the SystemC-based virtual model generation system and storage medium according to the present invention.

[0144] A fourth aspect of the present invention also provides a computer device, including as follows: Figure 4 The memory 402 and processor 401 shown are provided. The memory 402 stores a computer program that, when executed by the processor 401, implements the method of any of the above embodiments.

[0145] like Figure 4 The diagram shown is a hardware structure schematic of an embodiment of a computer device for executing a SystemC-based virtual model generation method provided by the present invention. Figure 4 The illustrated computer device is an example, in which a processor 401 and a memory 402 are included, and can further include an input device 403 and an output device 404. The processor 401, the memory 402, the input device 403 and the output device 404 can be connected by a bus or other means, Figure 4 The input device 403 can receive input digital or character information, and generate key signal input related to user settings and function control of the SystemC-based virtual model generation system. The output device 404 can include a display device such as a display screen.

[0146] The memory 402, as a non-volatile computer readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions / modules corresponding to the SystemC-based virtual model generation method in the embodiments of the present application. The memory 402 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required by a function; the data storage area can store data created by use of the SystemC-based virtual model generation method, etc. In addition, the memory 402 can include a high-speed random access memory, and can further include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 402 can optionally include a memory disposed remotely with respect to the processor 401, which can be connected to the local module through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0147] The processor 401 executes various function applications and data processing of the server by running the non-volatile software programs, instructions and modules stored in the memory 402, i.e. implements the SystemC-based virtual model generation method of the above-mentioned method embodiments.

[0148] Finally, it is noted that the computer-readable storage media of the present application, for example, the memory, can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example, and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM), which can act as external cache memory. By way of example, and not limitation, RAM is available in many forms such as Static RAM (DRAM), Dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). The memory of the disclosed aspects is intended to include, without being limited to including, these and any other suitable types of memory.

[0149] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application embodiments disclosure.

[0150] The foregoing is a summary of the exemplary embodiments disclosed herein, but it should be noted that various changes and modifications could be made therein without departing from the scope of the present application embodiments disclosure as defined by the appended claims. The functional, step, and / or action elements of the method claims, as described herein, need not be performed in any particular order. Furthermore, although elements of the present application embodiments disclosure can be described or claimed in individual forms, other embodiments can include a combination of those elements absent otherwise specifically restricted by the claims.

[0151] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. It is to be further understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated items, including items in the alternative. The use of "adapted to" or "configured to" herein is meant as antecedents to the term "means for" in connection with the functions described for structures, devices, and materials associated with the embodiments of the application.

[0152] Those skilled in the art should understand that the above discussion of any embodiment is only exemplary, and is not intended to mean that the scope of the embodiments disclosed by the present application (including claims) is limited to these examples; under the idea of the embodiments of the present application, the above embodiments or technical features in different embodiments can also be combined, and there are many other changes of different aspects of the embodiments of the present application as above. In order to be brief, they are not provided in details. Therefore, any omission, modification, equivalent replacement, improvement, etc. made in the spirit and principle of the embodiments of the present application shall be included in the protection scope of the embodiments of the present application.< / module> < / module> < / module>

Claims

1. A SystemC-based virtual model generation method, characterized by, The method comprises the following steps: receiving a name of a hardware module input by a user, and executing a first script based on the hardware module to generate a model directory structure, wherein the model directory structure comprises directory files for saving model source code, test platform code, a model source code directory, a model test platform code directory, a register model code directory, and a compilation and simulation directory; receiving a register description file input by a user, and parsing the register description file through a second script to generate a SystemC-based register model in the model directory structure, wherein the register model corresponds to generated files including definition-type files and operation-type files, the definition-type files include a register model class and related constant parameters, the operation-type files include read operation functions and write operation functions for domains of a register, the operation-type files further include a value acquisition function, the value acquisition function is used to acquire original values of all bits of the register, the read operation functions are used to perform read operations on values of bits belonging to a specified domain in the original values, and the write operation functions are used to perform write operations on the values of the bits belonging to the specified domain in the original values; executing a third script to generate a source code file of a virtual model of the hardware module in the model directory structure based on the register model; receiving custom function information added by the user on the source code file for the hardware module to obtain the virtual model implementing the custom function; wherein the source code file has read callback functions and write callback functions, the read callback functions are called based on a read register instruction in response to the application software issuing the read register instruction through an interface, and the write callback functions are called based on a write register instruction in response to the application software issuing the write register instruction through the interface.

2. A SystemC-based virtual model generation system, characterized by, The method comprises the following steps: a model directory structure generation module configured to receive a name of a hardware module input by a user, and execute a first script based on the hardware module to generate a model directory structure, wherein the model directory structure comprises directory files for saving model source code, test platform code, a model source code directory, a model test platform code directory, a register model code directory, and a compilation and simulation directory; a register model generation module configured to receive a register description file input by a user, and parse the register description file through a second script to generate a SystemC-based register model in the model directory structure, wherein the register model corresponds to generated files including definition-type files and operation-type files, the definition-type files include a register model class and related constant parameters, the operation-type files include read operation functions and write operation functions for domains of a register, the operation-type files further include a value acquisition function, the value acquisition function is used to acquire original values of all bits of the register, the read operation functions are used to perform read operations on values of bits belonging to a specified domain in the original values, and the write operation functions are used to perform write operations on the values of the bits belonging to the specified domain in the original values; a source code file generation module configured to execute a third script to generate a source code file of a virtual model of the hardware module in the model directory structure based on the register model; and a virtual model generation module configured to receive custom function information added by a user for the hardware module on the source code file to obtain the virtual model implementing the custom function; wherein the source code file has a read callback function and a write callback function; in response to an application software issuing a read register instruction through an interface, the read callback function is called based on the read register instruction; in response to the application software issuing a write register instruction through the interface, the write callback function is called based on the write register instruction.

3. A computer-readable storage medium, characterized in that, The memory stores computer program instructions, and the computer program instructions are executed by the processor to implement the method of claim 1.

4. A computer device comprising a memory and a processor, characterized in that, The memory stores computer program instructions, and the computer program instructions are executed by the processor to implement the method of claim 1.

Images