A multi-stage delta blending implementation method of SV container type

Abstract

The application relates to the field of simulators, in particular to a multi-stage incremental hybrid implementation method of an SV container type. The method comprises the following steps: identifying a target type container appearing in an SV file; setting a corresponding unique signature for each member function of each target type container, and taking the unique signature as a wrapping function name of the corresponding member function; replacing a call to a member function of the target type container appearing in a non-container definition part of the SV file into a call to a corresponding wrapping function, and compiling the modified non-container definition part to obtain a first compilation result; judging whether the target type container is a compiled container or a container to be compiled; constructing a C file, and sending a first C++ file, the C file and a second C++ file to a C++ compiler for compilation to obtain a second compilation result; and linking the two compilation results and a compilation result of the compiled container to obtain a compilation result corresponding to the SV file. The application has high feasibility and high compilation efficiency.

Description

Technical Field

[0001] This invention relates to the field of simulators, and in particular to a method for implementing multi-level incremental hybridization of SV container types. Background Technology

[0002] The System Verilog (SV) language supports containers such as fixed-width arrays, dynamic arrays, queues, and associative arrays. These containers function similarly to C++ template containers, making C++ template containers an efficient implementation choice. However, the main System Verilog simulation program can bypass high-level languages ​​like C++ and directly use assembly language to enhance simulation capabilities. This raises the question of how to call member functions of C++ template classes from the assembly-based simulation program.

[0003] Calling member functions of a C++ template class from assembly requires using its mangled name, which is modified by the C++ compiler. Because System Verilog container types can be flexibly nested, and member functions are numerous and flexibly defined, the mangled names of C++ template class member functions are quite complex. Therefore, it is not feasible for the assembly simulation program to call C++ template class member functions by obtaining the mangled name.

[0004] Moreover, System Verilog can predefine countless specific container types, making it impossible to compile all container types in advance. Dynamically generating container type implementations during simulation compilation would reduce the simulator's compilation performance. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-level incremental hybrid implementation method for SV container types, in order to solve the problems that the above-mentioned assembly body simulation program has low feasibility in calling member functions of C++ template classes by obtaining the decorated name, and that the above-mentioned implementation of dynamically generating container types during simulation compilation will reduce the compilation performance of the simulator.

[0006] According to the present invention, a method for implementing multi-level incremental hybridization of SV container types is provided, the method comprising the following steps: S100: Parse the SV file input by the user and identify the target type container appearing in the SV file; the target type container is implemented in the simulator through a C++ template class container.

[0007] S200 sets a unique signature for each member function of each target type container and uses the unique signature as the wrapper function name of the corresponding member function.

[0008] S300 replaces calls to member functions of the target type container in the non-container definition section of the SV file with calls to the corresponding wrapper functions, and compiles the modified non-container definition section to obtain the first compilation result.

[0009] S400: Determine whether the target type container is a container pre-compiled by the simulator or a container previously compiled by the user. If so, mark the container as a compiled container; otherwise, mark the container as a container that needs to be compiled.

[0010] S500: Build a C file and send the first C++ file, the C file, and the second C++ file to the C++ compiler for compilation to obtain the second compilation result. The C file includes the definition of the wrapper function corresponding to the member function of each target type container. The definition of each wrapper function includes a statement that prevents the C++ compiler from name mangling the name of the wrapper function and a statement that calls the member function corresponding to the wrapper function. The first C++ file is the C++ implementation corresponding to the container definition part of the SV file. The second C++ file includes the member functions of the container to be compiled and their corresponding C++ implementations.

[0011] S600 links the first compilation result, the second compilation result, and the compilation result corresponding to the compiled container to obtain the compilation result corresponding to the SV file.

[0012] Compared with the prior art, the present invention has at least the following beneficial effects: This invention generates a uniquely signed wrapper function for each member function of a target type container, and uses a statement to prevent the C++ compiler from manipulating the name of the wrapper function. Furthermore, it replaces calls to member functions of the target type container in the non-container definition section of the SV file with calls to the corresponding wrapper functions. This allows the assembly simulation program to directly call the member functions of the C++ template class within the wrapper function by the wrapper function name, eliminating the need to obtain the manipulated names of the C++ template class member functions. This reduces the difficulty of implementation and demonstrates high feasibility.

