Processor debug module verification methods, apparatus, electronic devices and storage media

Abstract

This application provides a processor debug module verification method, apparatus, electronic device, and storage medium. This solution is applicable to verifying debug modules in various chips and processors based on ARM and RISC-V instruction set architectures, such as CPUs, IoT chips, and audio / video chips. The processor debug module verification method includes: sending debug behavior information to the debug module in the processor, wherein the debug behavior information is used to control the processor to enter a target debug state, which is simulated by the processor through hardware code output from the front-end design; if the processor enters the target debug state, sending instruction stimuli to the debug module according to test cases, causing the debug module to control the processor to run according to the instruction stimuli, and obtaining the processor's stimulus execution result; and obtaining the verification result of the debug module based on the stimulus execution result. This solution can improve the design and development efficiency of processors.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a processor debugging module verification method, apparatus, electronic device, and storage medium. Background Technology

[0002] To facilitate the identification and resolution of software and hardware issues during processor design, development, and subsequent use, a debugging module is incorporated into the processor. When software or hardware problems arise during processor design, development, or operation, an external debugging platform can interact with the processor's debugging module to determine the cause of the problem through debugging mode, thereby quickly resolving the processor issue. Therefore, the processor's debugging module determines whether processor debugging can proceed normally, and thus, the debugging module needs to be verified during the processor design process.

[0003] Currently, when verifying the debug module in the processor, after the processor completes the integration of the interactive module, including the debug module, hardware simulation is performed on the debug module in the processor.

[0004] However, after the interaction module is integrated, hardware simulation is performed on the debugging module. If the debugging module malfunctions, the relevant issues need to be fixed in the front-end design. Then, the debugging module needs to be tested after the back-end design is completed. This makes the optimization and iteration of the debugging module take a long time, resulting in low processor design and development efficiency. Summary of the Invention

[0005] In view of this, embodiments of this application provide a processor debugging module verification method, apparatus, electronic device, and storage medium to at least solve or alleviate the above-mentioned problems.

[0006] According to a first aspect of the embodiments of this application, a processor debugging module verification method is provided, comprising: sending debugging behavior information to a debugging module in a processor, wherein the debugging behavior information is used to control the processor to enter a target debugging state, the target debugging state including a debugging exception state or a debugging mode state, and the processor is obtained by simulating hardware code output by a front-end design; if the processor enters the target debugging state, sending instruction stimuli to the debugging module according to test cases, causing the debugging module to control the processor to run according to the instruction stimuli, and obtaining the stimulus execution result of the processor; and obtaining the verification result of the debugging module according to the stimulus execution result.

[0007] According to a second aspect of the embodiments of this application, a processor debugging module verification apparatus is provided, comprising: a debugging stimulus generation module, configured to send debugging behavior information to a debugging module in a processor, wherein the debugging behavior information is used to control the processor to enter a target debugging state, the target debugging state including a debugging exception state or a debugging mode state, and the processor is obtained by simulating hardware code output by a front-end design; an instruction stimulus testing module, configured to send instruction stimuli to the debugging module according to test cases after the processor enters the target debugging state, causing the debugging module to control the processor to run according to the instruction stimuli, and to obtain the stimulus execution result of the processor; and a processor debugging function verification module, configured to obtain the verification result of the debugging module according to the stimulus execution result.

[0008] According to a third aspect of the present application, an electronic device is provided, including: a processing unit, a memory, a communication interface, and a communication bus, wherein the processing unit, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processing unit to perform the operation corresponding to the processor debugging module verification method provided in the first aspect.

[0009] According to a fourth aspect of the embodiments of this application, a computer storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the processor debugging module verification method described in the first aspect above.

[0010] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including computer instructions that instruct a computing device to execute the processor debugging module verification method described in the first aspect above.

[0011] According to the processor debugging module verification scheme provided in this application, after the front-end design outputs hardware code, the processor is simulated using the hardware code. The simulated processor includes a debugging module. After sending debugging behavior information to the debugging module, if the processor enters the target debugging state, instruction stimuli are sent to the debugging module according to the test cases, causing the debugging module to control the processor's operation according to the instruction stimuli. After sending the instruction stimuli, the processor's execution result for the instruction stimuli can also be obtained, and the verification result of the debugging module can be obtained based on the instruction stimuli execution result. It is evident that after the front-end design is completed, the processor can be simulated using hardware code to verify the debugging module in the processor, without waiting for the integration of the interaction module in the processor. This allows for optimization of the debugging module during the front-end design stage, saving the time required for optimization and iteration of the debugging module, thereby improving the design and development efficiency of the processor. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0013] Figure 1 This is a schematic diagram of an exemplary system applied in one embodiment of this application;

