Debugging function verification method, device and equipment for hardware acceleration simulation platform

Abstract

This invention discloses a method, apparatus, and device for verifying debugging functions on a hardware-accelerated simulation platform, relating to the field of simulation testing and verification. The method includes deploying the Design Under Test (DUT) and an Embedded Debug Execution Unit (MCU) on the EMU, loading and executing a debugging program on the MCU to generate a debugging command sequence; converting the debugging command sequence into timing drive signals corresponding to the DUT's test interface specification for debugging or tracing interaction with the DUT, obtaining response information, status information, and tracing information returned by the DUT; comparing the DUT's returned information with the target result, and continuing EMU debugging and verification based on the comparison result. This application enables automated debugging and verification without relying on an external physical debugger.

Description

Technical Field

[0001] This application relates to the field of simulation testing and verification, specifically to a method, apparatus, and equipment for verifying the debugging function of a hardware-accelerated simulation platform. Background Technology

[0002] Currently, there are two main methods for debugging and verifying EMU (Emulator, hardware accelerated simulation platform): (1) During the EMU simulation process, a connection is established with the DUT (Device Under Test) in the simulation platform by connecting an external real JTAG (Joint Test Action Group) simulator or other physical debugger, and the debugging function verification is completed by following the conventional chip debugging and tracing methods; (2) The behavior of the debugger is simulated outside or semi-external in the simulation environment by using DPI (the interface standard for direct interoperability between SV and C / C++), UVM (General Verification Methodology) drive or C Model (C Reference Model), and the debugger behavior is simulated outside or semi-external in the simulation environment, and the interface is used to interact with the DUT to realize the automated driving of some debugging protocols.

[0003] However, for the above scheme (1), a dedicated debugger device needs to be connected to the EMU platform, the system setup is complex, and it is highly dependent on external hardware, which is not conducive to automated deployment. The debugging process usually relies on manual real-time operation of the debugger, making it difficult to achieve batch execution, automatic verification, and automatic regression of the debugging sequence. The debugging behavior and the verification behavior are separated, making it difficult to form a stable closed-loop mechanism of "initiating debugging - collecting response - automatic judgment" within the simulation environment. For the above scheme (2), the debugger behavior is simulated outside or semi-externally in the simulation environment by using DPI, UVM drive, or C Model, and interacts with the DUT through the interface to realize the automated driving of some debugging protocols. Such schemes can replace physical debuggers to a certain extent, but they have insufficient adaptability and are difficult to stably map to the EMU execution environment, especially in specific simulation acceleration / cooperative execution modes (such as ICE mode).

[0004] Specifically, the existing EMU debugging and verification methods have the following problems: (1) Debugging and verification rely on external physical debuggers, resulting in low automation; (2) The debugging process requires real-time human intervention, making it difficult to form batch regression testing capabilities; (3) Simulation debugger schemes based on DPI, UVM, or CModel are not suitable for specific EMU operating modes, especially not suitable for ICE (In-Circuit Emulation) mode; (4) Existing debugging schemes are difficult to form a closed-loop verification mechanism integrating debugging initiation, response acquisition, and result judgment within the EMU. Summary of the Invention

[0005] This application provides a debugging function verification method, apparatus, and device for hardware accelerated simulation platforms, which can realize automated debugging verification without relying on external physical debuggers.

[0006] In a first aspect, embodiments of this application provide a method for verifying the debugging functions of a hardware-accelerated simulation platform, the method comprising: Deploy the Design Under Test (DUT) and the Embedded Debug Execution Unit (MCU) on the EMU, and load and execute the debug program on the MCU to generate a sequence of debug commands; The debugging command sequence is converted into timing drive signals corresponding to the DUT test interface specification to interact with the DUT for debugging or tracing, and to obtain the response information, status information and tracing information returned by the DUT. Compare the information returned by the DUT with the target result, and continue debugging and verifying the EMU based on the comparison results.

[0007] In conjunction with the first aspect, in one implementation method, The debugging program is used to call the debugging protocol primitive interface in the debugging protocol abstract software library to generate a debugging command sequence, and the debugging protocol abstract software library includes at least one debugging protocol primitive interface; The debug protocol primitive interface is used to implement at least one of the following operations: debug link initialization, reset control, debug mode entry, register read / write, memory read / write, breakpoint setting, single-step execution, run / pause control, trace enable, and trace data reading.

