UVM-based hardware security module verification method and apparatus, and electronic device

Abstract

The invention provides a hardware security module verification method and device based on a UVM and electronic equipment. After a verification instruction is received, an SV test case is started in a UVM environment, a target initialization function is called to initialize a target object, a C trigger function, a C initialization function and a DPI setting function are called, and a C test case is executed to obtain a verification result; in the process of executing the C test case, calling an algorithm function, if the to-be-verified hardware security module needs to be subjected to read-write processing, triggering a target interface read function and / or a target interface write function in the UVM environment through a target interface read packaging function and / or a target interface write packaging function in the C environment, and if the to-be-verified hardware security module needs to be subjected to read-write processing, executing the to-be-verified hardware security module. And executing an operation corresponding to the read-write processing on the to-be-verified hardware security module. In the mode, the data type mapping problem between the systemverilog language and the c language does not need to be considered in the UVM environment, so that the verification efficiency of the hardware security module can be improved.

Description

Technical Field

[0001] This invention relates to the field of hardware security module verification technology, and in particular to a hardware security module verification method, apparatus and electronic device based on UVM. Background Technology

[0002] The hardware security module includes hardware engines for various encryption algorithms, such as symmetric and hash algorithms, and implements multiple functions, including a secure boot mechanism, through the processor core. This involves verifying and checking the correctness of the encryption algorithm modules and the secure boot process. During verification, the UVM (Universal Verification Methodology) methodology is typically used to build the verification environment. For the verification of the algorithm module, the expected data of the reference model is generally compared with the actual data of the algorithm module. The reference model uses DPI (Direct Programming Interface) to import the C language algorithm model. During the import process, the data type mapping between SystemVerilog and C languages ​​needs to be considered. That is, data type conversion needs to be performed in the C environment or UVM environment before it can be used, which greatly reduces the verification efficiency of the hardware security module. Summary of the Invention

[0003] The purpose of this invention is to provide a hardware security module verification method, apparatus, and electronic device based on UVM, so as to improve the verification efficiency of hardware security modules.

[0004] This invention provides a hardware security module verification method based on UVM. A pre-built UVM environment is configured with SV test cases, a target initialization function, a target interface read function, and a target interface write function. A pre-built interface includes a target interface read wrapper function (wrapping the target interface read function) and a target interface write wrapper function (wrapping the target interface write function). A pre-built C environment is configured with a C trigger function, a C initialization function, a DPI setting function, C test cases, and an algorithm function. The hardware security module to be verified interacts with the UVM environment through the pre-built interface. The C environment and the UVM environment interact via DPI. The method further includes: upon receiving a verification command for the hardware security module to be verified, starting the SV test case in the UVM environment; and calling the target initialization function in the UVM environment. The process involves several steps: first, initializing the target object; then, calling a C trigger function in the UVM environment to invoke the C initialization function and DPI setting function, and executing C test cases to obtain the verification results corresponding to the hardware security module to be verified; the C trigger function in the UVM environment is derived from the C environment via DPI; during the execution of the C test cases, the algorithm function is called. If read / write processing of the hardware security module to be verified is required, the target interface read wrapper function and / or target interface write wrapper function in the C environment are used to trigger the target interface read function and / or target interface write function in the UVM environment to perform the corresponding read / write operations on the hardware security module to be verified; the target interface read wrapper function and target interface write wrapper function in the C environment are derived from a preset interface via DPI.

[0005] Furthermore, the C test cases and algorithm functions in the C environment are obtained as follows: acquire the C test cases and algorithm functions; compile the C test cases and algorithm functions into dynamic library files; and load the dynamic library files in the C environment to use the C test cases and algorithm functions in the C environment.

[0006] Furthermore, the hardware security module to be verified includes: a control interface and a data interface; the target interface read functions include: a control interface read function corresponding to the control interface and a data interface read function corresponding to the data interface; the target interface write functions include: a control interface write function corresponding to the control interface and a data interface write function corresponding to the data interface.