[0014] Figure 2 This is a flowchart of a processor debugging module verification method according to an embodiment of this application;

[0015] Figure 3 This is a flowchart of an instruction stimulus transmission method according to an embodiment of this application;

[0016] Figure 4 This is a schematic diagram of a processor debugging module verification device according to an embodiment of this application;

[0017] Figure 5 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0018] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the essence of the present application, well-known methods, processes, and flows are not described in detail. Furthermore, the accompanying drawings are not necessarily drawn to scale.

[0019] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows.

[0020] Debugging: Debugging is a technique based on hardware debugging equipment and often used in conjunction with software debugging tools to locate and resolve hardware and software problems that occur in the processor.

[0021] Test Case: A test case is a description of a testing task for a specific software product, embodying the test plan, methods, techniques, and strategies. Its content includes test objectives, test environment, input data, test steps, expected results, test scripts, etc., ultimately forming a document. Simply put, a test case is a set of test inputs, execution conditions, and expected results compiled for a specific objective to verify whether a specific software requirement is met. In this embodiment, a test case refers to a description of a testing task for the debugging module in the processor.

[0022] Processor design can be divided into three phases: specification definition, system-level design, front-end design, and back-end design. Specification definition involves initial requirements analysis to determine the processor's cost, purpose, and performance, thus defining the overall direction of the processor design. System-level design, based on the initial specification definition, specifies the design solution and concrete implementation architecture, divides module functions, and clarifies the processor architecture, business modules, power supply, and other system-level designs. Front-end design, based on the system design, describes the actual hardware circuit functions using a hardware description language (HTAL), forming RTL code. Back-end design converts the logic synthesis into a physical netlist, which is then converted into a graphical file that the manufacturing plant can use to create photomasks.

[0023] Exemplary System

[0024] Figure 1 An exemplary system for verifying a processor debug module applicable to embodiments of this application is shown. For example... Figure 1 As shown, the system includes a processor debugging module verification device 10 and a simulation verification module 20. The simulation verification module 20 can simulate the processor 21 to be verified through the hardware code output by the front-end design. The simulation verification module 20 simulates the processor 21, which includes a debugging module 22 for debugging. The debugging module 22 is located in the processor core of the processor 21.

[0025] The processor debugging module verification device 10 is connected to the simulation verification module 20 via a communication network / bus 30. The processor debugging module verification device 10 can send debugging requests to the debugging module 22 via the communication network / bus 30, and can also obtain the operating status and instruction execution status of the processor 21 via the communication network / bus 30, thereby realizing the simulation verification of the debugging module 22.

[0026] In some embodiments, the communication network / bus 30 can be any suitable combination of one or more wired and / or wireless networks. For example, the communication network / bus 30 can include any one or more of the following: the Internet, intranet, wide area network (WAN), local area network (LAN), wireless network, digital subscriber line (DSL) network, frame relay network, asynchronous transfer mode (ATM) network, virtual private network (VPN), and / or any other suitable communication network. The processor debug module verification device 10 can be connected to the communication network / bus 30 via one or more communication links, which can be linked to the emulation verification module 20 via one or more communication links. The communication link can be any communication link suitable for transmitting data between the processor debug module verification device 10 and the emulation verification module 20, such as a network link, dial-up link, wireless link, hardwired link, any other suitable communication link, or any suitable combination of such links.

[0027] In some embodiments, the processor debugging module verification device 10 can be any suitable device for storing information, data, programs, and / or any other suitable type of content, including but not limited to distributed storage system devices, server clusters, cloud computing server clusters, local servers, PCs, etc. In some embodiments, the processor debugging module verification device 10 can perform any suitable function. For example, in some embodiments, the processor debugging module verification device 10 can send a debugging request to the simulation verification module 20 and obtain the operating status and instruction execution status of the processor 21 simulated by the simulation verification module 20, thereby verifying whether the debugging module 22 meets the design requirements.