[0008] In conjunction with the first aspect, in one implementation, the step of converting the debug command sequence into timing drive signals corresponding to the DUT test interface specification for debugging or tracing interaction with the DUT, and obtaining the response information, status information, and tracing information returned by the DUT, specifically includes: The debug interface adapter module in the MCU receives the debug command sequence generated by the MCU and converts the debug command sequence into timing drive signals that conform to the debug interface specification of the DUT. Through the DUT's debugging interface, timing drive signals can be used to debug or trace with the DUT to obtain the response information, status information, and trace information returned by the DUT. The debugging interfaces of the DUT include JTAG and SWD.

[0009] In conjunction with the first aspect, in one implementation, the debug interface adaptation module in the MCU receives a debug command sequence generated by the MCU and converts the debug command sequence into timing drive signals conforming to the debug interface specification of the DUT, specifically including: The MCU's debug interface adapter module receives and parses the debug command sequence generated by the MCU, and decomposes the debug commands into hardware-executable operation steps; The MCU's debug interface adapter module converts the operation steps into a physical signal waveform sequence that conforms to the DUT's debug interface protocol in real time, based on the DUT's debug interface protocol, in order to drive the DUT's debug interface.

[0010] In conjunction with the first aspect, in one implementation method, The debugging interaction includes write operations, read operations, and control operations, which are initiated by the MCU. The tracking interaction is the active output of information by the DUT during normal operation. The specific process of the tracking interaction includes configuration, data generation, and data output.

[0011] In conjunction with the first aspect, in one implementation method, The response information is a reply to the read / write command issued by the MCU, including memory / register read values, register access confirmation, and version / status register information; The status information refers to the dynamically changing execution status of the DUT during the debugging interaction process, including running status, breakpoint / watchpoint hit information, exception / fault status, and debug event counter; The tracing information is information actively output by the DUT during normal operation, including program flow tracing, data flow tracing, and timestamp information during DUT execution.

[0012] In conjunction with the first aspect, in one implementation, the comparison between the DUT returned information and the target result, and the subsequent EMU debugging and verification based on the comparison result, specifically includes: The comparison engine is created to compare the information returned by the DUT with the target result, and the comparison result is obtained based on the consistency between the information returned by the DUT and the target result. Based on the comparison results, we will continue to debug and verify the EMU.

[0013] In conjunction with the first aspect, in one implementation, the step of continuing the EMU debugging and verification based on the comparison results specifically includes: Based on the comparison results: If the comparison result is successful, the next debugging command sequence is generated to continue debugging or tracing the interaction, and the comparison between the DUT returned information and the target result is continued to obtain the comparison result, so as to continue debugging and verifying the EMU. If the comparison result fails, and the reason for the failure is timeout or interface bus error, the current debugging command sequence is regenerated, debugging or tracing interaction is performed again, and the comparison between the DUT return information and the target result is performed again to obtain the comparison result. This process is repeated. If the comparison result still fails after a preset number of iterations, it is determined to be a persistent fault.

[0014] Secondly, embodiments of this application provide a debugging function verification device for a hardware-accelerated simulation platform, the debugging function verification device for a hardware-accelerated simulation platform comprising: The generation module is used to deploy the design under test (DUT) and the embedded debug execution unit (MCU) on the EMU, and load and execute debug programs on the MCU to generate a sequence of debug commands; The debugging module is used to convert the debugging command sequence into timing drive signals corresponding to the DUT test interface specification to perform debugging or tracing interaction with the DUT, and to obtain the response information, status information and tracing information returned by the DUT. The judgment module is used to compare the information returned by the DUT with the target result, and to continue the debugging and verification of the EMU based on the comparison result.

[0015] Thirdly, embodiments of this application provide a debugging function verification device for a hardware-accelerated simulation platform. The debugging function verification device for a hardware-accelerated simulation platform includes a processor, a memory, and a debugging function verification program for a hardware-accelerated simulation platform stored in the memory and executable by the processor. When the debugging function verification program for a hardware-accelerated simulation platform is executed by the processor, it implements the steps of the debugging function verification method for a hardware-accelerated simulation platform described above.