[0007] Furthermore, the target initialization function includes: a UVM initialization function and a hardware initialization function; the steps of calling the target initialization function in the UVM environment to complete the initialization of the target object include: calling the UVM initialization function in the UVM environment to complete the initialization of the target component; and calling the hardware initialization function in the UVM environment to complete the initialization of the hardware corresponding to the hardware security module to be verified.

[0008] Furthermore, the UVM environment is also configured with a UVM termination function; the method also includes: during the execution of C test cases, the UVM termination function is called to record error information during the execution of C test cases; the finish function is called through the UVM termination function to end the verification process of the hardware security module to be verified.

[0009] Furthermore, the hardware security module to be verified also includes a processor core and an encryption algorithm.

[0010] This invention provides a hardware security module verification device based on UVM. The pre-built UVM environment is configured with SV test cases, target initialization functions, target interface read functions, and target interface write functions. A preset interface is configured with a target interface read wrapper function (wrapping the target interface read function) and a target interface write wrapper function (wrapping the target interface write function). A pre-built C environment is configured with C trigger functions, C initialization functions, DPI setting functions, C test cases, and algorithm functions. The hardware security module to be verified interacts with the UVM environment through the preset interface. The C environment interacts with the UVM environment through DPI. The device also includes: The startup module is used to start SV test cases in the UVM environment when a verification instruction for the hardware security module to be verified is received. The initialization module is used to call the target initialization function in the UVM environment to initialize the target object; The execution module is used to call C trigger functions in the UVM environment to invoke C initialization functions and DPI setting functions, and execute C test cases to obtain the verification results corresponding to the hardware security module to be verified; wherein, the C trigger functions in the UVM environment are derived from the C environment through DPI; During the execution of C test cases, the processing module calls algorithm functions. If read / write processing of the hardware security module to be verified is required, it triggers the target interface read function and / or target interface write function in the UVM environment through the target interface read wrapper function and / or target interface write function in the C environment to perform the corresponding read / write operations on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from the preset interface through DPI.

[0011] Furthermore, the C test cases and algorithm functions in the C environment are obtained as follows: acquire the C test cases and algorithm functions; compile the C test cases and algorithm functions into dynamic library files; and load the dynamic library files in the C environment to use the C test cases and algorithm functions in the C environment.

[0012] The present invention provides an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the UVM-based hardware security module verification method described above.

[0013] The present invention provides a machine-readable storage medium, characterized in that the machine-readable storage medium stores machine-executable instructions, which, when called and executed by a processor, cause the processor to implement any of the above-mentioned UVM-based hardware security module verification methods.

[0014] The present invention provides a hardware security module verification method, apparatus, and electronic device based on UVM. Upon receiving a verification instruction for a hardware security module to be verified, the method initiates SV test cases in the UVM environment; calls a target initialization function in the UVM environment to initialize the target object; calls a C trigger function in the UVM environment to invoke the C initialization function and DPI setting function, and executes the C test cases to obtain the verification result corresponding to the hardware security module to be verified. The C trigger function in the UVM environment is derived from the C environment via DPI. During the execution of the C test cases, an algorithm function is called. If read / write processing of the hardware security module to be verified is required, the target interface read wrapper function and / or target interface write wrapper function in the C environment are used to trigger the target interface read function and / or target interface write function in the UVM environment to perform the corresponding read / write operations on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from a preset interface via DPI. In this method, the data type mapping between SystemVerilog and C languages ​​does not need to be considered in the UVM environment, thereby improving the verification efficiency of the hardware security module. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of a UVM environment in the prior art; Figure 2 This is a schematic diagram of a data type mapping table in the prior art; Figure 3 A flowchart illustrating a hardware security module verification method based on UVM, provided for an embodiment of the present invention; Figure 4 A schematic diagram of an environment architecture provided for an embodiment of the present invention; Figure 5 A schematic diagram of the operation process provided in an embodiment of the present invention; Figure 6 A schematic diagram of a hardware security module verification device based on UVM provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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.