[0028] Processor 21 can be based on an open-source instruction set architecture based on the Reduced Instruction Set Computing (RISC) principle. In one example, processor 21 can be designed based on the RISC-V instruction set, such as a CPU, GPU, or Application Specific Integrated Circuit (ASIC) designed based on the RISC-V instruction set.

[0029] This application embodiment mainly focuses on the process of the processor debugging module verification device 10 verifying the debugging module 22. The verification process of the debugging module 22 will be described in detail later.

[0030] Processor debug module verification method

[0031] Based on the above system, this application provides a processor debugging module verification method, which can be executed by the processor debugging module verification device 10 in the above system embodiment. The following describes the processor debugging module verification method in detail through multiple embodiments.

[0032] Figure 2 This is a flowchart of a processor debugging module verification method according to an embodiment of this application. Figure 2 As shown, the processor debug module verification method includes the following steps:

[0033] Step 201: Send debugging behavior information to the debugging module in the processor.

[0034] In this embodiment, the processor refers to a processor simulated through hardware code output from a front-end design. The simulated processor can respond to data processing requests and perform data processing just like a physical processor. The physical processor includes a debugging module, which allows for debugging of the processor and, by locating, resolving any hardware or software issues. The simulated processor also includes a debugging module, which can then be verified through simulation.

[0035] The processor's target debug states include debug exception states and debug mode states. In debug exception states, the processor handles any exceptions that occur and continues executing subsequent instruction streams after exception handling is complete. In debug mode states, the processor responds to externally input debug requests and executes corresponding processing. When multiple debug requests are input consecutively from the outside, the processor responds to each debug request sequentially. When no debug requests are input from the outside, the processor does not execute instruction streams on its own.

[0036] When the verification of the debug module begins, debug behavior information is first sent to the debug module. This debug behavior information is used to control the processor to enter a debug exception state or debug mode state, so as to verify the debug module when the processor is in different debug states.

[0037] Step 202: If the processor enters the target debug state, send instruction stimuli to the debug module according to the test cases, so that the debug module controls the processor to run according to the instruction stimuli and obtains the processor's stimulus execution results.

[0038] Debugging behavior information is used to control the processor to enter the target debug state. If the processor fails to enter the target debug state after the debugging behavior information is sent to it, it indicates that the debug module in the processor cannot be enabled normally, thus confirming a functional abnormality in the debug module. If the processor can enter the target debug state normally, the functionality of the debug module can be further verified based on test cases.

[0039] Test cases for testing the debugging module are obtained in advance. These test cases describe the testing tasks for the debugging module, specifically including the test plan, methods, techniques, and strategies. Their content includes test objectives, test environment, input data, test steps, expected results, and test scripts. Based on the test cases, the instruction stimuli to be sent to the debugging module can be determined. These instruction stimuli can be a single debugging request or a stream of instructions formed by the sequential combination of multiple debugging requests.

[0040] After the processor enters the target debug state, instruction stimuli are sent to the debug module according to the test cases. Upon receiving the instruction stimuli, the debug module controls the processor to run and execute the corresponding actions. After sending instruction stimuli to the debug module, the processor's execution results for the instruction stimuli can also be obtained. The execution results may include the processor's returned running status information, the executed instructions, the accessed memory addresses, etc.

[0041] Step 203: Based on the stimulus execution results, obtain the verification results of the debugging module.

[0042] After sending all instruction stimuli to the debug module according to the test cases and obtaining the processor's stimulus execution results for each instruction stimulus, the verification results of the debug module can be obtained based on the stimulus execution results. The functionality of the debug module can be determined based on the stimulus execution results, because when the debug module is functioning correctly, the processor's stimulus execution results should be the same as the expected results of the instruction stimuli.

[0043] In this embodiment, after the front-end design outputs hardware code, a processor is simulated using the hardware code. The simulated processor includes a debugging module. After sending debugging behavior information to the debugging module, if the processor enters the target debugging state, instruction stimuli are sent to the debugging module according to the test cases. This causes the debugging module to control the processor's operation based on the instruction stimuli. After sending the instruction stimuli, the processor's execution result in response to the instruction stimuli can be obtained, and the verification result of the debugging module can be obtained based on the instruction stimuli execution result. Therefore, after the front-end design is completed, the processor can be simulated using hardware code to verify the debugging module in the processor, without waiting for the integration of the interaction module in the processor. This allows for optimization of the debugging module during the front-end design phase, saving the time required for optimization and iteration of the debugging module, and thus improving the design and development efficiency of the processor.