[0016] The beneficial effects of the technical solutions provided in this application include: (1) No dependence on external physical debugger: By deploying an embedded debug execution unit MCU inside the EMU environment, the MCU executes the debug program and directly participates in the debugging and tracing interaction of the DUT, without the need for an external real JTAG emulator or other physical debug equipment, which reduces the complexity of system construction and external hardware dependence; (2) Implement the programmable and automated debugging process: Abstract the debugging protocol behaviors such as JTAG and SWD into software interfaces, and form a sequence of debugging commands by program calls, replacing the manual operation of the debugger, so that the debugging function verification can be executed automatically, significantly improving the debugging verification efficiency; (3) Forming a closed-loop verification mechanism within the EMU: Integrating debugging initiation, response collection and result judgment functions within the EMU to realize a closed-loop mechanism of "debugging-response-verification", which can not only initiate debugging transactions, but also automatically verify the debugging results, thereby improving the integrity and consistency of verification; (4) Supports batch testing and automatic regression: It can organize multiple debugging test scenarios into a programmatic sequence for batch execution, and complete regression testing based on automatic comparison results, which significantly improves the coverage and repeatability of debugging and tracing function verification. (5) Applicable to specific ICE operation modes of EMU: Compared with solutions based on DPI, UVM or C Model, this application can better adapt to specific simulation operation modes such as ICE by deploying a runnable MCU model and supporting software library inside the EMU, thereby improving the practicality and stability of the solution. (6) Facilitates failure localization and problem analysis: When verification fails, this application can record relevant debugging commands, response data, status snapshots and trace information, thereby providing a basis for problem reproduction and root cause analysis and improving the engineering usability of debugging and verification. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the debugging function verification method for a hardware-accelerated simulation platform according to this application. Figure 2 This is a deployment diagram; Figure 3 This is a schematic diagram of the functional modules of the debugging function verification device for the hardware-accelerated simulation platform of this application; Figure 4 This is a schematic diagram of the hardware structure of the debugging function verification device for the hardware accelerated simulation platform of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0020] Firstly, this application provides a debugging function verification method for a hardware accelerated simulation platform. By deploying an embedded debugging execution unit within the EMU platform, and targeting the EMU's ICE working mode, the debugging protocol behavior is abstracted into a programmable software interface. The embedded debugging execution unit directly participates in the debugging and tracing interaction of the DUT, and automatically completes result acquisition, comparison, and verification within the EMU, thereby achieving automated debugging verification without relying on an external physical debugger. The EMU's ICE working mode refers to running the Design Under Test (DUT) on a hardware emulator and connecting it to a real external environment (such as PCIe, USB, DDR memory) for testing via interfaces such as SpeedBridge.