[0018] In existing technologies, the verification of algorithm modules typically involves comparing the expected data of a reference model with the actual data of the algorithm module. The reference model uses DPI (Direct Programming Interface) to import the C language algorithm model. During the import process, the data type mapping between SystemVerilog and C needs to be considered: the mapping of input parameters and the mapping of output parameters. For example... Figure 1 A schematic diagram of a UVM environment is shown, and Figure 2The data type mapping table shown highlights the significant challenge of using DPI, particularly in the data type mapping between SystemVerilog and C, especially when sharing structures and classes. Taking the SM2 encryption and decryption process as an example: for input parameters, the plaintext generated by UVM excitation is of type bit[N:0] (mapped to `const svBitVecVal*` in C), while the CModel encryption function requires a plaintext char array (corresponding to `string` in SV). According to the recommended mapping table, these two data types do not directly match and require data type conversion in either the C or UVM environment before use. For output parameters: CModel outputs ciphertext as an unsigned char array (corresponding to `logic` in SV), which may actually need to be converted to `svOpenArrayHandle` to correctly pass the ciphertext to the SV environment. Similarly, in the RSA signature process, the signature function involves an EVP_MD structure as input parameters. This composite data structure lacks a corresponding mapping type, making calls in SV cumbersome. Overall, the related technologies involve numerous algorithm functions, making reference model debugging difficult. Furthermore, the DUT (device under test) has an initialization and startup process, resulting in lengthy simulation times and reduced verification efficiency. Therefore, this invention provides a hardware security module verification method, apparatus, and electronic device based on UVM. This technology can be applied to applications requiring simulation verification of hardware security modules.

[0019] To facilitate understanding of this embodiment, a hardware security module verification method based on UVM disclosed in this embodiment of the invention will first be introduced. The pre-built UVM environment is configured with SV test cases, target initialization functions, target interface read functions, and target interface write functions. The SV test cases are the top-level controller and test scenario definer of the entire UVM environment, primarily responsible for organizing the entire verification process. Based on the interface types existing in the hardware security module to be verified, corresponding target interface read functions and target interface write functions can be configured in the UVM environment. The preset interface is configured with a target interface read wrapper function that wraps the target interface read function, and a target interface write wrapper function that wraps the target interface write function. Since the environment of the preset interface is different from the UVM environment, the target interface read function and target interface write function in the UVM environment can be wrapped separately to obtain the corresponding target interface read wrapper function and target interface write wrapper function, which are then stored in the preset interface. Specific wrapping methods can be found in related technologies and will not be elaborated here. The pre-built C environment is configured with a C trigger function, a C initialization function, and a DPI setting function (DPI: Direct...). The Programming Interface (CUI) consists of C test cases and algorithm functions. C trigger functions are defined in the C environment and can be directly called by SV test cases in the UVM environment. C initialization functions are primarily used to complete the setup of the C environment at the start of simulation verification. The DPI setting function establishes communication between the UVM and C environments. C test cases can be understood as specific scenarios for simulating and verifying the hardware security module under test, set using C functions. Algorithm functions typically correspond to the hardware encryption engine function of the hardware security module under test. The hardware security module under test interacts with the UVM environment through a preset interface. The C environment and UVM environment interact via DPI. Figure 3 As shown, the method includes the following steps: Step S302: Upon receiving a verification instruction for the hardware security module to be verified, start the SV test case in the UVM environment. In actual implementation, upon receiving a verification instruction for the hardware security module to be verified, the system enters simulation mode, at which point SV test cases are first started in the UVM environment.

[0020] Step S304: In the UVM environment, call the target initialization function to complete the initialization of the target object; Initialization parameters are usually pre-configured, and the relevant components and hardware can be initialized by calling the target initialization function.

