Cross-level processor verification method, system, electronic device, storage medium and computer program product
By implementing bidirectional conversion between standard assembly and class assembly text through scripts, the problem of cross-level processor verification is solved, enabling seamless flow and fine-grained verification at the module and system levels, thereby improving verification efficiency and reusability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI CHAOWEI WUJI ELECTRONIC TECHNOLOGY CO LTD
- Filing Date
- 2026-06-23
- Publication Date
- 2026-07-21
Smart Images
Figure CN122431969A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of processor verification technology, specifically to a cross-level processor verification method, system, electronic device, storage medium, and computer program product. Background Technology
[0002] In the field of processor verification technology, such as the verification of processor cores based on the Reduced Instruction Set Computing (RISC) architecture, existing technologies typically employ module-level verification or system-level verification. In module-level verification, a general verification methodology sequence is usually written using a system-level hardware verification language. To simulate complex instruction flows, verifiers need to set numerous constraints to generate instruction-like stimuli. In system-level verification, standard assembly language or high-level programming languages are primarily used, with hexadecimal files generated by a compiler and run in an on-chip system environment or the processor core's top-level environment. It is evident that these two methods completely isolate the description of stimuli and the runtime environment, thus preventing cross-level stimulus reuse. This leads to the following problems: First, module-level test cases written using hardware description and verification languages cannot run directly in the system-level top-level environment due to differences in runtime mechanisms and environmental dependencies. Conversely, system-level assembly test cases often fail to run in the module-level environment due to the lack of a complete peripheral model or specific interface responses. Secondly, due to the inability to reuse across different levels, verification personnel have to develop two separate sets of stimulus generation logic for the module level and the system level, resulting in a large amount of repetitive verification development work. Furthermore, for computing units such as scalar processor cores and vector processor cores that are highly sensitive to instruction behavior, the fine-grained random stimuli generated by module-level constraints cannot be directly applied to the system-level environment. As a result, verification personnel often have to rely on cumbersome traditional verification intellectual property modules to simulate instruction behavior, making it difficult to accurately and efficiently cover the complex instruction interaction scenarios of specific computing cores.
[0003] In summary, there is an urgent need to provide a method that can achieve cross-level processor verification to solve the above-mentioned technical problems. Summary of the Invention
[0004] The technical problem solved by this application is to provide a cross-level processor verification method, system, electronic device, storage medium and computer program product, which can realize cross-level collaborative verification of processor implementation modules and system.
[0005] According to a first aspect of the embodiments of this application, a cross-level processor verification method is provided, comprising: A script is constructed to convert standard assembly into assembly-like text and then into a hexadecimal file, or to fill in missing fields in the assembly-like text and convert it into standard assembly; the standard assembly consists of test cases for processor system-level verification, and the assembly-like text contains only the test cases necessary for processor module-level verification; the hexadecimal file stores instruction variable values for module-level verification. When system-level verification needs to reuse module-level verification test cases, the script is used to convert the class assembly text corresponding to module-level verification into standard assembly, and system-level verification is performed based on the standard assembly. When system-level verification requires module-level verification reproduction, the script is used to process the standard assembly corresponding to system-level verification to obtain class assembly text, the script is used to process the class assembly text to obtain a hexadecimal file, and the hexadecimal file is used for module-level verification.
[0006] In existing technologies, module-level verification test cases and system-level verification test cases are developed independently based on their respective verification environments. This leads to difficulties in reusing cross-level test cases, resulting in significant duplication of effort and an inability to perform targeted verification of computationally sensitive units during system-level verification. Unlike existing technologies, this application addresses this issue by using scripts to complete class assembly text and convert it into standard assembly when system-level verification requires reuse of module-level verification test cases. This allows for direct use in system-level simulation, avoiding extensive repetitive verification development. Furthermore, when system-level verification requires module-level verification reproduction, scripts process the system-level standard assembly text to obtain class assembly text and hexadecimal files, enabling precise reproduction at the module level. This allows for detailed module-level verification of computationally sensitive units even within the system-level verification environment. This bidirectional pathway enables the seamless transfer of the same set of verification test cases between the module and system levels, achieving cross-level processor verification. In summary, this application introduces the concept of class assembly and supports bidirectional conversion between class assembly text and standard assembly through scripts, enabling a set of test cases to flow seamlessly between the module level and the system level, breaking the barrier that existing technologies cannot achieve cross-level verification.
[0007] In one implementation, the method further includes: if the standard assembly is a random standard assembly generated by an instruction set generator, iteratively performing the following operations: The script is used to convert random standard assembly into random class assembly text; The script is used to convert random assembly text into random hexadecimal files; The random hexadecimal file is sent to the verification module, and the verification result generated by the verification module is obtained. If the verification result is normal, the instruction set generator is used to randomly generate test cases for module-level verification, and the instruction set generator optimization ends. If the verification result is abnormal, the instruction set generator is optimized based on the verification result, and a new random standard assembly is regenerated using the optimized instruction set generator.
[0008] In existing technologies, instruction set generators are commonly used to generate random test cases for processor system-level verification. To ensure that the generated random test cases effectively verify the processor under test, the instruction set generator needs to be optimized within a system-level verification environment to learn the test-related constraints of that environment. That is, existing instruction set generators can only be iteratively optimized after the system-level verification environment is built, a process that is complex and time-consuming. To avoid these problems, accelerate the optimization process of the instruction set generator, and enable it to generate module-level test cases, this application uses a script to convert the random standard assembly (i.e., system-level random test cases) generated by the instruction set generator into class assembly, thereby decomposing the standard assembly into multiple module-level test cases. The constraints contained in the class assembly are verified using the module under test, and the instruction set generator is then specifically optimized based on the module-level verification results. This eliminates the need to build a complete system-level testing environment, thus accelerating the optimization process to some extent. Furthermore, through this process, the optimized instruction set generator can generate test cases for module-level verification.
[0009] In one implementation, the step of using the script to perform standard assembly processing corresponding to system-level verification to obtain assembly-like text includes: The script is used to trim the standard assembly to obtain the initial assembly text; The initial assembly text is simplified to obtain a class assembly text.
[0010] In one implementation, the step of using the script to trim the standard assembly includes: selecting and retaining the assembly content necessary for the module-level verification from the standard assembly according to the module-level verification requirements, and removing the assembly content that is irrelevant to the module-level verification to obtain the initial assembly text.
[0011] In one embodiment, simplifying the initial assembly text includes: rewriting the initial assembly text to eliminate semantic interactive assembly content generated by verification instruction interaction in the initial assembly text, converting the initial assembly text into a local assembly text only for the module under test, and using the local assembly text as a class assembly text; the local assembly text only represents the state modification or stimulus application to the module under test, and does not include the source information and transmission path information of the state modification or stimulus.
[0012] In the above embodiments, this application uses scripts to trim and simplify the content of standard assembly, ensuring that the generated assembly-like text only represents the state modification or stimulus application of the module under test. This removes the source information of the stimulus and simplifies the module-level verification environment to the greatest extent possible, without having to rebuild the system context unrelated to the module under test. In other words, this application can achieve the reuse of system-level test cases to module-level test cases by simply trimming and simplifying the standard assembly using scripts, and can achieve cross-level processor verification from system to module without having to rewrite test cases for module-level verification.
[0013] In one implementation, the step of processing the assembly text using the script to obtain a hexadecimal file includes: The verification instructions in the assembly text are identified by keyword matching, and the variable values in the verification instructions are extracted; according to the interface signal definition of the module under test, the variable values are converted into corresponding interface signal values; the interface signal values are sorted according to the interface order to generate a hexadecimal file.
[0014] In this embodiment, the present application uses a hexadecimal file to store all the input stimulus variable values of the module under test in a structured manner, which makes it easy for the module under test to directly read the driver without the need for additional format adaptation development, and focuses the processor verification more on the instruction logic itself rather than simple interface behavior.
[0015] According to a second aspect of the embodiments of this application, a cross-level processor verification system is provided, comprising: A script building module is used to build scripts that convert standard assembly into assembly-like text and then into hexadecimal files, or to perform missing field completion on assembly-like text and convert it into standard assembly. The standard assembly consists of test cases for processor system-level verification, while the assembly-like text contains only test cases necessary for processor module-level verification. The hexadecimal files store instruction variable values for module-level verification. The upward reuse module is used to convert the class assembly text corresponding to the module-level verification into standard assembly when the system-level verification needs to reuse the module-level verification test cases. System-level verification is then performed based on this standard assembly. The downward reproduction module is used to process the standard assembly corresponding to the system-level verification to obtain a class assembly text when the system-level verification requires module-level verification reproduction. The script is then used to process the class assembly text to obtain a hexadecimal file, and the hexadecimal file is used for module-level verification.
[0016] According to a third aspect of the embodiments of this application, an electronic device is provided, including a memory and a processor, wherein the memory is used to store a computer program executable by the processor; and the processor is used to execute the computer program in the memory to implement the above-described cross-level processor verification method.
[0017] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the executable computer program in the storage medium is executed by a processor, the above-described cross-level processor verification method can be implemented.
[0018] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the cross-level processor verification method described above. Attached Figure Description
[0019] Figure 1 This is a flowchart illustrating a cross-level processor verification method according to an exemplary embodiment; Figure 2 This is an iterative optimization flowchart of an instruction set generator according to an exemplary embodiment; Figure 3 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation
[0020] Unless otherwise defined, the technical or scientific terms used in this specification and claims shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. Specific embodiments of this application will be described below in conjunction with the accompanying drawings. It should be noted that, in order to provide a concise description, this specification cannot exhaustively describe all features of the actual embodiments. Without departing from the spirit and scope of this application, those skilled in the art can modify and substitute the embodiments of this application, and the resulting embodiments are also within the protection scope of this application.
[0021] Existing technologies employ two incompatible verification methods for processors: module-level verification and system-level verification. Specifically, module-level test cases, written in hardware description and verification languages, cannot run directly in the system-level top-level environment due to differences in their operating mechanisms and environmental dependencies. Conversely, system-level assembly test cases often fail to run in a module-level environment due to the lack of a complete peripheral model or specific interface responses. In other words, existing solutions cannot achieve cross-level processor verification because module-level and system-level test cases cannot be reused. Furthermore, the inability to reuse test cases across levels leads to a significant amount of repetitive verification development work and results in weak targeting for verification of instruction-sensitive modules.
[0022] To address the aforementioned technical problems, this application proposes a cross-level processor verification method, system, electronic device, storage medium, and computer program product that can achieve cross-level processor verification.
[0023] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0024] One embodiment of this application provides a cross-level processor verification method. This cross-level processor verification method can be applied to electronic devices. Please refer to... Figure 1 This cross-level processor verification method may include the following steps 101 to 106: Step 101, Build the script.
[0025] In this application, the constructed script, based on testing requirements, includes the following functions: converting standard assembly into assembly-like text and converting the assembly-like text into a hexadecimal file, or converting the assembly-like text into standard assembly by filling in missing fields.
[0026] It should be noted that standard assembly contains test cases for processor system-level verification, class assembly text contains only test cases necessary for processor module-level verification, and hexadecimal files store instruction variable values used for module-level verification.
[0027] If system-level verification requires the reuse of module-level verification test cases, proceed to steps 102-103.
[0028] Step 102: Use a script to convert the class assembly text corresponding to the module-level verification into standard assembly.
[0029] Step 103: Perform system-level verification based on the standard compilation.
[0030] If system-level verification requires module-level verification reproduction, proceed to steps 104-106.
[0031] Step 104: Use a script to process the standard assembly corresponding to system-level verification to obtain class assembly text.
[0032] In one embodiment, the process includes: Step 1041: Use a script to trim the standard assembly to obtain the initial assembly text.
[0033] In one embodiment, using a script to trim the standard assembly includes: selecting and retaining the assembly content necessary for the module-level verification from the standard assembly according to the module-level verification requirements, and removing the assembly content that is irrelevant to the module-level verification, to obtain the initial assembly text.
[0034] For ease of understanding, in this embodiment, this application takes the vector core in the processor as an example. In the standard assembly used to verify the vector core, the scalar instruction slots that are unrelated to the verification vector core are ignored, and only the opcodes and thresholds related to vector operations are retained.
[0035] Step 1042: Simplify the initial assembly text to obtain a class assembly text.
[0036] In one embodiment, the initial assembly text is simplified by: rewriting the initial assembly text to eliminate the semantic interactive assembly content generated by the verification instruction interaction in the initial assembly text, converting the initial assembly text into a local assembly text only for the module under test, and using the local assembly text as a class assembly text; the local assembly text only represents the state modification or stimulus applied to the module under test, and does not include the source information and transmission path information of the state modification or stimulus.
[0037] For ease of understanding, in this embodiment, this application takes the loading memory unit as an example. For the loading memory unit, it only focuses on the loading instructions and the storage instructions. Therefore, when verifying the unit, only the variables and their corresponding values in the loading and storage instructions in the initial assembly text are retained, and the source of the variable values does not need to be retained.
[0038] Step 105: Use a script to process the assembly text to obtain a hexadecimal file.
[0039] In some embodiments, a script is used to process the assembly text to obtain a hexadecimal file, including: Step 1051: Identify the verification instructions in the assembly text by keyword matching, and extract the variable values in the verification instructions.
[0040] Step 1052: Based on the interface signal definition of the module under test, convert the variable values into the corresponding interface signal values.
[0041] Step 1053: Sort the interface signal values according to the interface order and generate a hexadecimal file.
[0042] For ease of understanding, this application uses the load-store module of a fifth-generation reduced instruction set computer as an example to illustrate the process disclosed in this embodiment. For this module, the corresponding assembly text stores stored instructions. A script is used to parse the assembly text using keywords and perform instruction matching based on the parsed keywords. Upon successful matching, the values of variables such as general-purpose registers and immediate values are retrieved. These variables are then converted into hexadecimal values required by the interface. If the interface may contain addresses and data, the script will convert the address value into one hexadecimal value and the data value into another hexadecimal value. For example, if the address value is set to... The data value is set to Then the hexadecimal file corresponding to this use case can be: .
[0043] Step 106: Perform module-level verification using a hexadecimal file.
[0044] In this step, the general verification methodology driver reads the contents of the hexadecimal file and parses it line by line into drive signals, which are then sent to the module under test. Using the example provided in step 1053 as an example, the driver reads the hexadecimal values corresponding to the address and data, respectively. and Following the order of address interface first and data interface second as defined in the interface definition, the corresponding values are assigned to the address variable and data variable in sequence, and then the driver is passed to the interface.
[0045] It should be noted that, in another embodiment, if the standard assembly for system-level verification and the class assembly text format required for module-level reproduction are completely consistent, steps 104 to 106 can be omitted to process the standard assembly, and the standard assembly can be directly applied in the module under test.
[0046] In one embodiment, the cross-level processor verification method further includes, when the standard assembly is random standard assembly generated by the instruction set generator, verifying the instruction set generator according to... Figure 2 The process shown is iteratively optimized, including steps 201 to 206.
[0047] Step 201: Use a script to convert the random standard assembly into random class assembly text.
[0048] Step 202: Use a script to convert the random assembly text into a random hexadecimal file.
[0049] Step 203: Send the random hexadecimal file into the verification module and obtain the verification result generated by the verification module.
[0050] Step 204: Determine if the verification result is normal. If it is normal, proceed to step 205; otherwise, proceed to step 206.
[0051] Step 205: If the verification result is normal, use the instruction set generator to randomly generate test cases for module-level verification, and end the instruction set generator optimization.
[0052] Step 206: If the verification result is abnormal, optimize the instruction set generator based on the verification result, and use the optimized instruction set generator to regenerate a new random standard assembly.
[0053] This embodiment addresses the problem in existing technologies where instruction set generators are only used to generate random test cases for processor system-level verification, and their optimization process is time-consuming and complex due to reliance on the system-level verification environment. In this embodiment, a script is introduced to convert the standard assembly generated by the instruction set generator into class assembly, thereby breaking down the standard assembly into multiple module-level test cases. The constraints contained in the class assembly are verified using the module under test, and the instruction set generator is optimized based on the module-level verification results. This allows the instruction set generator to be optimized iteratively through module-level verification, and also enables the generation of random stimuli for module-level verification during the verification process itself.
[0054] In one specific embodiment of this application, the vector processing module of a fifth-generation reduced instruction set computer is used as an example object to apply the cross-level processor verification method provided above. Specifically, for the vector processing module, if the system verification language is directly used to describe the vector preparation instructions... Vector addition instruction The constraints between these instructions can be extremely complex because: these two instructions require that a vector preparation instruction must be executed before the vector addition instruction can be executed to complete the data preparation; furthermore, some fields in the instructions may be related to the contents of the lookup table, requiring further constraints to ensure that the lookup result matches the specific value of the next instruction. Such relationships are extremely complex. If implemented using a system verification language, it would require maintaining complex pre-randomization or post-randomization logic to record the state of preceding instructions and then generate subsequent stimuli accordingly, resulting in high development and debugging costs.
[0055] When the instruction set size is expanded to hundreds of instructions, the complexity of the constraints increases exponentially compared to the complexity of constraints between two vector instructions. More importantly, these constraints specifically designed for vector instructions are difficult to directly reuse in system-level verification within the processor. This is because the system-level verification environment is filled with scalar instructions, load-store instructions, branch instructions, and more, in addition to vector instructions. These complex inter-instruction constraints are not essential for the module under test during module-level verification; therefore, implementing them only once in the instruction set generator is sufficient. Repeatedly developing similar fully random constraints at the module level would result in a huge waste of manpower.
[0056] Based on this, the solution provided in this application is adopted, and when developing module-level test cases, the instruction sequence is written according to a class assembly text format, such as: This type of assembly text clearly describes the two instructions to be sent and their order, and explicitly specifies the input operation values. Simultaneously, the instruction set generator can also forward generate sequences with similar instruction arrangements, and process them using steps 104-106 to convert them into module-level random test cases. During this process, the module-level environment can also assist in iterating the results generated by the instruction set generator, without needing to develop system-level random constraint logic.
[0057] During the module simulation phase, the written assembly text is converted into a readable hexadecimal file by a script. The verification environment, built based on a general verification methodology, reads the hexadecimal file and then the driver drives the parsed opcodes and register indices to the vector processing core to complete the stimulus input.
[0058] When large-scale random stress testing is required, the instruction set generator is called to generate tens of thousands or even more vector instruction sequences. These sequences are standard assembly. These randomly generated standard assembly are converted into assembly-like text using step 104 provided in this application. Then, the assembly-like text is converted into a hexadecimal file in step 105. Finally, the hexadecimal file is loaded into the module-level environment for execution according to step 106, thereby fully verifying the correctness of the module's functionality under random and high-load conditions.
[0059] After the module verification is passed, these class assembly texts can be directly compiled by the compiler and tested in the system-level verification environment, thereby realizing the inheritance and reuse of system-level verification. There is no need to redevelop any instruction constraints or test sequences for the top-level environment, which significantly improves verification efficiency and reusability.
[0060] In summary, the technical solution provided in this application has the following advantages: 1) This application enables the conversion between class assembly and standard assembly through scripts, allowing the same set of test cases to flow across levels between the module level and the system level, avoiding the duplication of test case development, and supporting targeted verification of instruction-sensitive computing units.
[0061] 2) The method provided in this application can convert the system-level random standard assembly generated by the instruction set generator into class assembly, and decompose the system-level test cases into module-level test cases. The generator can be optimized without building a complete system environment, so that the optimized instruction set generator can also generate module-level test cases.
[0062] Another embodiment of this application also provides a cross-level processor verification system, which can complement the aforementioned cross-level processor verification method, and specifically includes: The script building module is used to build scripts that convert standard assembly into assembly-like text and then into hexadecimal files, or to fill in missing fields in assembly-like text and convert it into standard assembly. The standard assembly contains test cases for processor system-level verification, while the assembly-like text contains only the test cases necessary for processor module-level verification. The hexadecimal files store the instruction variable values used for module-level verification. Upward reuse module is used to convert the class assembly text corresponding to the module-level verification into standard assembly when system-level verification needs to reuse module-level verification test cases. System-level verification is then performed based on this standard assembly. The downward reproduction module is used when module-level verification reproduction is required for system-level verification. It uses scripts to process the standard assembly corresponding to system-level verification to obtain class assembly text, processes the class assembly text to obtain a hexadecimal file, and uses the hexadecimal file for module-level verification.
[0063] It should be noted that the steps performed by each module in the system during runtime are similar to those in the cross-level processor verification method, and will not be elaborated here.
[0064] Embodiments of this application also propose an electronic device, including a processor and a memory; the memory is used to store a computer program executable by the processor; the processor is used to execute the computer program in the memory to implement the cross-level processor verification method of any of the above embodiments.
[0065] Embodiments of this application also propose a computer-readable storage medium that, when an executable computer program in the storage medium is executed by a processor, enables the implementation of the cross-level processor verification method of any of the above embodiments.
[0066] Embodiments of this application also propose a computer program product, including a computer program that, when executed by a processor, implements the cross-level processor verification method of any of the above embodiments.
[0067] Embodiments of this application also provide an electronic device 600, such as... Figure 3 As shown, the electronic device 600 includes a memory 601 and a processor 602. The memory 601 is used to store a computer program product, which includes a computer program executable by the processor 602. The processor 602 is used to execute the computer program in the memory 601 to implement the cross-level processor verification method provided in any of the above embodiments.
[0068] The electronic device 600 also includes a communication interface 603. The processor 602, memory 601, and communication interface 603 are connected via a communication bus and communicate with each other.
[0069] Processor 602 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the above computer program products.
[0070] Communication interface 603 is used to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc.
[0071] The memory 601 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory may exist independently and be connected to the processor via a bus. The memory may also be integrated with the processor.
[0072] In this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The term "multiple" refers to two or more unless otherwise expressly defined.
[0073] The above description of the embodiments is intended to enable those skilled in the art to understand and apply this application. It will be apparent to those skilled in the art that various modifications can be easily made to these embodiments, and the general principles described herein can be applied to other embodiments without creative effort. Therefore, this application is not limited to the embodiments described herein, and any improvements and modifications made by those skilled in the art based on the disclosure of this application without departing from the scope and spirit of this application are within the scope of this application.
Claims
1. A cross-level processor verification method, characterized in that, include: A script is constructed to convert standard assembly into assembly-like text and then into a hexadecimal file, or to fill in missing fields in the assembly-like text and convert it into standard assembly; the standard assembly consists of test cases for processor system-level verification, and the assembly-like text contains only the test cases necessary for processor module-level verification; the hexadecimal file stores instruction variable values for module-level verification. When system-level verification needs to reuse module-level verification test cases, the script is used to convert the class assembly text corresponding to module-level verification into standard assembly, and system-level verification is performed based on the standard assembly. When system-level verification requires module-level verification reproduction, the script is used to process the standard assembly corresponding to system-level verification to obtain class assembly text, the script is used to process the class assembly text to obtain a hexadecimal file, and the hexadecimal file is used for module-level verification.
2. The cross-level processor verification method as described in claim 1, characterized in that, Also includes: In the case that the standard assembly is a random standard assembly generated by the instruction set generator, the following operations are performed iteratively: The script is used to convert random standard assembly into random class assembly text; The script is used to convert random assembly text into random hexadecimal files; The random hexadecimal file is sent to the verification module, and the verification result generated by the verification module is obtained. If the verification result is normal, the instruction set generator is used to randomly generate test cases for module-level verification, and the instruction set generator optimization ends. If the verification result is abnormal, the instruction set generator is optimized based on the verification result, and a new random standard assembly is regenerated using the optimized instruction set generator.
3. The cross-level processor verification method as described in claim 1, characterized in that, The step of using the script to perform standard assembly processing corresponding to system-level verification to obtain class assembly text includes: The script is used to trim the standard assembly to obtain the initial assembly text; The initial assembly text is simplified to obtain a class assembly text.
4. The cross-level processor verification method as described in claim 3, characterized in that, The process of trimming standard assembly using the script includes: Based on the module-level verification requirements, the necessary assembly content for the module-level verification is selected and retained from the standard assembly, while the assembly content irrelevant to the module-level verification is removed to obtain the initial assembly text.
5. The cross-level processor verification method as described in claim 3, characterized in that, The simplification of the initial assembly text includes: The initial assembly text is rewritten to eliminate the semantic interactive assembly content generated by the verification instruction interaction in the initial assembly text, and the initial assembly text is transformed into a local assembly text that is only for the module under test. This local assembly text is used as a class assembly text. The local assembly text only represents the state modification or stimulus applied to the module under test, and does not include the source information or transmission path information of the state modification or stimulus.
6. The cross-level processor verification method as described in claim 1, characterized in that, The process of using the script to process the assembly text to obtain a hexadecimal file includes: The verification instructions in the assembly text are identified by keyword matching, and the variable values in the verification instructions are extracted; according to the interface signal definition of the module under test, the variable values are converted into corresponding interface signal values; the interface signal values are sorted according to the interface order to generate a hexadecimal file.
7. A cross-level processor verification system, characterized in that, include: A script building module is used to build scripts that convert standard assembly into assembly-like text and then into hexadecimal files, or to perform missing field completion on assembly-like text and convert it into standard assembly. The standard assembly consists of test cases for processor system-level verification, and the assembly-like text contains only the test cases necessary for processor module-level verification. The hexadecimal files store instruction variable values for module-level verification. The upward reuse module is used to convert the class assembly text corresponding to the module-level verification into standard assembly when the system-level verification needs to reuse the module-level verification test cases. System-level verification is then performed based on this standard assembly. The downward reproduction module is used to process the standard assembly corresponding to the system-level verification to obtain a class assembly text when the system-level verification requires module-level verification reproduction. The script is then used to process the class assembly text to obtain a hexadecimal file, and the hexadecimal file is used for module-level verification.
8. An electronic device, characterized in that, The method includes a memory and a processor, wherein the memory is used to store a computer program executable by the processor; and the processor is used to execute the computer program in the memory to implement the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the executable computer program in the storage medium is executed by a processor, it can implement the method as described in any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method as described in any one of claims 1 to 6.