[0044] By sending debugging behavior information to the debugging module, the processor can enter a debugging exception state or a debugging mode state. It can also make the processor ignore the current problem or the instruction being executed. Since both the debugging exception state and the debugging mode state are possible debugging states of the physical processor, it can cover different application scenarios of the debugging module and improve the comprehensiveness of the verification of the debugging module.

[0045] In one possible implementation, when sending debugging behavior information to the debugging module in the processor, the debugging behavior information can be sent to the debugging module in the processor when at least one of the value fetching instructions executed by the processor, the memory access data of the processor, and the memory access address of the processor hits a preset trigger. Alternatively, the debugging behavior information can be sent to the debugging module in the processor randomly during the operation of the processor.

[0046] In one example, triggers are pre-set based on test cases. The triggers are triggered by the processor's instruction fetch or memory access behavior, such as the processor executing a specific instruction fetch or accessing a specific cache address. When the processor's instruction fetch or memory access behavior hits the trigger, debugging behavior information is sent to the debugging module in the processor. After receiving the debugging behavior information, the debugging module prompts the processor to enter the target debugging state.

[0047] In another example, during processor operation, debug behavior information is randomly sent to the debug module within the processor based on test cases. Upon receiving this information, the debug module prompts the processor to enter the target debug state. Because the sending of debug behavior information to the debug module is random, both the timing and type of this information are also random.

[0048] In this embodiment, debugging behavior information can be sent to the debugging module when the processor's instruction fetch or memory access behavior hits a trigger, or it can be sent randomly. This allows for controlled or random sending of debugging behavior information, enabling the selection of one or both methods to send information to the debugging module as needed. This satisfies the testing requirements of different users and processors, improving the applicability of the debugging module verification method. By sending debugging behavior information to the debugging module through these two methods, the environment and scenarios of the debugging module can be more comprehensively covered during the verification process, thereby improving the comprehensiveness of the debugging module verification.

[0049] In one possible implementation, test cases from other modules in the processor can be obtained in advance and used as test cases for testing the debug module.

[0050] When simulating and verifying the debug module in a processor, test cases used to verify other modules in the processor can be reused as test cases for verifying the debug module. The reused test cases can be test cases from other modules in the same processor or test cases from functional modules in different processors; this embodiment does not limit this. When the reused test case is a test case from a functional module in a processor different from the processor under test, the reused test case can be a test case from a debug module in a processor different from the processor under test. For example, the reused test case was originally used to test the debug module in processor A, and now it is used to test the debug module in processor B.

[0051] In this embodiment, since writing test cases requires binary code construction, the test case construction process is complex, and the constructed test cases include a single instruction sequence. By reusing test cases from one or more other functional modules to verify the debugging module, the time and labor costs spent on constructing test cases can be reduced. Reusing test cases from other modules in the processor to verify the debugging module increases the scenarios and instruction sequences in the verification process, allowing for more comprehensive coverage of random scenarios and instruction stimuli. This enables a more comprehensive verification of the debugging module from multiple dimensions, such as the processor's state when responding to a debugging request, the state of instruction execution in debug mode, and operands, thereby improving the effectiveness, comprehensiveness, and reliability of the debugging module verification.

[0052] In one possible implementation, when testing the debug module using test cases from other modules in the processor, directly sending instruction stimuli to the debug module might cause the processor to behave differently than expected, resulting in poor reliability of the verification results. Therefore, it is necessary to filter and adjust the instruction stimuli before sending them to the debug module.

[0053] Figure 3 This is a flowchart of an instruction stimulus transmission method according to an embodiment of this application. Figure 3 As shown, the instruction excitation sending method includes the following steps:

[0054] Step 301: Read the reuse instruction stimulus according to the test case.

[0055] The reused test cases define the instruction flow that sends instruction stimuli to the target object. In this embodiment, the instruction stimuli defined by the reused test cases are referred to as reused instruction stimuli. Based on the reused test cases, the reused instruction stimuli can be read sequentially or randomly.

[0056] Step 302: Analyze the multiplexed instruction stimulus to obtain the analysis result.