[0021] Step S306: In the UVM environment, call the C trigger function to call the C initialization function and the DPI setting function, and execute the C test case to obtain the verification result corresponding to the hardware security module to be verified; wherein, the C trigger function in the UVM environment is derived from the C environment through DPI; In actual implementation, the call content corresponding to the C trigger function in the C environment can be set. The C trigger function in the C environment can be imported into the preset interface through DPI. The UVM environment can then obtain the C trigger function from the preset interface. By calling the C trigger function, the C initialization function can be further called. The C initialization function will call the DPI setting function and the C test case, and execute the C test case to obtain the verification result corresponding to the hardware security module to be verified.

[0022] Step S308: During the execution of the C test case, the algorithm function is called. If read and write processing of the hardware security module to be verified is required, the target interface read wrapper function and / or target interface write wrapper function in the C environment are used to trigger the target interface read function and / or target interface write function in the UVM environment to perform the corresponding read and write processing operation on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from the preset interface through DPI.

[0023] In practical implementation, the target interface read wrapper function and target interface write wrapper function in the preset interface can be imported into the C environment through DPI. During the execution of C test cases, the corresponding algorithm functions can be called as needed. If read processing is required for the hardware security module to be verified, the target interface read wrapper function in the C environment can be used to trigger the target interface read function in the UVM environment to read the corresponding data from the hardware security module to be verified. If write processing is required for the hardware security module to be verified, the target interface write wrapper function in the C environment can be used to trigger the target interface write function in the UVM environment to write the corresponding data to the hardware security module to be verified.

[0024] The aforementioned UVM-based hardware security module verification method, upon receiving a verification instruction for the hardware security module to be verified, initiates SV test cases in the UVM environment; calls the target initialization function in the UVM environment to initialize the target object; calls the C trigger function in the UVM environment to invoke the C initialization function and DPI setting function, and executes the C test cases to obtain the verification result corresponding to the hardware security module to be verified; wherein, the C trigger function in the UVM environment is imported from the C environment via DPI; during the execution of the C test cases, the algorithm function is called, and if read / write processing of the hardware security module to be verified is required, the target interface read wrapper function and / or target interface write wrapper function in the C environment are used to trigger the target interface read function and / or target interface write function in the UVM environment to perform the corresponding read / write operations on the hardware security module to be verified; wherein, the target interface read wrapper function and target interface write wrapper function in the C environment are exported from preset interfaces via DPI. In this method, the data type mapping problem between SystemVerilog and C languages ​​does not need to be considered in the UVM environment, thereby improving the verification efficiency of the hardware security module.

[0025] This invention also provides another method for verifying hardware security modules based on UVM. This method is implemented based on the method described in the above embodiments. In this method, the target initialization function includes a UVM initialization function and a hardware initialization function; a UVM termination function is also configured in the UVM environment; the hardware security module to be verified also includes a processor core and an encryption algorithm. The processor core can be used to perform cryptographic operations such as encryption and decryption; the hardware security module to be verified can support multiple encryption algorithms, such as RSA (an asymmetric encryption algorithm), elliptic curve cryptography, etc. The method includes the following steps: Step 1: Upon receiving the verification instruction for the hardware security module to be verified, start the SV test case in the UVM environment. Step 2: In the UVM environment, call the UVM initialization function to complete the initialization of the target component; In this embodiment, the UVM initialization function can be used to instantiate UVM components such as env and cfg. The specific initialization process can be found in relevant technologies and will not be described in detail here.

[0026] Step 3: In the UVM environment, call the hardware initialization function to initialize the hardware corresponding to the security module to be verified.

[0027] In this embodiment, the hardware initialization function can be used to configure specific configuration signals, etc., onto the hardware interface corresponding to the hardware security module to be verified, so that the hardware corresponding to the hardware security module to be verified is in a known and determined initial state; the hardware initialization function can also initialize memory, wait for the ready signal of the hardware security module, etc.