[0013] Moreover, the present invention adopts the method of providing some container compilation results in advance (i.e., pre-compilation) and saving the compilation results of containers previously used by the user. During subsequent compilation, the compilation results of containers pre-provided by the simulator and the compilation results of previously used containers can be directly used. During the compilation process, only the container types that are not pre-compiled and added to the SV file compared to the user's historical files need to be compiled, which shortens the overall simulation compilation time and improves the compilation performance of the simulator. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 A flowchart illustrating a multi-level incremental mixing implementation method for SV container types provided in an embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] According to this embodiment, a multi-level incremental hybrid implementation method for SV container types is provided. The method includes the following steps, such as... Figure 1 As shown: S100: Parse the SV file input by the user and identify the target type container appearing in the SV file; the target type container is implemented in the simulator through a C++ template class container.

[0018] It should be understood that SV files are SystemVerilog files.

[0019] Those skilled in the art will understand that if an SV file contains containers, then the SV file will contain the definitions of those containers. By parsing the SV file, the definitions of the containers appearing in the SV file can be identified, and thus the containers appearing in the SV file can be known.

[0020] In this example, the target type container refers to the container implemented internally by a C++ template class container within the simulator. If the container appearing in the SV file is a container implemented by a C++ template class container in the simulator (the number may be one or more), such as a fixed-width array, a dynamic array, a queue, or an associative array, then S200 is executed. If no container appears in the SV file, or no container implemented by a C++ template class container appears, then S200 is not executed, and the SV file is directly compiled to obtain the corresponding compilation result.

[0021] It should be understood that among all containers supported by System Verilog, the simulator is aware of which containers are implemented internally using C++ template class containers and which are not. Containers implemented using C++ template class containers within System Verilog are implemented using underlying C++ member functions, and a container implemented using C++ template class containers in System Verilog may be implemented by combining multiple underlying C++ member functions.

[0022] S200 sets a unique signature for each member function of each target type container and uses the unique signature as the wrapper function name of the corresponding member function.

[0023] In this embodiment, the unique signature emphasizes uniqueness. As a specific implementation, SystemVerilog has an `int q[$]` (an `int` type queue) with a `push_back()` member function and a `push_front()` member function. The corresponding C++ implementation inside the simulator has an interface similar to the following: template<class T> class Queue { void PushBack(T&item); void PushBack(const T&item); void PushFront(T&item); void PushFront(const T&item); } The process of defining a unique signature in this embodiment is as follows: 1. Define the first part of the unique signature based on the container type: for example, q_int, where q indicates that the type itself is q, and int indicates that the type signature of the member of this type is int; 2. Define the second part of the unique signature based on the member function (different member functions will not repeat under the same container type). For example, the second part of the unique signature corresponding to void PushBack(T&item) is PushBack_NonConst. Therefore, the unique signature corresponding to void PushBack(T&item) is: q_int_PushBack_NonConst. Another example: the unique signature corresponding to void PushBack(const T&item) is q_int_PushBack_Const. Another example: the unique signature corresponding to void PushFront(T&item) is q_int_PushFront_Const. Another example: the unique signature corresponding to void PushFront(const T&item) is q_int_PushFront_NonConst.

[0024] In this embodiment, the wrapper function is the function name. For example, if the unique signature of void PushBack(T&item) is q_int_PushBack_NonConst, then q_int_PushBack_NonConst is the function wrapper name of void PushBack(T&item).

[0025] S300 replaces calls to member functions of the target type container in the non-container definition section of the SV file with calls to the corresponding wrapper functions, and compiles the modified non-container definition section to obtain the first compilation result.

[0026] In this embodiment, the non-container definition portion of the SV file does not need to be compiled by a C++ compiler and can directly generate machine code. The non-container definition portion of the SV file includes the content of the call to member functions in the defined container and other unrelated container definition and call content.

[0027] In this embodiment, S300 further includes: replacing calls to member functions of the target type container in the non-container definition section of the SV file with calls to the corresponding wrapper functions, and then adding the address of the target type container object to the call parameters. By adding the address of the target type container object to the call parameters, the wrapper function can call the correct member function. It should be understood that the modified non-container definition section refers to the non-container definition section after the above replacement and addition.

[0028] As a specific implementation, if a call to the member function PushBack(const T&item) of the target type container appears in the non-container definition part of the SV file, then the first compilation result will generate the symbol q_int_PushBack_NonConst, which can be called by the call q_int_PushBack_NonConst instruction.