[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the debugging function verification method for a hardware-accelerated simulation platform according to this application. Figure 1 As shown, the debugging function verification method for hardware-accelerated simulation platforms includes: S1: Deploy the Design Under Test (DUT) and the Embedded Debug Execution Unit (MCU) on the EMU, and load and execute the debug program on the MCU to generate a sequence of debug commands; S2: Convert the debugging command sequence into timing drive signals corresponding to the DUT test interface specification to perform debugging or tracing interaction with the DUT, and obtain the response information, status information and tracing information returned by the DUT; S3: Compare the information returned by the DUT with the target result, and continue to debug and verify the EMU based on the comparison result.

[0022] In this application, the Design Under Test (DUT) and the Embedded Debug Execution Unit (MCU) are deployed within the EMU. This deployment method tightly couples the debug control logic with the DUT, reducing dependence on external test hosts. See also Figure 2 The diagram shown illustrates the arrangement of the DUT and MCU within the EMU.

[0023] In this application, the debugger is used to call the debug protocol primitive interface (i.e., interface function) in the debug protocol abstraction software library to generate a debug command sequence, and the debug protocol abstraction software library includes at least one debug protocol primitive interface. By calling the debug protocol primitive interface in the debug protocol abstraction software library multiple times, passing in different parameters (commands, data, etc.), debug commands with different functions are generated, thus obtaining the debug command sequence. That is, the debugger uses scripting, serialization, or function call methods to organize multiple debug protocol primitive interfaces to generate debug command sequences, thereby forming a batch-executable debug test scenario.

[0024] The debug protocol primitive interface is used to implement at least one of the following operations: debug link initialization, reset control, debug mode entry, register read / write, memory read / write, breakpoint setting, single-step execution, run / pause control, trace enable, and trace data reading.

[0025] Specifically, the debug protocol abstraction software library includes one or more debug protocol primitive interfaces, which are used to implement at least one of the following operations: debug link initialization, reset control, debug mode entry, register read / write, memory read / write, breakpoint setting, single-step execution, run / pause control, trace enable, and trace data reading.

[0026] Furthermore, in one embodiment, the debugging command sequence is converted into timing drive signals corresponding to the DUT test interface specification to interact with the DUT for debugging or tracing, and to obtain the response information, status information, and tracing information returned by the DUT, specifically including: S201: The debug interface adapter module in the MCU receives the debug command sequence generated by the MCU and converts the debug command sequence into timing drive signals that conform to the debug interface specification of the DUT; wherein, the debug interface of the DUT includes JTAG (Joint Test Action Group, an international standard test protocol) and SWD (Single Wire Debug, a serial debug interface). S202: Through the DUT's debugging interface, the timing drive signals are used to perform debugging or tracing interactions with the DUT to obtain the response information, status information, and tracing information returned by the DUT.

[0027] Specifically, the debug interface adapter module receives the debug command sequence generated by the MCU, converts it into timing drive signals conforming to the DUT debug interface specification, and then interacts with the DUT for debugging or tracing through the DUT debug interface. The debug interface adapter module is used for protocol conversion and timing adaptation.

[0028] Furthermore, in one embodiment, the debug interface adapter module in the MCU receives the debug command sequence generated by the MCU and converts the debug command sequence into timing drive signals conforming to the debug interface specification of the DUT, specifically including: S2011: The MCU's debug interface adapter module receives and parses the debug command sequence generated by the MCU, and decomposes the debug commands into hardware-executable operation steps; S2012: The MCU's debug interface adapter module converts the operation steps into a physical signal waveform sequence that conforms to the DUT's debug interface protocol in real time, according to the DUT's debug interface protocol, in order to drive the DUT's debug interface.

[0029] Specifically, the debug interface adapter module receives and parses commands generated by the debug program from the MCU. The debug interface adapter module decomposes these commands into hardware-executable operation steps. Based on the specific debug interface in the DUT, the debug interface adapter module converts the decomposed operation steps into physical signal waveform sequences that conform to the corresponding protocol in real time, and then drives the debug interface of the DUT.

[0030] Furthermore, in one embodiment, the debugging interaction includes write operations, read operations, and control operations, which are initiated by the MCU.

[0031] Specifically, the debug interaction follows a "request-response" model, initiated by the MCU. For write operations: after completing timing conversion, the debug interface adapter module drives the data to the DUT debug interface. The DUT samples at the clock edge and updates its internal registers. For read operations: after the debug interface adapter module sends the read command and address, the DUT prepares the data and returns it through the debug interface within a subsequent specific clock cycle. The debug interface adapter module is responsible for sampling and latching the data at the correct time. For control operations, such as halt, reset, or step, the debug interface adapter module converts them into a specific write sequence to the DUT debug control register.

[0032] Furthermore, in one embodiment, the tracking interaction is the DUT actively outputting information during normal operation, and the specific process of the tracking interaction includes configuration, data generation, and data output.

[0033] Specifically, the tracing interaction operates in a "broadcast" mode, with the DUT actively outputting information during normal operation. For configuration: the MCU first configures the internal tracing unit of the DUT through the DUT debug interface; for data generation: when the DUT is running, the tracing unit generates a compressed tracing packet upon the occurrence of a preset event (such as a function call or memory access); for data output: the generated tracing packet is output via a dedicated tracing port using high-speed serial or parallel signals. The tracing interface portion of the debug interface adapter module is responsible for continuously receiving, decoding, and buffering this data.

[0034] Furthermore, in one embodiment, the response information is a reply to the read / write command issued by the MCU, including memory / register read values ​​(such as 32-bit data 0x55AA55AA read from address 0x20000000), register access confirmation (such as an ACK response returned by the DUT, indicating that the write operation has been completed), version / status register information (such as the IDCODE of the debug interface, the device ID of the DUT); the status information is the execution status of the DUT that changes dynamically during the debugging interaction, including the running status (whether the core is running, suspended, sleeping, or reset), breakpoint / watchpoint hit information (the number of the hit breakpoint, the program counter value when it is triggered), exception / fault status (whether a bus error, illegal access, watchdog reset, or other exception has occurred, and the specific exception type code), and debug event counter (number of single-step executions, number of breakpoint hits, pause duration, etc.).

[0035] Trace information is information actively output by the DUT during normal operation, including program flow trace, data flow trace, and timestamp information during DUT execution.

[0036] Program flow tracing includes branch addresses and instruction execution counters. Branch addresses are the target addresses for each conditional jump, function call / return; instruction execution counters record the exact number of instructions executed, used for performance analysis.

[0037] Data flow tracing includes memory read / write addresses and data, and peripheral register accesses. Memory read / write addresses and data are records of accesses to specific memory addresses (such as each modification of a global variable). Peripheral register accesses are records of the configuration timing of the DUT's internal peripheral registers.

[0038] For timestamp information, each tracing packet is accompanied by a timestamp, which is used to calculate function execution time, interruption delay, etc.

[0039] Furthermore, in one embodiment, a comparison is performed between the DUT returned information and the target result. Based on the comparison result, the EMU debugging and verification are continued. Specifically, this includes: S301: The comparison engine created is used to compare the information returned by the DUT with the target result, and the comparison result is obtained based on the consistency between the information returned by the DUT and the target result; S302: Continue EMU debugging and verification based on the comparison results.

[0040] Specifically, a real-time, efficient data comparison engine is established to process the collected response information, status information, and tracking information, perform comparison operations to obtain comparison results, and then determine subsequent EMU debugging and verification based on the obtained comparison results, realizing batch testing and automatic regression testing. In one implementation, the comparison operation automatically compares the debug response returned by the DUT, status register values, program counter changes, abnormal states, tracking output content, and event timing.

[0041] Furthermore, in one embodiment, the EMU debugging and verification is continued based on the comparison results, specifically including: Based on the comparison results: If the comparison result is successful, the next debugging command sequence is generated to continue debugging or tracing the interaction, and the comparison between the DUT returned information and the target result is continued to obtain the comparison result, so as to continue debugging and verifying the EMU. If the comparison fails, and the reason for the failure is a timeout or interface bus error, the current debug command sequence is regenerated, and debugging or tracing interaction is performed again. The comparison between the DUT's returned information and the target result is performed again to obtain the comparison result. This process is repeated. If the comparison result still fails after a preset number of iterations (which can be 3), it is considered a persistent fault. An interface bus error refers to a failure of JTAG or SWD communication between the MCU and the DUT. This is a temporary communication failure caused by signal interference or timing issues, so several retries are required. If the problem persists after several retries, it can be considered a persistent fault. At this point, there may be a problem inside the DUT, requiring the intervention of general DUT debugging methods.

[0042] Specifically, the comparison result is obtained. If the comparison result is successful, the next debug command sequence is generated to continue the EMU debugging and verification. If the comparison result fails, and the failure reason is timeout or bus interface error, the same debug command sequence is regenerated, and debugging or tracing interaction is performed again. The comparison result is obtained again between the DUT returned information and the target result. If the comparison result is successful, the next debug command sequence is generated to continue the EMU debugging and verification. If the comparison result fails, and the failure reason is timeout or bus interface error, the same debug command sequence is regenerated again. This process is repeated. If the comparison result still fails after a preset number of iterations, it is determined to be a persistent fault, and the SoC simulation debugging method is needed to locate the problem in the DUT.

[0043] The debugging function verification method for hardware-accelerated simulation platforms in this application embodiment is as follows: (1) No dependence on external physical debugger: By deploying an embedded debug execution unit MCU inside the EMU environment, the MCU executes the debug program and directly participates in the debugging and tracing interaction of the DUT, without the need for an external real JTAG emulator or other physical debug equipment, which reduces the complexity of system construction and external hardware dependence; (2) Implement the programmable and automated debugging process: Abstract the debugging protocol behaviors such as JTAG and SWD into software interfaces, and form a sequence of debugging commands by program calls, replacing the manual operation of the debugger, so that the debugging function verification can be executed automatically, significantly improving the debugging verification efficiency; (3) Forming a closed-loop verification mechanism within the EMU: Integrating debugging initiation, response collection and result judgment functions within the EMU to realize a closed-loop mechanism of "debugging-response-verification", which can not only initiate debugging transactions, but also automatically verify the debugging results, thereby improving the integrity and consistency of verification; (4) Supports batch testing and automatic regression: It can organize multiple debugging test scenarios into a programmatic sequence for batch execution, and complete regression testing based on automatic comparison results, which significantly improves the coverage and repeatability of debugging and tracing function verification. (5) Applicable to specific ICE operation modes of EMU: Compared with solutions based on DPI, UVM or C Model, this application can better adapt to specific simulation operation modes such as ICE by deploying a runnable MCU model and supporting software library inside the EMU, thereby improving the practicality and stability of the solution. (6) Facilitates failure localization and problem analysis: When verification fails, this application can record relevant debugging commands, response data, status snapshots and trace information, thereby providing a basis for problem reproduction and root cause analysis and improving the engineering usability of debugging and verification.

[0044] Secondly, embodiments of this application also provide a debugging function verification device for hardware-accelerated simulation platforms.

[0045] In one embodiment, reference is made to Figure 3 , Figure 3 This is a functional module diagram of the debugging function verification device for the hardware-accelerated simulation platform described in this application. Figure 3 As shown, the debugging function verification device for the hardware accelerated simulation platform includes: a generation module, a debugging module, and a judgment module.

[0046] The generation module is used to deploy the Design Under Test (DUT) and the Embedded Debug Execution Unit (MCU) on the EMU, and load and execute the debug program on the MCU to generate a debug command sequence; the debugging module is used to convert the debug command sequence into timing drive signals corresponding to the DUT test interface specification to perform debugging or tracing interaction with the DUT, and obtain the response information, status information and tracing information returned by the DUT; the judgment module is used to compare the DUT return information with the target result, and continue to perform EMU debugging verification based on the comparison result.

[0047] Thirdly, this application provides a debugging function verification device for a hardware-accelerated simulation platform. The debugging function verification device for a hardware-accelerated simulation platform can be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0048] Reference Figure 4 , Figure 4 This is a schematic diagram of the hardware structure of the debugging function verification device for a hardware-accelerated simulation platform involved in the embodiments of this application. In this embodiment, the debugging function verification device for a hardware-accelerated simulation platform may include a processor, a memory, a communication interface, and a communication bus.