[0028] Step 4: In the UVM environment, call the C trigger function to invoke the C initialization function and DPI setting function, and execute the C test cases to obtain the verification results corresponding to the hardware security module to be verified; wherein, the C trigger function in the UVM environment is derived from the C environment through DPI; C test cases and algorithm functions in the C environment are obtained through the following steps A and B: Step A: Obtain C test cases and algorithm functions; Step B involves compiling the C test cases and algorithm functions into dynamic library files, and then loading these dynamic library files into the C environment to use the C test cases and algorithm functions within the C environment.

[0029] The aforementioned dynamic library file can be a .so dynamic library file; that is, in this embodiment, the C environment can interact with C test cases and algorithm functions in the algorithm model (i.e., cmodel) through the .so dynamic library file. This is equivalent to standardizing and unifying the C test cases and algorithm functions in the algorithm model through the .so dynamic library file. Therefore, this embodiment can support algorithm models written in multiple different languages.

[0030] Step 5: During the execution of C test cases, the algorithm function is called. If read and write processing of the hardware security module to be verified is required, the target interface read wrapper function and / or target interface write wrapper function in the C environment are used to trigger the target interface read function and / or target interface write function in the UVM environment to perform the corresponding read and write operations on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from the preset interface through DPI.

[0031] The hardware security module to be verified includes: a control interface and a data interface; the target interface read functions include: a control interface read function corresponding to the control interface and a data interface read function corresponding to the data interface; the target interface write functions include: a control interface write function corresponding to the control interface and a data interface write function corresponding to the data interface.

[0032] In this embodiment, when configuring the UVM environment, corresponding read and write functions can be configured based on the characteristics of the hardware security module to be verified. Specifically, when the hardware security module to be verified has control and data interfaces, control interface read, control interface write, data interface read, and data interface write functions can be constructed in the UVM environment sequencer to drive the control and data interfaces of the hardware security module to be verified. For example, assuming the control interface supports the AHB (Advanced High-performance Bus) protocol, the control interface write function will operate on the received write signal and then transmit the write signal to the control interface of the hardware security module to be verified according to the timing of the AHB protocol.

[0033] Step 6: During the execution of C test cases, the UVM termination function is called to record error information during the execution of C test cases; In this embodiment, by calling the UVM termination function, error information during the execution of C test cases can be analyzed and recorded, such as error type, time of error occurrence, and total number of errors.

[0034] Step 7: Call the finish function via the UVM termination function to end the verification process of the hardware security module to be verified.

[0035] In this embodiment, the simulation process can be terminated by calling the finish function through the UVM termination function, thereby ending the verification process of the hardware security module to be verified.

[0036] For ease of understanding, see Figure 4 The diagram shows an environment architecture that can be divided into three main parts: a hardware security module to be verified, a UVM+C-based environment, and algorithm model files and C test case files written in different languages.

[0037] The interconnections between the components are as follows: the hardware security module to be verified interacts with the UVM environment through an interface; the C environment interacts with the algorithm model and C test cases through .so dynamic library files; and the UVM and C environments interact through DPI. The specific configuration process is as follows: (1) Configuration of functions in the UVM environment: Analyze the characteristics of the hardware security module to be verified and confirm that it has control interface and data interface. Then, construct control interface read function, control interface write function, data interface read function and data interface write function in the UVM environment sequencer to drive the control interface and data interface of the hardware security module to be verified. (2) Configuration of functions in the interface: Use DPI to import the C trigger function in the C environment into the interface. At the same time, wrap the control interface read function, control interface write function, data interface read function and data interface write function in the sequencer to obtain the control interface read wrapper function, control interface write wrapper function, data interface read wrapper function and data interface write wrapper function. The feature of this function is that it is defined in the interface and can trigger the function in the sequencer.