[0057] After reading the multiplexed instruction stimulus, it can be parsed to obtain the corresponding parsing results. The parsing results of the multiplexed instruction stimulus include the behavior produced by the processor when executing the multiplexed instruction stimulus.

[0058] Step 303: Based on the analysis results, determine whether the behavior generated when the processor executes the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus. If so, proceed to step 304; otherwise, proceed to step 305.

[0059] After obtaining the parsing results of the multiplexed instruction stimulus, since the parsing results can indicate the behavior produced by the processor when executing the multiplexed instruction stimulus, and the multiplexed test cases define the expected behavior that the processor should produce when the multiplexed instruction stimulus is executed, it can be determined whether the behavior produced by the processor when executing the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus based on the parsing results and the multiplexed test cases.

[0060] It should be understood that the behavior generated by the processor when executing multiplexed instruction stimuli, as described in this step, refers to the behavior generated by the processor when executing multiplexed instruction stimuli under normal debugging module functionality. If, under normal debugging module functionality, the analysis results determine that the behavior generated by the processor when executing multiplexed instruction stimuli is the same as the expected behavior of the multiplexed instruction stimuli, then if, after actually sending the multiplexed instruction stimuli to the debugging module, the behavior generated by the processor when executing the multiplexed instruction stimuli differs from the expected behavior, then it can be determined that the debugging module is malfunctioning.

[0061] Step 304: Send the multiplexed instruction stimulus as an instruction stimulus to the debugging module and end the current process.

[0062] When the behavior of the processor when executing the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus, the multiplexed instruction stimulus is sent directly to the debug module. This allows the processor to compare the behavior of the processor when executing the multiplexed instruction stimulus with the expected behavior corresponding to the multiplexed instruction stimulus, in order to determine whether the debug module is functioning correctly.

[0063] Step 305: Process the multiplexed instruction stimulus to obtain the instruction stimulus whose behavior is the same as the expected behavior of the multiplexed instruction stimulus when the processor executes it, and send the instruction stimulus to the debug module.

[0064] When the behavior generated by the processor during the execution of a multiplexed instruction stimulus differs from the expected behavior of the multiplexed instruction stimulus, the multiplexed instruction stimulus is processed to generate an instruction stimulus whose behavior during processor execution is identical to the expected behavior of the multiplexed instruction stimulus. This generated instruction stimulus is then sent to the debug module. After the debug module controls the processor to execute the instruction stimulus, it can compare the behavior generated by the processor during instruction stimulus execution with the expected behavior corresponding to the multiplexed instruction stimulus to determine whether the debug module is functioning correctly.

[0065] Processing reused instruction stimuli includes deleting instruction stimuli, adjusting the order of instruction stimuli, adding instruction stimuli, and modifying the parameters of instruction stimuli in the instruction stream defined by the reused test cases, so that the instruction stimuli obtained through processing can be applied to the debugging module under test.

[0066] In this embodiment of the application, the reused instruction stimuli included in the reused test cases may not be fully compatible with the debug module to be verified. By parsing the reused instruction stimuli, processing is performed on reused instruction stimuli that may not produce the expected behavior in debug mode, including but not limited to exceptions, termination, jumps, instruction pointer (PC) maintenance, etc. This ensures that when the debug module functions normally, the behavior generated by the processor after executing the instruction stimuli is the same as the expected behavior, thus ensuring the correctness and effectiveness of the stimuli and program flow in debug mode. This ensures the comprehensiveness of the verification of the debug module while ensuring the accuracy of the verification results.

[0067] In one possible implementation, when reading the multiplexed instruction stimulus according to the test case, the multiplexed instruction stimulus can be read from the cache according to the target address recorded in the test case, or the multiplexed instruction stimulus that matches the instruction text recorded in the test case can be read.

[0068] In this embodiment, when reading multiplexed instruction stimuli, multiplexed instruction stimuli can be read from the cache according to the target address, or the instruction text can be matched to read multiplexed instruction stimuli. Different ways of reading multiplexed instruction stimuli are provided. The reading of multiplexed instruction stimuli can be based on the cache or not, thus being applicable to instruction stimuli provided in different forms, improving the applicability of the verification method of the debugging module.