[0029] S400: Determine whether the target type container is a container pre-compiled by the simulator or a container previously compiled by the user. If so, mark the container as a compiled container; otherwise, mark the container as a container that needs to be compiled.

[0030] As a specific implementation method, determining whether a target type container is a container pre-compiled by the simulator includes: S401, obtain the list of pre-compiled containers provided by the simulator; the compilation result corresponding to each container in the container list has been saved by the simulator.

[0031] As a specific implementation, containers in UVM (Universal Verification Methodology) can be used as containers in the container list, such as queue, arry, etc.; or containers used in open source projects can be used as containers in the container list, or containers in the container list can be determined according to user needs.

[0032] S402, if the target type container belongs to the container list, then the target type container is determined to be a container pre-compiled by the simulator.

[0033] As an optional implementation, it can be determined whether the target type container is a previously compiled container by comparing the container type signature (e.g., q_int). If the type signature of the target type container is the same as the type signature of a previously compiled container, then the target type container is determined to be a previously compiled container.

[0034] As an optional implementation, determining whether the target type container is a container that the user has previously compiled includes: S410: Obtain the hash value of the target container type based on the definition of the target type container in the SV file.

[0035] In one specific implementation, S410 includes: S411: Retrieve the member names and corresponding default values ​​from the definition of the target type container in the SV file, and concatenate them to obtain the description string of the target type container.

[0036] S412, perform a hash calculation on the description string of the target type container to obtain the hash value of the target container type.

[0037] Those skilled in the art are familiar with the process of hash calculation, and will not elaborate further here.

[0038] S420, Obtain the hash value of the specified container in the user history file according to the definition of the specified container in the user history file; the user history file is an SV file.

[0039] It should be understood that the SV file input by the user may be modified based on the user's historical file. In this case, the similarity between the SV file input by the user and the user's historical file is usually high, and the difference in the container types used by the two is small. In this embodiment, the compilation results corresponding to the containers appearing in the user's historical file are saved, which can realize the reuse of the compilation results and improve the compilation efficiency.

[0040] In this embodiment, the specified container is any container; the process of obtaining the hash value of the specified container is similar to the process of obtaining the hash value of the target container type described above, and will not be repeated here.

[0041] S430, if the hash value of the target container type is the same as the hash value of the container specified in the user's history file, then the target type container is determined to be a container compiled by the user in history.

[0042] It should be understood that if the hash value of the target container type is different from the hash value of the container specified in the user's history file, it means that the target container type is different from the specified container type. If the hash value of the target container is different from that of all containers in the user's history file, then it is determined that the target type container is not a container compiled by the user in the history.

[0043] S500: Build a C file and send the first C++ file, the C file, and the second C++ file to the C++ compiler for compilation to obtain the second compilation result. The C file includes the definition of the wrapper function corresponding to the member function of each target type container. The definition of each wrapper function includes a statement that prevents the C++ compiler from name mangling the name of the wrapper function and a statement that calls the member function corresponding to the wrapper function. The first C++ file is the C++ implementation corresponding to the container definition part of the SV file. The second C++ file includes the member functions of the container to be compiled and their corresponding C++ implementations.

[0044] It should be understood that a C file is a file written in the C language. An emulator can be used to generate the C++ implementation corresponding to the container definition section of an SV file, i.e., the first C++ file.

[0045] In this embodiment, after S500, the method further includes: saving the compilation results corresponding to the containers to be compiled in the second compilation results on a container-by-container basis. Furthermore, to avoid duplicate storage, only the compilation results of containers for which the simulator did not provide compilation results are saved in the compilation results corresponding to the containers to be compiled in the second compilation results.

[0046] As a specific implementation, the wrapper function q_int_PushBack_NonConst corresponding to the member function of a certain target type container included in the C file is defined as follows: extern "C" { void q_int_PushBack_NonConst(void* obj, int item) { ((Queue <int>*)obj)->PushBack(item); } } It should be understood that in the code above, ((Queue) <int>*)obj)->PushBack(item) means calling the member function PushBack.

[0047] S600 links the first compilation result, the second compilation result, and the compilation result corresponding to the compiled container to obtain the compilation result corresponding to the SV file.