[0038] (3) Function configuration in the C environment: The C environment contains a top-level function, the C trigger function, which calls the C initialization function. The C initialization function then calls the DPI setting function and the C test case function. Furthermore, the C initialization function uses the dlopen dynamic library linking function to expose the algorithm model and C test cases to the C environment, allowing the call of algorithm functions and C test cases. In addition, it also uses DPI to export the control interface read wrapper function, control interface write wrapper function, data interface read wrapper function, and data interface write wrapper function from the interface to the C environment for use. (4) The C test case will call the algorithm function, control interface read wrapper function, control interface write wrapper function, data interface read wrapper function and data interface write wrapper function as needed to realize the data reading, writing and verification of the hardware security module. For example, taking the construction of AES (Advanced Encryption Standard) symmetric encryption scenario as an example, firstly, the C test case calls the control port read wrapper function and control port write wrapper function to start the hardware security module to be verified. After the hardware security module to be verified is started, it will operate the data port to read and write plaintext data in the UVM environment, obtain ciphertext data after calculation, and save the ciphertext data in the UVM environment. Finally, the ciphertext data is compared with the result of the AES algorithm function. If the result is consistent, the verification is successful.

[0039] (5) When the simulation is started, the simulator will start the SV test case, which will call the UVM initialization function, hardware initialization function, C trigger function and UVM termination function in sequence.

[0040] (6) Finally, execute the SV test cases and C test cases.

[0041] Compared to existing verification environments, this approach only requires declaring UVM activation functions in the interface and adding initialization logic such as loading cmodel files in the C environment, making structural optimization less difficult. Verifying the hardware security module under test using this environment structure eliminates the need to consider the mapping between cmodel functions and SV data types in the UVM environment compared to existing solutions. This reduces the debugging difficulty of the reference model (corresponding to the aforementioned algorithm model), improves verification efficiency, and allows for data reading, writing, and verification of the hardware security module under test within the C environment. It also skips the initialization startup process simulation and supports algorithm models in multiple languages, including C and Python.

[0042] like Figure 5 The diagram illustrates an operational flow. The hardware security module to be verified includes a processor core. Each simulation involves an initialization startup process. The simulator's save and restore tools can be used: the save command saves the initialization startup process, and the restore command restores the saved simulation state, thus skipping the initialization startup process. Based on the characteristics of the environment architecture, it can be divided into a reused structure and a variable structure. By utilizing the simulator's breakpoint debugging or simulation state save-restore function, the simulation state of the hardware security module's initialization startup process (i.e., the startup phase) can be saved. Each time the C test case is modified, the above state is directly restored, and the application phase simulation is started, thereby achieving the goal of skipping the hardware security module's initialization startup process. In this approach, the UVM activation function is declared in the sequencer, wrapped in the interface, and exported to the C environment. Furthermore, the SV test cases in the UVM environment call the C trigger function. In addition, the C trigger function loads the cmodel function and C test cases. Moreover, this approach also supports cmodels written in C and Python.

[0043] In summary, this method has the following beneficial effects: 1) Improved verification efficiency, eliminating the need to consider data type mapping between cmodel and sv functions, and reducing the debugging difficulty of the reference model; 2) Supports reference models for different languages, such as C and Python; 3) Supports test case simulation that skips the initialization startup process; Exporting UVM activation functions to the C environment only requires considering the mapping relationship between UVM activation functions and C functions, bypassing the data type mapping between cmodel functions and the UVM environment. Furthermore, both activation functions and cmodel functions can be called within the C environment, facilitating the construction of C test cases. With the DUT unchanged and simulation state saved, modifications to C test cases do not require recompilation, allowing for rapid simulation by skipping the initialization startup process and improving execution flexibility.