[0069] In one possible implementation, when obtaining the verification result of the debugging module based on the stimulus execution result, the stimulus execution result, including at least one of the processor's pipeline state, processor privileges, and instruction execution results, can be input into a pre-trained debugging verification model to obtain the verification result output by the debugging verification model.

[0070] The debugging verification model is used to verify whether the debugging module functions properly. After obtaining the stimulus execution results of the processor for each instruction stimulus, the stimulus execution results and the expected results included in the test cases are input into the debugging verification model. By comparing the stimulus execution results with the expected results, the debugging verification model can output verification results indicating whether the debugging module functions properly.

[0071] In this embodiment, after sending debugging behavior information and instruction stimuli to the debugging module, information such as the processor's pipeline status, processor permissions, and instruction execution results can be obtained. This information indicates whether the processor produces the expected behavior. Using this information as the stimulus execution result to obtain the verification result of the debugging module ensures that the obtained verification result can comprehensively indicate whether the debugging module's function is normal, thus improving the accuracy of the debugging module verification. Obtaining verification results through a debugging verification model saves the time and manpower costs required for manual analysis of stimulus execution results, improves the efficiency of verifying the debugging model, and reduces the cost of verifying the debugging module.

[0072] Processor debug module verification device

[0073] Corresponding to the above method embodiments, Figure 4 A schematic diagram of a processor debug module verification device is shown. Figure 4 As shown, the processor debug module verification device 10 includes:

[0074] The debug stimulus generation module 101 is used to send debug behavior information to the debug module in the processor. The debug behavior information is used to control the processor to enter the target debug state. The target debug state includes a debug exception state or a debug mode state, which is simulated by the processor through the hardware code output by the front-end design.

[0075] The instruction stimulus test module 102 is used to send instruction stimuli to the debugging module according to the test cases after the processor enters the target debugging state, so that the debugging module controls the processor to run according to the instruction stimuli and obtains the processor's stimulus execution results;

[0076] The processor debugging function verification module 103 is used to obtain the verification result of the debugging module based on the stimulus execution result.

[0077] In this embodiment, after the front-end design outputs hardware code, a processor is simulated using the hardware code. The simulated processor includes a debugging module. After the debugging stimulus generation module 101 sends debugging behavior information to the debugging module, if the processor enters the target debugging state, the instruction stimulus testing module 102 sends instruction stimuli to the debugging module according to the test cases, causing the debugging module to control the processor's operation according to the instruction stimuli. After sending the instruction stimuli, the processor's stimulus execution result for the instruction stimuli can also be obtained. Then, the processor debugging function verification module 103 obtains the verification result of the debugging module based on the instruction stimulus execution result. It is evident that after the front-end design is completed, the processor can be simulated using hardware code to verify the debugging module in the processor, without waiting for the integration of the interaction module in the processor. This allows for optimization of the debugging module during the front-end design phase, saving the time required for optimization and iteration of the debugging module, thereby improving the processor's design and development efficiency.

[0078] In one possible implementation, the debug stimulus generation module 101 may send debug behavior information to the debug module in the processor when at least one of the instruction fetch, memory access data, and memory access address executed by the processor hits a preset trigger, or randomly send debug behavior information to the debug module in the processor during processor operation.

[0079] In one possible implementation, the instruction stimulus test module 102 can acquire test cases from other modules in the processor as test cases for testing the debug module.

[0080] In one possible implementation, the instruction stimulus testing module 102 can perform the following processing: read the multiplexed instruction stimulus according to the test case; parse the multiplexed instruction stimulus to obtain the parsing result; determine whether the behavior generated by the processor when executing the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus based on the parsing result; if the behavior generated by the processor when executing the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus, then send the multiplexed instruction stimulus as an instruction stimulus to the debugging module; if the behavior generated by the processor when executing the multiplexed instruction stimulus is different from the expected behavior of the multiplexed instruction stimulus, then process the multiplexed instruction stimulus to obtain an instruction stimulus whose behavior is the same as the expected behavior of the multiplexed instruction stimulus when the processor executes it, and send the instruction stimulus to the debugging module.

[0081] In one possible implementation, when the stimulus test module 102 executes the read multiplexed instruction stimulus according to the test case, it can read the multiplexed instruction stimulus from the cache according to the target address recorded in the test case, or read the multiplexed instruction stimulus that matches the instruction text recorded in the test case.