[0048] This embodiment generates a uniquely signed wrapper function for each member function of the target type container, and uses a statement to prevent the C++ compiler from manipulating the name of the wrapper function. Furthermore, it replaces calls to member functions of the target type container in the non-container definition section of the SV file with calls to the corresponding wrapper functions. This allows the assembly simulation program to directly call the member functions of the C++ template class within the wrapper function by the wrapper function name, eliminating the need to obtain the manipulated names of the C++ template class member functions. This reduces the difficulty of implementation and makes the method highly feasible.

[0049] Moreover, this embodiment adopts the method of the simulator providing some of the container compilation results in advance (i.e., pre-compilation) and saving the compilation results of containers previously used by the user. During subsequent compilation, the pre-compiled container compilation results and the previously used container compilation results can be directly used. During the compilation process, only the container types that are not pre-compiled and added to the SV file compared to the user's historical files need to be compiled, which shortens the overall simulation compilation time and improves the compilation performance of the simulator.

[0050] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.< / int> < / int>

Claims

1. A method for implementing multi-level incremental hybridization of SV container type, characterized in that, The method includes the following steps: S100: Parse the SV file input by the user and identify the target type container appearing in the SV file; the target type container is implemented in the simulator through a C++ template class container; S200 sets a unique signature for each member function of each target type container and uses the unique signature as the wrapper function name of the corresponding member function; S300 replaces the calls to member functions of the target type container in the non-container definition part of the SV file with calls to the corresponding wrapper functions, and compiles the modified non-container definition part to obtain the first compilation result; S400: Determine whether the target type container is a container pre-compiled by the simulator or a container compiled by the user in the past. If so, mark the container as a compiled container; otherwise, mark the container as a container that needs to be compiled. S500: Build a C file and send the first C++ file, the C file, and the second C++ file to the C++ compiler for compilation, resulting in a second compilation result. The C file includes the definitions of the wrapper functions corresponding to the member functions of each target type container. The definition of each wrapper function includes statements that prevent the C++ compiler from name mangling the wrapper function name and statements that call the member function corresponding to the wrapper function. The first C++ file is the C++ implementation corresponding to the container definition part of the SV file, and the second C++ file includes the member functions of the container to be compiled and their corresponding C++ implementations. S600 links the first compilation result, the second compilation result, and the compilation result corresponding to the compiled container to obtain the compilation result corresponding to the SV file.

2. The multi-level incremental hybrid implementation method for SV container type according to claim 1, characterized in that, S300 also includes: replacing calls to member functions of the target type container that appear in the non-container definition part of the SV file with calls to the corresponding wrapper functions, and then adding the address of the target type container object to the call parameters.

3. The multi-level incremental hybrid implementation method for SV container type according to claim 1, characterized in that, Following S500, the method further includes: saving the compilation results corresponding to the container to be compiled in the second compilation result in units of containers.

4. The multi-level incremental hybrid implementation method for SV container type according to claim 1, characterized in that, The target type container is a fixed-width array, a dynamic array, a queue, or an associative array.

5. The multi-level incremental hybrid implementation method for SV container type according to claim 1, characterized in that, Determining whether a target type container is a container pre-compiled by the simulator includes: S401, retrieve the list of pre-compiled containers provided by the simulator; the compilation result for each container in the container list has been saved by the simulator. S402, if the target type container belongs to the container list, then the target type container is determined to be a container pre-compiled by the simulator.

6. The multi-level incremental hybrid implementation method for SV container type according to claim 1, characterized in that, The target type container is determined by comparing its type signature.

7. The multi-level incremental hybrid implementation method for SV container type according to claim 1, characterized in that, Determining whether a target type container is a container that has been previously compiled by the user includes: S410, Obtain the hash value of the target container type according to the definition of the target type container in the SV file; S420, Obtain the hash value of the specified container in the user history file according to the definition of the specified container in the user history file; the user history file is an SV file; S430, if the hash value of the target container type is the same as the hash value of the container specified in the user's history file, then the target type container is determined to be a container compiled by the user in history.

8. The multi-level incremental hybrid implementation method for SV container type according to claim 7, characterized in that, The S410 includes: S411, retrieve the member names and corresponding default values ​​from the definition of the target type container in the SV file, and concatenate them to obtain the description string of the target type container; S412, perform a hash calculation on the description string of the target type container to obtain the hash value of the target container type.

Images