[0044] This invention provides a hardware security module verification device based on UVM. A pre-built UVM environment is configured with SV test cases, a target initialization function, a target interface read function, and a target interface write function. A preset interface is configured with a target interface read wrapper function (wrapping the target interface read function) and a target interface write wrapper function (wrapping the target interface write function). A pre-built C environment is configured with a C trigger function, a C initialization function, a DPI setting function, C test cases, and algorithm functions. The hardware security module to be verified interacts with the UVM environment through the preset interface. The C environment and the UVM environment interact via DPI. Figure 6 As shown, the device also includes: The startup module 60 is used to start SV test cases in the UVM environment after receiving a verification instruction for the hardware security module to be verified. Initialization module 61 is used to call the target initialization function in the UVM environment to complete the initialization of the target object; Execution module 62 is used to call C trigger functions in the UVM environment to call C initialization functions and DPI setting functions, and execute C test cases to obtain the verification results corresponding to the hardware security module to be verified; wherein, the C trigger functions in the UVM environment are derived from the C environment through DPI; During the execution of C test cases, the processing module 63 calls the algorithm function. If read and write processing of the hardware security module to be verified is required, it triggers the target interface read function and / or target interface write function in the UVM environment through the target interface read wrapper function and / or target interface write function in the C environment to perform the corresponding read and write operations on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from the preset interface through DPI.

[0045] The aforementioned hardware security module verification device based on UVM eliminates the need to consider data type mapping issues between SystemVerilog and C languages ​​in the UVM environment, thereby improving the verification efficiency of hardware security modules.

[0046] Furthermore, C test cases and algorithm functions in the C environment are obtained in the following way: Obtain C test cases and algorithm functions; C test cases and algorithm functions are compiled into dynamic library files. By loading the dynamic library files in the C environment, the C test cases and algorithm functions can be used in the C environment.

[0047] Furthermore, the hardware security module to be verified includes: a control interface and a data interface; the target interface read functions include: a control interface read function corresponding to the control interface and a data interface read function corresponding to the data interface; the target interface write functions include: a control interface write function corresponding to the control interface and a data interface write function corresponding to the data interface.

[0048] Furthermore, the target initialization function includes: a UVM initialization function and a hardware initialization function; the initialization module is also used to: call the UVM initialization function in the UVM environment to initialize the target component; and call the hardware initialization function in the UVM environment to initialize the hardware corresponding to the hardware security module to be verified.

[0049] Furthermore, the UVM environment is also configured with a UVM termination function; this device is also used to: record error information during the execution of C test cases by calling the UVM termination function; and to terminate the verification process of the hardware security module to be verified by calling the finish function through the UVM termination function.

[0050] Furthermore, the hardware security module to be verified also includes a processor core and an encryption algorithm.

[0051] The hardware security module verification device based on UVM provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned hardware security module verification method based on UVM. For the sake of brevity, any parts not mentioned in the embodiment of the hardware security module verification device based on UVM can be referred to the corresponding content in the aforementioned hardware security module verification method based on UVM.

[0052] This invention also provides an electronic device, see [link to relevant documentation]. Figure 7 As shown, the electronic device includes a processor 130 and a memory 131. The memory 131 stores machine-executable instructions that can be executed by the processor 130. The processor 130 executes the machine-executable instructions to implement the aforementioned UVM-based hardware security module verification method.

[0053] Furthermore, Figure 7 The electronic device shown also includes a bus 132 and a communication interface 133, with the processor 130, the communication interface 133 and the memory 131 connected via the bus 132.

[0054] The memory 131 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 133 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 132 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0055] Processor 130 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 130 or by instructions in software form. Processor 130 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 131, and processor 130 reads the information in memory 131 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0056] This invention also provides a machine-readable storage medium storing machine-executable instructions. When these machine-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned UVM-based hardware security module verification method. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0057] The computer program product of the hardware security module verification method, device and electronic device based on UVM provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0058] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0059] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A hardware security module verification method based on UVM, characterized in that, The pre-built UVM environment is configured with SV test cases, target initialization functions, target interface read functions, and target interface write functions; the pre-built interface is configured with a target interface read wrapper function that wraps the target interface read function, and a target interface write wrapper function that wraps the target interface write function; the pre-built C environment is configured with C trigger functions, C initialization functions, DPI setting functions, C test cases, and algorithm functions; The hardware security module to be verified interacts with the UVM environment through the preset interface; the C environment interacts with the UVM environment through DPI; the method further includes: Upon receiving a verification instruction for the hardware security module to be verified, the SV test case is initiated in the UVM environment. In the UVM environment, the target initialization function is called to initialize the target object; In the UVM environment, the C trigger function is called to invoke the C initialization function and the DPI setting function, and the C test case is executed to obtain the verification result corresponding to the hardware security module to be verified; wherein, the C trigger function in the UVM environment is derived from the C environment through the DPI; During the execution of the C test case, the algorithm function is called. If read / write processing of the hardware security module to be verified is required, the target interface read function and / or target interface write function in the UVM environment are triggered through the target interface read wrapper function and / or target interface write function in the C environment to perform the operation corresponding to the read / write processing on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from the preset interface through the DPI.