[0082] In one possible implementation, the processor debugging function verification module 103 can input the stimulus execution result, which includes at least one of the processor's pipeline state, processor privileges, and instruction execution results, into a pre-trained debugging verification model to obtain the verification result of the debugging module output by the debugging verification model.

[0083] It should be noted that the processor debugging module verification device in this embodiment is used to implement the corresponding processor debugging module verification method in the foregoing method embodiment, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0084] electronic devices

[0085] Figure 5 This is a schematic block diagram of an electronic device provided in an embodiment of this application. Specific embodiments of this application do not limit the specific implementation of the electronic device. Figure 5 As shown, the electronic device may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 508. Wherein:

[0086] The processing unit 502, the communication interface 504, and the memory 506 communicate with each other via the communication bus 508.

[0087] Communication interface 504 is used to communicate with other electronic devices or servers.

[0088] The processing unit 502 is used to execute program 510, which can specifically execute the relevant steps in any of the aforementioned processor debugging module verification method embodiments.

[0089] Specifically, program 510 may include program code that includes computer operation instructions.

[0090] Processing unit 502 may be a CPU, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The electronic device may include one or more processing units of the same type, such as one or more CPUs; or it may include processing units of different types, such as one or more CPUs and one or more ASICs.

[0091] RISC-V is an open-source instruction set architecture based on the Reduced Instruction Set Computing (RISC) principle. It can be applied to various aspects of microcontrollers and FPGA chips, specifically in areas such as IoT security, industrial control, mobile phones, and personal computers. Because its design considers small size, speed, and low power consumption, it is particularly suitable for modern computing devices such as warehouse-scale cloud computers, high-end mobile phones, and tiny embedded systems. With the rise of AIoT (Artificial Intelligence of Things), the RISC-V instruction set architecture is receiving increasing attention and support and is expected to become the next generation of widely used CPU architecture.

[0092] The computer operation instructions in this embodiment can be computer operation instructions based on the RISC-V instruction set architecture. Correspondingly, the processing unit 502 can be designed based on the RISC-V instruction set. Specifically, the chip of the processing unit in the electronic device provided in this embodiment can be a chip designed using the RISC-V instruction set. This chip can execute executable code based on the configured instructions, thereby realizing the processor debugging module verification method in the above embodiment.

[0093] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0094] Specifically, program 510 can be used to cause processing unit 502 to execute the processor debugging module verification method in any of the foregoing embodiments.

[0095] The specific implementation of each step in program 510 can be found in the corresponding steps and units described in any of the aforementioned processor debugging module verification method embodiments, and will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the devices and modules described above can be referred to the corresponding process descriptions in the aforementioned method embodiments, and will not be repeated here.

[0096] In the electronic device of this application embodiment, after the front-end design outputs hardware code, a processor is simulated using the hardware code. The simulated processor includes a debugging module. After sending debugging behavior information to the debugging module, if the processor enters the target debugging state, instruction stimuli are sent to the debugging module according to the test cases, causing the debugging module to control the processor's operation according to the instruction stimuli. After sending the instruction stimuli, the processor's execution result in response to the instruction stimuli can also be obtained, and the verification result of the debugging module can be obtained based on the instruction stimuli execution result. It is evident that after the front-end design is completed, the processor can be simulated using hardware code to verify the debugging module within the processor, without waiting for the integration of the interaction module within the processor. This allows for optimization of the debugging module during the front-end design phase, saving the time required for optimization and iteration of the debugging module, thereby improving the design and development efficiency of the processor.

[0097] Computer storage media

[0098] This application also provides a computer-readable storage medium storing instructions for causing a machine to execute the processor debugging module verification method as described herein. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer (or CPU or MPU) of the system or apparatus to read and execute the program code stored in the storage medium.

[0099] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of this application.

[0100] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0101] Computer program products

[0102] This application also provides a computer program product, including computer instructions that instruct a computing device to perform any corresponding operation in the above-described plurality of method embodiments.

[0103] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0104] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or a non-transitory machine-readable medium and will be stored in a local recording medium. Thus, the methods described herein can be processed by software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0105] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0106] The above embodiments are only used to illustrate the embodiments of this application, and are not intended to limit the embodiments of this application. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the embodiments of this application. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of this application, and the patent protection scope of the embodiments of this application should be defined by the claims.

Claims