[0049] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0050] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces. These interfaces enable interconnection of internal components within the debugging verification device for the hardware-accelerated simulation platform, and also enable interconnection between the debugging verification device and other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0051] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0052] The processor can be a general-purpose processor, which can call a debugging function verification program for a hardware-accelerated simulation platform stored in memory and execute the debugging function verification method for a hardware-accelerated simulation platform provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the debugging function verification program for a hardware-accelerated simulation platform is called can be referred to in the various embodiments of the debugging function verification method for a hardware-accelerated simulation platform of this application, and will not be repeated here.

[0053] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0054] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0055] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0056] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0057] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0058] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0059] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for verifying debugging functions for a hardware-accelerated simulation platform, characterized in that, The debugging function verification method for the hardware-accelerated simulation platform includes: Deploy the Design Under Test (DUT) and the Embedded Debug Execution Unit (MCU) on the EMU, and load and execute the debug program on the MCU to generate a sequence of debug commands; The debugging command sequence is converted into timing drive signals corresponding to the DUT test interface specification to interact with the DUT for debugging or tracing, and to obtain the response information, status information and tracing information returned by the DUT. Compare the information returned by the DUT with the target result, and continue debugging and verifying the EMU based on the comparison results.

2. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 1, characterized in that: The debugging program is used to call the debugging protocol primitive interface in the debugging protocol abstract software library to generate a debugging command sequence, and the debugging protocol abstract software library includes at least one debugging protocol primitive interface; The debug protocol primitive interface is used to implement at least one of the following operations: debug link initialization, reset control, debug mode entry, register read / write, memory read / write, breakpoint setting, single-step execution, run / pause control, trace enable, and trace data reading.

3. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 1, characterized in that, The step of converting the debugging command sequence into timing drive signals corresponding to the DUT test interface specification for debugging or tracing interaction with the DUT, and obtaining the response information, status information, and tracing information returned by the DUT, specifically includes: The debug interface adapter module in the MCU receives the debug command sequence generated by the MCU and converts the debug command sequence into timing drive signals that conform to the debug interface specification of the DUT. Through the DUT's debugging interface, timing drive signals can be used to debug or trace with the DUT to obtain the response information, status information, and trace information returned by the DUT. The debugging interfaces of the DUT include JTAG and SWD.

4. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 3, characterized in that, The debug interface adapter module in the MCU receives the debug command sequence generated by the MCU and converts the debug command sequence into timing drive signals that conform to the debug interface specification of the DUT, specifically including: The MCU's debug interface adapter module receives and parses the debug command sequence generated by the MCU, and decomposes the debug commands into hardware-executable operation steps; The MCU's debug interface adapter module converts the operation steps into a physical signal waveform sequence that conforms to the DUT's debug interface protocol in real time, based on the DUT's debug interface protocol, in order to drive the DUT's debug interface.

5. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 3, characterized in that: The debugging interaction includes write operations, read operations, and control operations, which are initiated by the MCU. The tracking interaction is the active output of information by the DUT during normal operation. The specific process of the tracking interaction includes configuration, data generation, and data output.

6. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 3, characterized in that: The response information is a reply to the read / write command issued by the MCU, including memory / register read values, register access confirmation, and version / status register information; The status information refers to the dynamically changing execution status of the DUT during the debugging interaction process, including running status, breakpoint / watchpoint hit information, exception / fault status, and debug event counter; The tracing information is information actively output by the DUT during normal operation, including program flow tracing, data flow tracing, and timestamp information during DUT execution.

7. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 1, characterized in that, The comparison between the DUT returned information and the target result, and the subsequent debugging and verification of the EMU based on the comparison results, specifically includes: The comparison engine is created to compare the information returned by the DUT with the target result, and the comparison result is obtained based on the consistency between the information returned by the DUT and the target result. Based on the comparison results, we will continue to debug and verify the EMU.

8. The debugging function verification method for a hardware-accelerated simulation platform as described in claim 7, characterized in that, The step of continuing the EMU debugging and verification based on the comparison results specifically includes: Based on the comparison results: If the comparison result is successful, the next debugging command sequence is generated to continue debugging or tracing the interaction, and the comparison between the DUT returned information and the target result is continued to obtain the comparison result, so as to continue debugging and verifying the EMU. If the comparison result fails, and the reason for the failure is timeout or interface bus error, the current debugging command sequence is regenerated, debugging or tracing interaction is performed again, and the comparison between the DUT return information and the target result is performed again to obtain the comparison result. This process is repeated. If the comparison result still fails after a preset number of iterations, it is determined to be a persistent fault.

9. A debugging function verification device for a hardware-accelerated simulation platform, characterized in that, The debugging function verification device for the hardware-accelerated simulation platform includes: The generation module is used to deploy the design under test (DUT) and the embedded debug execution unit (MCU) on the EMU, and load and execute debug programs on the MCU to generate a sequence of debug commands; The debugging module is used to convert the debugging command sequence into timing drive signals corresponding to the DUT test interface specification to perform debugging or tracing interaction with the DUT, and to obtain the response information, status information and tracing information returned by the DUT. The judgment module is used to compare the information returned by the DUT with the target result, and to continue the debugging and verification of the EMU based on the comparison result.

10. A debugging function verification device for a hardware-accelerated simulation platform, characterized in that, The debugging function verification device for the hardware-accelerated simulation platform includes a processor, a memory, and a debugging function verification program for the hardware-accelerated simulation platform stored in the memory and executable by the processor. When the debugging function verification program for the hardware-accelerated simulation platform is executed by the processor, it implements the steps of the debugging function verification method for the hardware-accelerated simulation platform as described in any one of claims 1 to 8.

Images