DPI-C interface-based reference model packaging method and packaging system
By using the data conversion module to uniformly map parameter types in the reference model packaging method of the DPI-C interface, the types inconsistency and compatibility problems in the DPI-C interface packaging are solved, the packaging efficiency and code readability are improved, and the seamless cross-platform adaptation and team collaboration are achieved.
Patent Information
- Application Number
- CN202510938036.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-08
- Publication Date
- 2025-08-05
AI Technical Summary
During the encapsulation process of DPI-C interface, there are types inconsistencies, operation differences, resource conflicts, and compatibility issues, resulting in cross-platform migration difficulties, poor code readability and maintenance, team collaboration difficulties, complex debugging and performance problems.
The general packaging method of reference model based on DPI-C interface is adopted, and the char2others and others2char data conversion modules are encapsulated on the C side, and the others2byte and byte2others data conversion modules are used on the SV side to realize unified mapping of parameter types and standardized interface design.
It significantly reduces the risk of parameter type obfuscation when cross-language calls, improves packaging efficiency and code readability, realizes seamless cross-platform adaptation and team collaboration, and reduces debugging complexity.
Smart Images

Figure CN120429221A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of computer data processing, and in particular to a universal encapsulation method and encapsulation system for a reference model based on a DPI-C interface. Background Art
[0002] The increasing complexity of digital systems is posing greater challenges for hardware-software co-design and verification. Verification of complex IP (Intellectual Property Core) functionality is shifting from hardware-driven to software-driven, and the use of high-level programming languages like C to write higher-level abstraction use cases is becoming commonplace.
[0003] The SystemVerilog Direct Programming Interface for C (DPI-C) is an interface for interoperability between SystemVerilog and C / C++. Within the UVM (Universal Verification Methodology) verification framework, SystemVerilog can call reference models implemented in C and compare them with DUT (Device Under Test) results, providing strong support for automated verification and coverage. Most current SystemVerilog and C developers lack a deep understanding of each other's domains. When encapsulating reference models, they simply follow grammatical rules for mapping. This results in a wide variety of interface call types and is prone to errors.
[0004] Each variable passed through the DPI-C interface has two matching definitions, one in SystemVerilog and one in C. The specific correspondence is shown in the following table: When directly using the parameter types provided by native DPI-C for encapsulation, due to type inconsistencies, in addition to inconsistent interface parameter types, there are also differences in operation methods. This brings the following problems to C model users (SystemVerilog developers) and C model designers (C developers): Compatibility issues: Different DPI-C encapsulations may behave differently in different operating systems and compiler environments, making cross-platform porting difficult.
[0005] Toolchain dependency: Some packages may depend on specific toolchains or libraries, which limits the flexibility and versatility of use.
[0006] Reduced code readability: Multiple encapsulation methods may lead to inconsistent code styles, reducing code readability and maintainability.
[0007] Inconsistent documentation: Different packaging methods may have their own documentation and usage guides, and the lack of unified standards increases the difficulty of learning and use.
[0008] Performance issues: Different encapsulation methods may generate different overheads when calling C / C++ functions, affecting overall performance.
[0009] Memory management: Inconsistent memory management strategies may lead to memory leaks or performance degradation.
[0010] Increased debugging difficulty: Multiple packaging methods may result in inconsistent error messages, making it difficult to accurately locate and debug the problem. Some packaging methods may not be supported by mainstream debugging tools, increasing debugging complexity.
[0011] Difficulty in team collaboration: Different packaging methods may require different expertise, which increases the difficulty of knowledge sharing and collaboration among team members.
[0012] Code reuse: The lack of a unified packaging standard leads to low code reuse rates and increased duplication of work.
[0013] like Figure 1 As shown in the figure, in the current UVM verification field, only scattered parameter type mapping is used, without providing a systematic and comprehensive unified mapping conversion solution. Therefore, how to unify parameter types during encapsulation and increase work efficiency is an urgent problem to be solved. Summary of the Invention
[0014] In view of the above problems, the present invention proposes a universal encapsulation method and encapsulation system for a reference model based on a DPI-C interface.
[0015] To achieve the purpose of the present invention, a general encapsulation method for a reference model based on a DPI-C interface is provided, comprising the following steps: S1: On the C side, encapsulation operations are performed based on the first reference model, the char2others data conversion module, and the others2char data conversion module to obtain a second reference model. At this time, the interface parameter type of the second reference model is a char pointer plus an int. S2: Based on the DPI-C interface mapping rules, replace the char pointer in the second reference model interface with a byte array, then import the modified second reference model into the context of the SV side to obtain a DPI-C interface model that can be directly used by the SV side; S3: On the SV side, encapsulation operations are performed based on the DPI-C interface model, the others2byte data conversion module, and the byte2others data conversion module to obtain a final universal reference model.
[0016] The present invention also provides a reference model packaging system based on the DPI-C interface, comprising: an SV side, a C side and a DPI-C interface; The SV side calls the C side through the DPI-C interface; The C side includes: a reference model, a char2others data conversion module and an others2char data conversion module; The SV side includes: a mapping module, an others2byte data conversion module and a byte2others data conversion module; The reference model is used to: simulate the DTU of the component under test to generate a reference result; The char2others data conversion module is used to: restore the input data on the C side from the combination of char pointer and int to the original type; The others2char data conversion module is used to convert the output data of the C side from the original type into a combination of a char pointer and an int; The mapping module is used to: map the data input from the C side to the SV side from a char pointer plus an int to a byte array and an int, and map the data output from the SV side to the C side from a byte array and an int to a char pointer plus an int based on the DPI-C interface mapping rule; The others2byte data conversion module is used to convert the input data of the SV side from the original data type to the standard byte array type and integer type, that is, byte array and int; The byte2others data conversion module is used to restore the standard byte array type and integer type obtained after model calculation to the required original data type.
[0017] Furthermore, the reference model is a C model.
[0018] The present invention also provides an electronic device comprising a memory, a processor and a computer program; The computer program is stored in the memory and can be run on the processor; The processor implements the reference model encapsulation method based on the DPI-C interface when running the computer program.
[0019] Compared with the prior art, the present invention has the following beneficial technical effects: Ease of Use: By standardizing parameter passing within the DPI-C interface, the risk of parameter type confusion during cross-language calls is significantly reduced. This invention employs a layered encapsulation strategy, enabling C and SystemVerilog developers to focus on developing the core logic in their respective domains without requiring a deep understanding of the underlying features of the other language. This separation of duties not only reduces the complexity of cross-language debugging but also doubles encapsulation efficiency, fully embodying the usability design principle of "learnability."
[0020] Compatibility: This invention seamlessly adapts to over 95% of common reference models through an abstract variable type mapping table (supporting 12 basic data types, including integers, structures, and dynamic arrays). Its core advantage lies in its standardized interface design, derived from advanced packaging technology. This ensures the stability of existing functionality while providing standardized access for the subsequent expansion of new variable types. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Figure 1 It is a comparison diagram of interface parameter types in the prior art; Figure 2 is a flow chart of a reference model encapsulation method based on a DPI-C interface according to an embodiment; Figure 3 is a module diagram of a reference model encapsulation system based on a DPI-C interface according to an embodiment; Figure 4 is a schematic diagram of interface parameter configuration of an embodiment; Figure 5 is a schematic diagram of a char2others data conversion module according to an embodiment; Figure 6 is a schematic diagram of an others2char data conversion module according to an embodiment; Figure 7 is a schematic diagram of an others2byte data conversion module according to an embodiment; Figure 8 is a schematic diagram of a byte2others data conversion module according to an embodiment. DETAILED DESCRIPTION
[0022] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.
[0023] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0024] refer to Figure 2 As shown, Figure 2 The following is a flow chart of a reference model encapsulation method based on a DPI-C interface according to an embodiment of the present invention. The reference model encapsulation method based on a DPI-C interface includes the following steps: S1: On the C side, encapsulation operations are performed based on the first reference model, the char2others data conversion module, and the others2char data conversion module to obtain a second reference model. At this time, the interface parameter type of the second reference model is a char pointer plus an int. S2: Based on the DPI-C interface mapping rules, replace the char pointer in the second reference model interface with a byte array, then import the modified second reference model into the context of the SV side to obtain a DPI-C interface model that can be directly used by the SV side; S3: On the SV side, encapsulation operations are performed based on the DPI-C interface model, the others2byte data conversion module, and the byte2others data conversion module to obtain a final universal reference model.
[0025] In one embodiment, Figure 3 As shown, a reference model packaging system based on the DPI-C interface includes: an SV side, a C side and a DPI-C interface; The SV side calls the C side through the DPI-C interface; The C side includes: a reference model, a char2others data conversion module and an others2char data conversion module; The SV side includes: a mapping module, an others2byte data conversion module and a byte2others data conversion module; The reference model is used to: simulate the DTU of the component under test to generate a reference result; The char2others data conversion module is used to: restore the input data on the C side from the combination of char pointer and int to the original type; The others2char data conversion module is used to convert the output data of the C side from the original type into a combination of a char pointer and an int; The mapping module is used to: map the data input from the C side to the SV side from a char pointer plus an int to a byte array and an int, and map the data output from the SV side to the C side from a byte array and an int to a char pointer plus an int based on the DPI-C interface mapping rule; The others2byte data conversion module is used to convert the input data of the SV side from the original data type to the standard byte array type and integer type, that is, byte array and int; The byte2others data conversion module is used to restore the standard byte array type and integer type obtained after model calculation to the required original data type.
[0026] In one embodiment, in the reference model packaging system based on the DPI-C interface, the reference model is the C model.
[0027] In one embodiment, there is also provided an electronic device comprising a memory, a processor and a computer program; The computer program is stored in the memory and can be run on the processor; When the processor runs the computer program, a reference model encapsulation method based on the DPI-C interface is implemented.
[0028] In one embodiment, within the UVM verification environment, the DPI-C interface is often used to call C models to build stimulus or reference models. Typically, a C reference model exists first, which is then encapsulated and called from the SV side (SystemVerilog) via the DPI-C interface. Both the SV side and the C side provide bidirectional mapping APIs for most type parameters to byte and char types, respectively, ensuring parameter type uniformity and data consistency during DPI-C interface calls.
[0029] In one embodiment, Figure 4As shown, when a reference model encapsulation system based on the DPI-C interface is running, the original data is input to the SV side, and the others2byte data conversion module converts the original data from the original type to a byte array and int; the mapping module maps the type of the original data from a byte array and int to a char pointer plus int based on the DPI-C interface mapping rule; the char2others data conversion module restores the type of the original data from a char pointer plus int to the original type; the DPI-C interface module calls the reference model and imports the original data restored to the original type into the reference model, the reference model runs and outputs the reference result data, at which time the type of the reference result data is the original type; the others2char data conversion module converts the type of the reference result data from the original type to a char pointer plus int; the mapping module maps the reference result data type at this time from a char pointer plus int to a byte array and int based on the DPI-C interface mapping rule, and sends it to the SV side through the DPI-C interface module; the byte2others data conversion module restores the reference result data of the byte array and int type to the reference result data of the original type for subsequent calling of the ref_model component in the next stage.
[0030] In one embodiment, in C syntax, unsigned char, unsigned int, struct, char[] and other types are often used as calculation buffer space. In order to adapt to the existing C model, it is necessary to convert the char pointer and int type variable passed through DPI-C into the types required by the existing C model, such as Figure 5 , Figure 6 shown.
[0031] In one embodiment, a C reference model of an original ZUC algorithm (Zu Chongzhi algorithm) is known as follows: void zuc(unsigned char key
[16] , unsigned char iv
[16] , unsigned intlen, unsigned int *ls); By observing the reference model, we can see that we need to call the char2others data conversion module on the C side to restore the input char pointer and variable to the type required by the original reference model, and call the others2char data conversion module to convert the calculation results into char pointers and int variables, as shown in the following table: In one embodiment, the original C model of a known RSA public-private key pair generation function is as follows: int rsa_generate_keys(rsa_pk_t *pk, rsa_sk_t *sk, unsigned int key_bits); Two of the structure types are defined as follows: typedef struct { unsigned int bits; unsigned char modulus[RSA_MAX_MODULUS_LEN]; unsigned char exponent[RSA_MAX_MODULUS_LEN]; } rsa_pk_t; typedef struct { unsigned int bits; unsigned char modulus[RSA_MAX_MODULUS_LEN]; unsigned char public_exponet[RSA_MAX_MODULUS_LEN]; unsigned char exponent[RSA_MAX_MODULUS_LEN]; unsigned char prime1[RSA_MAX_PRIME_LEN]; unsigned char prime2[RSA_MAX_PRIME_LEN]; unsigned char prime_exponent1[RSA_MAX_PRIME_LEN]; unsigned char prime_exponent2[RSA_MAX_PRIME_LEN]; unsigned char coefficient[RSA_MAX_PRIME_LEN]; } rsa_sk_t; Here, each element in rsa_pk_t and rsa_sk_t is an integer multiple of 4 bytes, so there is no need to perform byte-by-byte operations on them in the others2char module, and they can be forcibly converted to char* and int.
[0032] The C model declaration after repackaging is as follows: void soft_rsa_gen_key(int key_bits, char *pk, int *pklen, char *sk,int *sklen); The C-side structure type parameter mapping comparison table is as follows: In one embodiment, although sv supports conversion of real to C float, it has been found in practice that the decimal part will be lost when using gcc4.5.0 and gcc8.1.0. Therefore, according to the solution, float and double types can be converted to char* on the C side.
[0033] The original C model is a fast inverse square root algorithm (Carmack's algorithm) stated as follows: float Q_rsqrt(float number); It is repackaged as follows: void soft_q_rsqrt(char *number, int len, char *result); The C-side floating-point parameter mapping comparison table is as follows: In one embodiment, the variable types commonly used in DPI-C interface calls in SystemVerilog syntax include bit, reg, struct, string, etc. In order to unify the data types during DPI-C interface communication, a parameter mapping conversion API of various types is provided on the SV side to unify the parameter types into fixed-size byte arrays and int variables, such as Figure 7 , Figure 8 shown.
[0034] Generally speaking, the data transferred in a transaction is mainly of type bit[], byte[], and int, and string and real types are occasionally used.
[0035] Note: When passing, use a fixed byte array. If resources permit, the space requested should be larger than the maximum space that the user will use in subsequent use.
[0036] In one embodiment, during a ZUC algorithm verification process, it is known that the DPI-C interface encapsulation: import "DPI-C" function void soft_alg_zuc(input byte key
[16] , input byte iv
[16] , input int len, output byte outdata
[4096] ); The transaction definition in its UVM verification code is as follows: ```systemverilog `ifndef MY_TRANSACTION__SV `define MY_TRANSACTION__SV class my_transaction extends uvm_sequence_item; rand bit [127:0] key; rand bit [127:0] iv; rand bit [31:0] zlen; rand bit [31:0] zout []; rand int idles; `uvm_object_utils_begin(my_transaction) `uvm_field_int(key, UVM_ALL_ON|UVM_NOCOMPARE) `uvm_field_int(iv, UVM_ALL_ON|UVM_NOCOMPARE) `uvm_field_int(zlen, UVM_ALL_ON|UVM_NOCOMPARE) `uvm_field_array_int(zout, UVM_ALL_ON) `uvm_field_int(idles, UVM_ALL_ON|UVM_NOCOMPARE) `uvm_object_utils_end function new(string name = "my_transaction"); super.new(name); endfunction endclass `endif ``` By observing the definition of the transaction class, we can see that the data on the SV side is mainly of bit type, which needs to be converted into byte type and then transmitted to the C model for calculation through DPI-C. The specific mapping relationship is as follows: In one embodiment, a known DPI-C interface for obtaining an RSA public-private key pair is as follows: import "DPI-C" function void soft_rsa_gen_key(input int key_bits,output byte pk
[1024] ,output int pk_len, output byte sk
[2048] , output int sk_len); Among them, key_bits is the length of the generated public key, rsa_pk_t is the public key related structure, and rsa_sk_t is the private key related structure.
[0037] typedef struct { int bits; byte modulus
[256] ; byte exponent
[256] ; } rsa_pk_t; typedef struct { int bits; byte modulus
[256] ; byte public_exponet
[256] ; byte exponent
[256] ; byte prime1
[128] ; byte prime2
[128] ; byte prime_exponent1
[128] ; byte prime_exponent2
[128] ; byte coefficient
[128] ; } rsa_sk_t; By observing the definition of the transaction class, we can see that a large byte array is obtained from the C side through the DPI-C interface, and then restored into multiple byte arrays in sequence. The specific mapping is as follows: In one embodiment, if the C reference model encapsulated by this solution is used and floating-point numbers are passed in the form of byte arrays, a function needs to be called on the sv side to convert between floating-point numbers and byte types: The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0038] It should be noted that the terms "first, second, and third" used in the embodiments of the present application are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It is understood that the terms "first, second, and third" may interchangeably represent a specific order or precedence, where permitted. It should be understood that the terms "first, second, and third" may interchangeably represent objects, where appropriate, such that the embodiments of the present application described herein may be implemented in an order other than that illustrated or described herein.
[0039] The terms "including," "having," and any variations thereof in the embodiments of the present application are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to the process, method, product, or device.
[0040] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.
Claims
1. A reference model encapsulation method based on DPI-C interface, characterized in that: The steps include: S1: On the C side, encapsulation operations are performed based on the first reference model, the char2others data conversion module, and the others2char data conversion module to obtain a second reference model. At this time, the interface parameter type of the second reference model is a char pointer plus an int. S2: Based on the DPI-C interface mapping rules, replace the char pointer in the second reference model interface with a byte array, then import the modified second reference model into the context of the SV side to obtain a DPI-C interface model that can be directly used by the SV side; S3: On the SV side, encapsulation operations are performed based on the DPI-C interface model, the others2byte data conversion module, and the byte2others data conversion module to obtain a final universal reference model.
2. A reference model packaging system based on DPI-C interface, characterized in that: include: SV side, C side and DPI-C interface; The SV side calls the C side through the DPI-C interface; The C side includes: a reference model, a char2others data conversion module and an others2char data conversion module; The SV side includes: a mapping module, an others2byte data conversion module and a byte2others data conversion module; The reference model is used to: simulate the DTU of the component under test to generate a reference result; The char2others data conversion module is used to: restore the input data on the C side from the combination of char pointer and int to the original type; The others2char data conversion module is used to convert the output data of the C side from the original type into a combination of a char pointer and an int; The mapping module is used to: map the data input from the C side to the SV side from a char pointer plus an int to a byte array and an int, and map the data output from the SV side to the C side from a byte array and an int to a char pointer plus an int based on the DPI-C interface mapping rule; The others2byte data conversion module is used to convert the input data of the SV side from the original data type to the standard byte array type and integer type, that is, byte array and int; The byte2others data conversion module is used to restore the standard byte array type and integer type obtained after model calculation to the required original data type.
3. A reference model packaging system based on DPI-C interface according to claim 2, characterized in that: The reference model is the C model.
4. An electronic device, characterized in that: including memory, processor and computer program; The computer program is stored in the memory and can be run on the processor; When the processor runs the computer program, the reference model encapsulation method based on the DPI-C interface as claimed in claim 1 is implemented.
Citation Information
Patent Citations
Data encapsulation method and data transmission method
CN114546372A
Computing interface based on embedded database and implementation method
CN119441335A
Method and device for transmitting big data between C language and Flutter
CN120123024A