1. A processor debug module verification method, comprising: sending debug behavior information to a debug module in a processor, wherein the debug behavior information is used to control the processor to enter a target debug state, the target debug state comprising a debug exception state or a debug mode state, the processor being simulated by hardware code output by a front-end design; if the processor enters the target debug state, sending an instruction stimulus to the debug module according to a test case, so that the debug module controls the processor to run according to the instruction stimulus, and an execution result of the processor is obtained; obtaining a verification result of the debug module according to the execution result; the method further comprises: obtaining a test case of another module in the processor as the test case used to test the debug module; the sending of the instruction stimulus to the debug module according to the test case comprises: reading a multiplexed instruction stimulus according to the test case; parsing the multiplexed instruction stimulus to obtain a parsing result; determining whether the behavior generated when the processor executes the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus according to the parsing result; if the behavior generated when the processor executes the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus, sending the multiplexed instruction stimulus as the instruction stimulus to the debug module; if the behavior generated when the processor executes the multiplexed instruction stimulus is not the same as the expected behavior of the multiplexed instruction stimulus, processing the multiplexed instruction stimulus to obtain the instruction stimulus whose behavior generated when the processor executes is the same as the expected behavior of the multiplexed instruction stimulus, and sending the instruction stimulus to the debug module.

2. The method of claim 1, wherein, the sending of the debug behavior information to the debug module in the processor comprises: sending the debug behavior information to the debug module in the processor when at least one of a fetch instruction executed by the processor, data accessed, and an access address hits a preset trigger; alternatively, sending the debug behavior information to the debug module in the processor randomly during the running of the processor.

3. The method of claim 1, wherein, the reading of the multiplexed instruction stimulus according to the test case comprises: reading the multiplexed instruction stimulus from a cache according to a target address recorded in the test case; alternatively, reading the multiplexed instruction stimulus matching an instruction text according to the instruction text recorded in the test case.

4. The method of any one of claims 1-3, wherein, the obtaining of the verification result of the debug module according to the execution result comprises: inputting the execution result into a pre-trained debug verification function model to obtain the verification result of the debug module output by the debug verification function model, wherein the execution result comprises at least one of a pipeline state of the processor, a processor permission, and an instruction execution result.

5. A processor debug module verification device, comprising: The debugging stimulus generation module is configured to send debugging behavior information to a debugging module in the processor, wherein the debugging behavior information is used to control the processor to enter a target debugging state, and the target debugging state includes a debugging exception state or a debugging mode state, and the processor is obtained by hardware code simulation output by front-end design; The instruction stimulus test module is configured to send instruction stimulus to the debugging module according to a test case after the processor enters the target debugging state, to control the processor to run according to the instruction stimulus, and to obtain an execution result of the processor; The processor debugging function verification module is configured to obtain a verification result of the debugging module according to the execution result. The debugging stimulus generation module is further configured to obtain a test case of another module in the processor, as the test case used to test the debugging module. The instruction stimulus test module is configured to read a multiplexed instruction stimulus according to the test case, to analyze the multiplexed instruction stimulus to obtain an analysis result, to determine whether a behavior generated when the processor executes the multiplexed instruction stimulus is the same as an expected behavior of the multiplexed instruction stimulus according to the analysis result, to send the multiplexed instruction stimulus to the debugging module as the instruction stimulus if the behavior generated when the processor executes the multiplexed instruction stimulus is the same as the expected behavior of the multiplexed instruction stimulus, and to process the multiplexed instruction stimulus to obtain the instruction stimulus whose behavior generated when the processor executes is the same as the expected behavior of the multiplexed instruction stimulus, and to send the instruction stimulus to the debugging module if the behavior generated when the processor executes the multiplexed instruction stimulus is not the same as the expected behavior of the multiplexed instruction stimulus.

6. An electronic device comprising: The processing unit, the memory, the communication interface and the communication bus complete communication among each other through the communication bus; The memory is configured to store at least one executable instruction, and the executable instruction causes the processing unit to perform operations corresponding to the processor debugging module verification method in any one of claims 1-4.

7. A computer storage medium having a computer program stored thereon, the program being executed by a processor to implement the processor debugging module verification method in any one of claims 1-4.

8. A computer program product comprising computer instructions, the computer instructions instructing a computing device to perform the processor debugging module verification method in any one of claims 1-4.

Images