2. The method according to claim 1, characterized in that, The C test cases and algorithm functions in the C environment are obtained in the following way: Obtain the C test cases and algorithm functions; The C test cases and the algorithm functions are compiled into a dynamic library file, and the dynamic library file is loaded in the C environment to use the C test cases and the algorithm functions in the C environment.

3. The method according to claim 1, characterized in that, The hardware security module to be verified includes a control interface and a data interface; the target interface read function includes a control interface read function corresponding to the control interface and a data interface read function corresponding to the data interface. The target interface write function includes: a control interface write function corresponding to the control interface and a data interface write function corresponding to the data interface.

4. The method according to claim 1, characterized in that, The target initialization function includes a UVM initialization function and a hardware initialization function; the steps of calling the target initialization function in the UVM environment to complete the initialization of the target object include: In the UVM environment, the UVM initialization function is called to initialize the target component; The hardware initialization function is called in the UVM environment to initialize the hardware corresponding to the hardware security module to be verified.

5. The method according to claim 1, characterized in that, The UVM environment is also configured with a UVM termination function; the method further includes: During the execution of the C test case, the error information during the execution of the C test case is recorded by calling the UVM termination function; The verification process for the hardware security module to be verified is terminated by calling the finish function through the UVM termination function.

6. The method according to claim 1, characterized in that, The hardware security module to be verified also includes a processor core and an encryption algorithm.

7. A hardware security module verification device based on UVM, characterized in that, The pre-built UVM environment is configured with SV test cases, target initialization functions, target interface read functions, and target interface write functions; the pre-built interface is configured with a target interface read wrapper function that wraps the target interface read function, and a target interface write wrapper function that wraps the target interface write function; the pre-built C environment is configured with C trigger functions, C initialization functions, DPI setting functions, C test cases, and algorithm functions; The hardware security module to be verified interacts with the UVM environment through the preset interface; The C environment interacts with the UVM environment via DPI; the device also includes: The startup module is used to start the SV test case in the UVM environment after receiving a verification instruction for the hardware security module to be verified. An initialization module is used to call the target initialization function in the UVM environment to initialize the target object; An execution module is configured to call the C trigger function in the UVM environment to call the C initialization function and the DPI setting function, and execute the C test cases to obtain the verification result corresponding to the hardware security module to be verified; wherein, the C trigger function in the UVM environment is derived from the C environment through the DPI; During the execution of the C test case, the processing module calls the algorithm function. If read / write processing of the hardware security module to be verified is required, the target interface read function and / or target interface write function in the UVM environment are triggered through the target interface read wrapper function and / or target interface write function in the C environment to perform the corresponding read / write operation on the hardware security module to be verified. The target interface read wrapper function and target interface write wrapper function in the C environment are derived from the preset interface through the DPI.

8. The apparatus according to claim 7, characterized in that, The C test cases and algorithm functions in the C environment are obtained in the following way: Obtain the C test cases and algorithm functions; The C test cases and the algorithm functions are compiled into a dynamic library file, and the dynamic library file is loaded in the C environment to use the C test cases and the algorithm functions in the C environment.

9. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the UVM-based hardware security module verification method according to any one of claims 1-6.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the UVM-based hardware security module verification method as described in any one of claims 1-6.

Images