A cross-level unified verification system and method for a RISC-V processor debugging module

Abstract

The application discloses a cross-level unified verification system and method for a RISC-V processor debugging module. The system comprises: a unified debugging semantic API module, which provides debugging semantic API decoupled from a bottom protocol and a verification level; a semantic-level random generation module, which generates a random debugging sequence based on the API; a hierarchical verification strategy control module, which determines a verification strategy according to the verification level; a cross-level transaction adaptation module, which adaptively converts unified debugging transactions into APB, JTAG and CJTAG driving transactions; and a hierarchical automatic checking module, which automatically selects built-in checking rules for comparison and checking according to the verification level. The application realizes high reuse of test cases in module-level, subsystem-level and system-level verification, supports non-aware switching of different protocols in the compilation period, has a built-in hierarchical automatic checking mechanism, can significantly reduce verification development workload, accelerate functional coverage convergence speed and improve engineering adaptation efficiency.

Description

Technical Field

[0001] This invention relates to the field of processor technology, and in particular to a cross-level unified verification system and method for RISC-V processor debugging modules. Background Technology

[0002] Verification of the RISC-V processor debug module (DM) is typically divided into three levels: module level, subsystem level, and system level. At the module level, the DM's internal registers are accessed directly via the APB bus. At the subsystem and system levels, access to the DM is achieved indirectly through the JTAG / CJTAG protocol, which is converted into APB transactions by the TAP controller.

[0003] In existing technologies, verification personnel generally use commercial protocol verification IPs (such as Synopsys Verification IP for RISC-V and Cadence RISC-V Debug VIP) to provide the underlying drivers, and then encapsulate debugging logic, develop test cases, and build reference models on this basis.

[0004] However, this existing technology has the following drawbacks:

[0005] First, the lack of a unified debugging semantic abstraction leads to strong coupling between test cases and underlying access paths and communication protocols. Test cases written at the module level cannot be directly reused at the subsystem or system level. Switching verification levels requires refactoring a large amount of code, resulting in low development efficiency.

[0006] Second, the lack of a random access API for dedicated registers of the RISC-V debug module and a complete debug process API makes it difficult to efficiently cover legal and illegal register access scenarios, resulting in slow convergence of functional coverage.

[0007] Third, there is no built-in hierarchical automatic verification mechanism. Different verification levels require repeated development of verification logic, making it difficult to clearly distinguish the boundary between DM's own functional verification and CPU debugging process verification, which can easily lead to missed tests and make it difficult to locate problems.

[0008] Fourth, when switching between APB, JTAG and CJTAG interfaces, it is necessary to manually modify the component instantiation and test case code in the verification environment, which cannot achieve seamless switching and results in low efficiency of engineering adaptation. Summary of the Invention

[0009] Based on this, it is necessary to provide a cross-level unified verification system and method for RISC-V processor debugging modules to address the existing technical problems. This verification system and method can automatically adapt to layered verification, eliminating the need for repeated development of inspection logic, reducing the missed detection rate, and enabling faster localization.

[0010] To address the problems in the existing technology, the present invention adopts the following technical solution:

[0011] A cross-level unified verification system for RISC-V processor debug modules includes:

[0012] The Unified Debug Semantic API module provides a set of debugging semantic APIs decoupled from the underlying communication protocol and verification layer. The debugging semantic APIs include at least reset operations, register read / write operations, debug mode control operations, abstract instruction execution operations, and breakpoint configuration and monitoring operations.

[0013] A semantic-level random generation module is used to generate random debugging sequences based on the debugging semantic API and according to the preset verification level and debugging module status.

[0014] The hierarchical verification strategy control module is used to determine the corresponding verification strategy and objectives according to different verification levels, including module level, subsystem level and system level.

[0015] A cross-level transaction adaptation module is used to adaptively convert the unified debugging transaction issued by the debugging semantic API into a driving transaction of the corresponding underlying communication protocol according to the macro definition. The underlying communication protocol includes APB, JTAG and CJTAG.

[0016] The hierarchical automatic verification module is used to automatically select at least one set of built-in verification rules according to the verification level, and to automatically compare and verify the behavior of the debugging module.

[0017] Preferably, the debugging semantic API provided by the unified debugging semantic API module includes at least one of the following categories:

[0018] Register access APIs, including dm_dereset(), dm_read(), dm_write(), and acc_dm_reg(), are used to implement de-reset, register reading, writing, and random access of the debug module. Among them, acc_dm_reg() performs random read and write access to the control registers and status registers inside the debug module, supports access to both legal and illegal addresses, and is used to verify the address decoding, access permissions, and error response mechanism of the debug module.

[0019] The debug state control API, including enter_dbg_mode() and quit_dbg_mode(), is used to control the processor to enter or exit debug state.

[0020] Abstract instruction execution class API, including cmd_write_gpr(), cmd_read_gpr(), cmd_write_

[0021] csr(), cmd_read_csr(), cmd_store_mem(), cmd_load_mem(), and pbuff_cmd_issue() are used to issue and execute read / write operations on general-purpose registers, read / write control status registers, and read / write memory through the program buffer of the debug module.

[0022] The debugging and control APIs include `read_idcode()`, `trigger_ini()`, `trigger_mon_close()`, `acc_mem()`, and `acc_reg()`, used to read and verify device identifier codes, configure breakpoints, monitor and close breakpoints, perform random memory read / write comparisons, and perform random general-purpose register and control status register read / write comparisons. Specifically, `acc_reg()` performs random read / write accesses to the processor core's general-purpose registers (GPRs) and control status registers (CSRs) and automatically compares the read / write results. Internally, this is achieved by calling `cmd_write_gpr()`, `cmd_read_gpr()`, `cmd_write_csr()`, and `cmd_read_csr()`.

[0023] Preferably, the verification strategy configured by the hierarchical verification strategy control module includes:

[0024] The module-level verification strategy is used to test the legal and illegal access requests of all registers of the debugging module under different states, and to verify the registers and functions of the debugging module.

[0025] Subsystem-level verification strategies are used to reuse module-level verification test cases and automatically verify the link from the test access port to the debug module and the behavior of the debug module.

[0026] The system-level verification strategy is used to reuse other use cases other than illegal random access use cases at the module level and / or subsystem level, execute the complete debugging process, and verify the status of the processor core and related registers. At this time, the general-purpose registers and CSR are implemented by accessing the internal registers of the debugging module through acc_reg(). All debugging processes are based on access to the internal registers of the debugging module.

[0027] Preferably, the cross-level transaction adaptation module adopts an adaptive architecture that separates unified debugging transactions from underlying protocol drivers. It automatically selects APB, JTAG, and CJTAG drivers based on the compilation configuration and automatically completes transaction conversion, timing adaptation, and address mapping. The interface protocol switching is controlled only by the compiler macros, and the unified API, test cases, random stimulus, and verification logic do not need to be modified.

[0028] Preferably, the built-in verification rules of the hierarchical automatic verification module include:

[0029] The first verification rule is used to verify the register values, state transitions, and instruction issuance of the debugging module. This rule is applicable to module-level, subsystem-level, and system-level verification.

[0030] The second verification rule is used to verify the link from the test access port to the debug module. This rule is applicable to subsystem-level and system-level verification.

[0031] The third verification rule is used to verify the correctness of the processor's debugging process, including entering / exiting debug mode, instruction issuance, memory access, register access, breakpoint triggering, single-step execution, and instruction behavior in debug mode. This rule is applicable to system-level verification.

[0032] As a preferred implementation, the three sets of verification rules are implemented independently of each other. The corresponding verification logic can be automatically selected and instantiated at compile time according to the verification level macro VERIF_LEVEL: at the module level, only the first rule is instantiated; at the subsystem level, both the first and second rules are instantiated; and at the system level, the first, second, and third rules are instantiated simultaneously.

[0033] A cross-level unified verification method for RISC-V processor debug modules includes:

[0034] The compiler macros are set according to the design module under test, and the verification level and interface protocol are adaptively switched. The verification level includes module level, subsystem level and system level, and the interface protocol includes APB, JTAG and CJTAG.

[0035] Based on the target verification level, a test stimulus sequence independent of the underlying protocol is generated through a set of unified debugging semantic APIs that are decoupled from the underlying communication protocol and verification level.

[0036] Based on the configured compiler macros, the cross-level transaction adaptation module will adaptively convert the sequence generated by the unified debugging semantic API into the stimulus sequence of the corresponding interface protocol.

[0037] According to the target verification level, the corresponding verification strategy is executed. The module-level strategy is to test the legal and illegal access of the debug module registers. The subsystem-level strategy is to reuse the module-level test cases and verify the conversion link from the test access port to the debug module. The system-level strategy is to reuse test cases other than illegal random access and execute the complete debugging process.

[0038] The built-in verification rules are automatically selected based on the verification strategy to automatically compare and verify the behavior of the debugging module.

[0039] Preferably, the target verification level is at the module level, and the method includes:

[0040] Configure compiler macros to select the APB interface driver and configure the verification level to module level;

[0041] Call the dm_dereset() API to complete the debug module de-reset;

[0042] Call the acc_dm_reg() API to perform random read and write access to legal and illegal addresses in the debug module registers;

[0043] Call the enter_dbg_mode() and quit_dbg_mode() APIs to control the processor to enter and exit debug mode and check the debug module request status;

[0044] Call the abstract instruction execution class API to check if the instruction has been issued correctly;

[0045] The cross-level transaction adaptation module adaptively converts the sequences generated by the unified debugging semantic API into test stimulus sequences for the APB.

[0046] The hierarchical automatic verification module calls the first verification rule to verify the correctness of the register values, state transitions, and instruction issuance of the debugging module.

[0047] Preferably, the target verification level is at the subsystem level, and the method includes:

[0048] Configure compiler macros to select the JTAG / CJTAG interface driver and configure the verification level to subsystem level;

[0049] Reuse the entire API test stimulus sequence for module-level verification;

[0050] The cross-level transaction adaptation module adaptively converts API test stimulus sequences into JTAG / CJTAG test stimulus sequences.

[0051] The hierarchical automatic verification module simultaneously calls the first verification rule and the second verification rule to verify the internal behavior of the debugging module and test the link from the access port to the debugging module, respectively.

[0052] Preferably, the target verification level is system-level, and the method includes:

[0053] Configure compiler macros to select the JTAG / CJTAG interface driver and configure the verification level to system level;

[0054] Reuse the API test stimulus sequence in module-level verification, excluding the illegal random access to register test cases;

[0055] Call the pbuff_cmd_issue() API to initialize the program buffer and issue instructions, and perform instruction verification.

[0056] Call the enter_dbg_mode() API to put the processor into debug mode;

[0057] Call the read_idcode() API to read and verify the device identification code;

[0058] Call the acc_reg() and acc_mem() APIs to perform random access and automatic comparison of registers and memory;

[0059] Configure breakpoints by calling the trigger_ini() API, and resume processor operation by calling the quit_dbg_mode() API;

[0060] After a breakpoint is triggered, the trigger_mon_close() API is called to automatically monitor and check whether the processor has entered debug mode, whether the debug reason register is correct, and whether the breakpoint program counter is correct.

[0061] The cross-level transaction adaptation module adaptively converts API test stimulus sequences into JTAG / CJTAG test stimulus sequences.

[0062] The hierarchical automatic verification module calls the first, second, and third verification rules to verify the processor's debug mode entry / exit, breakpoint triggering correctness, and instruction execution results.

[0063] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the cross-level unified verification method.

[0064] The beneficial effects of this invention are:

[0065] First, by unifying the debugging semantic API architecture, interface and hierarchical differences are masked, enabling high reuse of test cases across hierarchical levels. Module-level and subsystem-level test case reuse rates reach 100%, and system-level reuse includes all test cases except for random read / write operations. Actual testing shows that the overall development workload is reduced by approximately 70%.

[0066] Second, it provides a dedicated API for the RISC-V Debug standard, covering DM register access and the complete debugging process, and supports legal and illegal register access coverage in all DM states. According to actual tests, the functional coverage convergence speed is accelerated by about 80%.

[0067] Third, it has a built-in hierarchical automatic verification mechanism that automatically switches verification rules according to the verification level, eliminating the need to repeatedly develop inspection logic, effectively reducing the missed detection rate, and making problem location faster.

[0068] Fourth, it adopts a unified transaction plus pluggable protocol compile-time adaptive interface architecture to achieve seamless switching of APB, JTAG and CJTAG across the entire stack. Interface switching does not require modification of any upper-layer logic. According to actual tests, the efficiency of engineering adaptation is improved by about 100%. Attached Figure Description

[0069] Figure 1 System structure block diagram;

[0070] Figure 2 Structure diagram of the module for cross-level transaction adaptation;

[0071] Figure 3 This is a flowchart of the method.

[0072] Figure 4 This is a flowchart for module-level verification.

[0073] Figure 5 This is a flowchart for system-level verification. Detailed Implementation

[0074] To further understand the features, technical means, and specific objectives and functions achieved by the present invention, the present invention will be described in further detail below with reference to the accompanying drawings and specific embodiments.

[0075] This invention provides a cross-level unified verification system for RISC-V processor debugging modules, aiming to achieve the following objectives:

[0076] The same set of use cases is reused at the module and subsystem levels, focusing on the legal and illegal random access of registers under different DM states, and checking the DM register status and instruction issuance.

[0077] The system reuses all test cases except random read / write, executes the complete debugging process, and supports debugging operations such as instruction issuance, memory access, register access, breakpoint configuration, and single-stepping. It verifies whether the processor core has entered debug mode correctly and whether the relevant registers have been updated correctly.

[0078] Implement high-level reuse of use cases at the module, subsystem, and system levels.

[0079] It supports compile-time adaptive switching between APB, JTAG, and CJTAG interfaces to adapt to different design modules under test.

[0080] Built-in hierarchical automatic verification mechanism.

[0081] like Figures 1-3 As shown, this system is implemented based on the Universal Verification Methodology (UVM) architecture, which includes five core modules, adaptively adapts to different verification levels, and completely decouples test cases from underlying interface protocols.

[0082] I. Unified debugging of semantic API module

[0083] This module is divided into two sub-layers:

[0084] (1) Low-level primitive function layer: Provides the most basic register read and write operations, and is the boundary of protocol switching. Includes:

[0085] dm_read(addr, rdata): Reads the register at the specified address in the debug module.

[0086] dm_write(addr, wdata): Writes to the register at the specified address in the debug module.

[0087] (2) High-level debugging semantic API layer: Based on the underlying primitive functions, it provides debugging operations for verification scenarios. Specifically, it includes:

[0088] dm_dereset(): De-resets the DM and queries its reset status;

[0089] acc_dm_reg(): The control registers and status registers inside the DM perform random read and write access, supporting both legal and illegal address access, and are used to verify the address decoding, access permissions and error response mechanism of the debugging module;

[0090] enter_dbg_mode(): Triggers a Halt request, putting the CPU into debug mode;

[0091] quit_dbg_mode(): Triggers a Resume request, causing the CPU to exit debug mode;

[0092] read_idcode(): Reads and verifies the IDCODE;

[0093] cmd_write_gpr(addr, data): Abstract instruction to write to a general-purpose register;

[0094] cmd_read_gpr(addr): Abstract instruction to read general-purpose registers;

[0095] cmd_write_csr(addr, data): Abstract instruction to write to the control status register;

[0096] cmd_read_csr(addr): Abstract instruction to read the control status register;

[0097] cmd_store_mem(addr, data): Abstract instruction to write to memory;

[0098] cmd_load_mem(addr): Abstract instruction to read memory;

[0099] pbuff_cmd_issue(): Initializes the program buffer and issues instructions from it;

[0100] acc_mem(): Random memory read / write with automatic comparison of read / write data;

[0101] acc_reg(): Performs random read and write access to the processor core's general purpose registers (GPR) and control status registers (CSR) and automatically compares the read and write results. Internally, it is implemented by calling cmd_write_gpr(), cmd_read_gpr(), cmd_write_csr(), and cmd_read_csr().

[0102] trigger_ini(): Configures breakpoints;

[0103] trigger_mon_close(): Enables breakpoint monitoring and closing.

[0104] II. Semantic-level random generation module

[0105] At the module and subsystem levels, this module calls the aforementioned APIs based on different DM states to generate random debugging sequences and function sequences, focusing on register read / write, state transitions, and illegal access under different DM states. The random logic is independent of the underlying protocol and verification layer.

[0106] At the system level, this module calls the API to test legitimate debugging requests and executes the complete debugging process.

[0107] III. Hierarchical Verification Strategy Control Module

[0108] This module determines the corresponding verification strategy based on the verification level:

[0109] Module-level strategy: Test requests to all registers under different DM states, including valid and invalid requests, and verify the DM registers and functions.

[0110] Subsystem-level strategy: Reuse module-level test cases to automatically verify the consistency between the test access port (TAP) and DM behavior.

[0111] System-level strategy: Test legitimate debug requests, execute the complete debug process, and verify the processor core status and related registers. At this point, the `command` register within the debug module is accessed via `Acc_reg` to implement general-purpose registers and CSRs. All debugging processes are based on access to registers within the debug module.

[0112] IV. Cross-level Transaction Adaptation Module

[0113] This module adopts an adaptive architecture that separates unified debugging transactions from underlying protocol drivers. It automatically selects the APB, JTAG, and CJTAG drivers based on the compilation configuration and automatically completes transaction conversion, timing adaptation, and address mapping.

[0114] The interface protocol switching is controlled solely by compiler macros. No modifications are required to the unified API, test cases, random stimuli, or verification logic, achieving seamless switching across the entire stack during compilation.

[0115] In a preferred implementation of the present invention, the cross-level transaction adaptation module employs a compile-time conditional compilation mechanism to automatically select the underlying driver function based on macro definitions. Specifically:

[0116] This module provides two core low-level primitive functions: `dm_read(addr, rdata)` and `dm_write(addr, wdata)`, used for reading and writing operations to the module's registers, respectively. Internally, these functions use conditional compilation directives such as `#ifdef`, `#elif`, and `#endif` to call the corresponding low-level protocol driver functions based on macros defined at compile time (such as APB, JTAG, and CJTAG).

[0117] 1. If the APB macro is defined, then call apb_dm_read() / apb_dm_write();

[0118] 2. If a JTAG macro is defined, then jtag_dm_read() / jtag_dm_write() will be called;

[0119] 3. If the CJTAG macro is defined, then cjtag_dm_read() / cjtag_dm_write() will be called.

[0120] Building upon this foundation, all high-level debugging APIs provided by the unified debugging semantic API module (including but not limited to dm_dereset(), enter_dbg_mode(), cmd_write_gpr(), etc.) are implemented based on the two underlying primitives dm_read() and dm_write(). Therefore, when compiler macros are switched, the underlying protocol drivers of all high-level APIs automatically complete the global switch, while the API call layer, test case layer, random stimulus layer, and verification logic layer require no modification.

[0121] This two-layer architecture of "unified high-level API calls + conditional compilation of low-level primitives" achieves the "seamless switching of the entire stack during compilation" effect described in this invention.

[0122] V. Hierarchical Automatic Verification Module

[0123] This module has three built-in independent verification rules, which are automatically selected based on the verification level:

[0124] Rule 1: Verify DM register values, state transitions, and instruction issuance. Applicable to module level, subsystem level, and system level.

[0125] Rule 2: Verify the link from TAP to DM. Applicable to subsystem and system levels.

[0126] Rule 3: Verify the debugging process, including entering / exiting debug mode, instruction issuance, memory access, register access, breakpoint triggering, and single-stepping, as well as instruction behavior in debug mode. Applicable at the system level.

[0127] The three sets of verification rules are implemented independently of each other. The corresponding verification logic can be automatically selected and instantiated at compile time according to the verification level macro VERIF_LEVEL: at the module level, only the first rule is instantiated; at the subsystem level, both the first and second rules are instantiated; and at the system level, the first, second, and third rules are instantiated simultaneously.

[0128] Example 1: DM Module-Level Verification Based on APB Interface

[0129] This embodiment provides a specific implementation method for verifying and debugging a module at the module level via the APB interface using the system of the present invention. The verification objective is to verify the correctness of the DM module's register access function and state transitions under the APB interface.

[0130] See Figure 4 This embodiment includes the following steps S401 to S406:

[0131] Step S401: Configure the compiler macros, instantiate the module-level DUT, select the APB interface driver, and configure the verification level to module level (VERIF_LEVEL=MODULE).

[0132] Step S402: Call the dm_dereset() API to complete the DM dereset.

[0133] Step S403: Call the acc_dm_reg() API to perform legal and illegal random access to the DM register.

[0134] Step S404: Call the enter_dbg_mode() and quit_dbg_mode() APIs to control the processor to enter and exit debug mode and check the DM request status.

[0135] Step S405: Call the abstract instruction execution class API (such as cmd_write_gpr(), cmd_read_gpr(), etc.) to check whether the instruction is issued correctly.

[0136] Step S406: The hierarchical automatic verification module automatically calls the first verification rule to check the correctness of the DM register value, status, and instruction issuance.

[0137] Implementation Results: Through this embodiment, DM register access coverage reached 100%, state transition coverage reached 100%, and state and register cross-access coverage reached 100%. During the verification process, 15 design flaws in the DM module were successfully discovered.

[0138] Taking a single DM register write operation during module-level verification as an example, the complete call chain is as follows:

[0139] / / 1. Test case layer calls unified API

[0140] dm_write(0x10, 0x1234);

[0141] / / 2. dm_write() selects the driver based on compiler macros

[0142] #ifdef APB

[0143] apb_dm_write(addr, wdata);

[0144] #elif defined(JTAG)

[0145] jtag_dm_write(addr, wdata);

[0146] #elif defined(CJTAG)

[0147] cjtag_dm_write(addr, wdata);

[0148] #endif

[0149] / / 3. After the underlying driver completes the timing conversion, it drives the DUT interface.

[0150] During this call, the source code of the test case layer does not need to be modified in any way, and the changes in the underlying protocol are transparent to the test case layer.

[0151] Example 2: Subsystem-level CJTAG interface design-under-test module verification

[0152] This embodiment provides a specific implementation method for verifying and debugging modules at the subsystem level via the CJTAG interface using the system of the present invention. The verification objective is to verify the link from the TAP controller to the DM and the consistency of the DM's behavior under the CJTAG interface.

[0153] This embodiment includes the following steps:

[0154] Step S501: Configure the compiler macros, define V_CJTAG to select the CJTAG interface driver, and configure the verification level to subsystem level (VERIF_LEVEL=SUBSYSTEM).

[0155] Step S502: Fully reuse all test stimulus sequences from Example 1 without any modifications.

[0156] Step S503: The hierarchical automatic verification module simultaneously calls the first verification rule and the second verification rule to automatically verify the TAP to DM conversion link and DM behavior.

[0157] Implementation Results: Through this embodiment, the TAP-DM conversion link coverage reached 100%, the CJTAG protocol coverage reached 100%, and the DM status and register cross-access coverage reached 100%. Five design flaws in the TAP-DM link were successfully identified.

[0158] Example 3: Verification of the Complete System-Level JTAG Debugging Process

[0159] This embodiment provides a specific implementation method for verifying the complete debugging process at the system level via the JTAG interface using the system of the present invention. The verification objective is to verify the complete processor debugging process, including breakpoint configuration, single-step execution, memory and register access, etc.

[0160] See Figure 5 This embodiment includes the following steps S601 to S609:

[0161] Step S601: Configure the compiler macros, do not define V_CJTAG to select the JTAG interface driver, and configure the verification level to system level (VERIF_LEVEL=SYSTEM).

[0162] Step S602: Reuse all test stimulus sequences in Example 1 except for the illegal random access to register test case.

[0163] Step S603: Call the pbuff_cmd_issue() API to initialize the program buffer and issue instructions, and perform instruction verification.

[0164] Step S604: Call the enter_dbg_mode() API to put the CPU into debug mode.

[0165] Step S605: Call the read_idcode() API to read and verify the IDCODE.

[0166] Step S606: Call the acc_reg() and acc_mem() APIs to complete random access and automatic comparison of registers and memory.

[0167] Step S607: Call the trigger_ini() API to configure breakpoints, and call the quit_dbg_mode() API to resume CPU operation.

[0168] Step S608: After triggering the breakpoint, call the trigger_mon_close() API to automatically monitor and check: whether the processor core has entered debug mode, whether the value of the debug reason register dcsr.cause is 2 (indicating that the breakpoint has been triggered), and whether the breakpoint program counter dpc is correct.

[0169] Step S609: The correctness of instruction behavior and CPU internal state is guaranteed by a reference model (such as the C model).

[0170] Implementation Results: Through this embodiment, the debugging process coverage reached 100%, and the breakpoint trigger coverage reached 100%. 26 system-level debugging process design flaws were successfully discovered.

[0171] As a specific implementation of the present invention, the compiler macro can be defined as follows:

[0172] VERIF_LEVEL: Values ​​include MODULE (module level), SUBSYSTEM (subsystem level), and SYSTEM (system level).

[0173] BUS_IF: Values ​​APB, JTAG, and CJTAG are used to control the selection of the underlying driver for cross-level transaction adaptation modules.

[0174] These two can be combined arbitrarily. For example, module-level verification is usually combined with APB, while subsystem-level and system-level verification are usually combined with JTAG or CJTAG. During compilation, the corresponding BUS_IF macro is defined according to the actual interface type of the module under test, and the VERIF_LEVEL macro is defined to select the verification strategy and verification rules.

[0175] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A cross-level unified verification system for RISC-V processor debug modules, characterized in that, include: The Unified Debug Semantic API module provides a set of debugging semantic APIs decoupled from the underlying communication protocol and verification layer. The debugging semantic APIs include at least reset operations, register read / write operations, debug mode control operations, abstract instruction execution operations, and breakpoint configuration and monitoring operations. A semantic-level random generation module is used to generate random debugging sequences based on the debugging semantic API and according to the preset verification level and debugging module status. The hierarchical verification strategy control module is used to determine the corresponding verification strategy and objectives according to different verification levels, including module level, subsystem level and system level. A cross-level transaction adaptation module is used to adaptively convert the unified debugging transactions issued by the debugging semantic API into driving transactions of the corresponding underlying communication protocols during the compilation phase according to macro definitions. The underlying communication protocols include APB, JTAG and CJTAG. The hierarchical automatic verification module is used to automatically select at least one set of built-in verification rules according to the verification level, and to automatically compare and verify the behavior of the debugging module.

2. The system according to claim 1, characterized in that, The debugging semantic API provided by the unified debugging semantic API module includes at least one of the following categories: Register access APIs, including dm_dereset(), dm_read(), dm_write(), and acc_dm_reg(), are used to implement de-reset, register reading, writing, and random access of the debug module. Among them, acc_dm_reg() performs random read and write access to the control registers and status registers inside the debug module, supports access to both legal and illegal addresses, and is used to verify the address decoding, access permissions, and error response mechanism of the debug module. The debug state control API, including enter_dbg_mode() and quit_dbg_mode(), is used to control the processor to enter or exit debug state. The abstract instruction execution class API, including cmd_write_gpr(), cmd_read_gpr(), cmd_write_csr(), cmd_read_csr(), cmd_store_mem(), cmd_load_mem(), and pbuff_cmd_issue(), is used to issue and execute operations such as reading and writing general-purpose registers, reading and writing control status registers, and reading and writing memory through the abstract instructions or program buffer of the debug module. The debugging and control APIs include read_idcode(), trigger_ini(), trigger_mon_close(), acc_mem(), and acc_reg(), which are used to read and verify device identifier codes, configure breakpoints, monitor and close breakpoints, perform random memory read / write comparisons, and perform random general-purpose register and control status register read / write comparisons. Among them, acc_reg() performs random read / write accesses to the processor core's general-purpose registers (GPR) and control status registers (CSR) and automatically compares the read / write results. Internally, it is implemented by calling cmd_write_gpr(), cmd_read_gpr(), cmd_write_csr(), and cmd_read_csr().

3. The system according to claim 1, characterized in that, The verification strategies configured by the hierarchical verification strategy control module include: The module-level verification strategy is used to test the legal and illegal access requests of all registers of the debugging module under different states, and to verify the registers and functions of the debugging module. Subsystem-level verification strategies are used to reuse module-level verification test cases and automatically verify the conversion link from the test access port to the debug module and the behavior of the debug module. The system-level verification strategy is used to reuse other use cases other than illegal random access use cases at the module level and / or subsystem level, execute the complete debugging process, and verify the status of the processor core and related registers. At this time, the general-purpose registers and CSR are implemented by accessing the registers (commands) inside the debugging module through Acc_reg.

4. The system according to claim 1, characterized in that, The cross-level transaction adaptation module adopts an adaptive architecture that separates unified debugging transactions from underlying protocol drivers. It automatically selects APB, JTAG, and CJTAG drivers based on the compilation configuration and automatically completes transaction conversion, timing adaptation, and address mapping. Interface protocol switching is controlled only by compilation macros, and the unified API, test cases, random stimulus, and verification logic do not need to be modified.

5. The system according to claim 1, characterized in that, The built-in verification rules of the hierarchical automatic verification module include: The first verification rule is used to verify the register values, state transitions, and instruction issuance of the debugging module. This rule is applicable to module-level, subsystem-level, and system-level verification. The second verification rule is used to verify the conversion link from the test access port to the debug module. This rule is applicable to subsystem-level and system-level verification. The third verification rule is used to verify the correctness of the processor's debugging process, including entering / exiting debug mode, instruction issuance, memory access, register access, breakpoint triggering, single-step execution, and instruction behavior in debug mode. This rule is applicable to system-level verification.

6. A cross-level unified verification method for RISC-V processor debug modules, characterized in that, include: The compiler macros are set according to the design module under test, and the verification level and interface protocol are adaptively switched. The verification level includes module level, subsystem level and system level, and the interface protocol includes APB, JTAG and CJTAG. Based on the target verification level, a test stimulus sequence independent of the underlying protocol is generated through a set of unified debugging semantic APIs that are decoupled from the underlying communication protocol and verification level. Based on the configured compiler macros, the cross-level transaction adaptation module will adaptively convert the sequence generated by the unified debugging semantic API into the stimulus sequence of the corresponding interface protocol. According to the target verification level, the corresponding verification strategy is executed. The module-level strategy is to test the legal and illegal access of the debug module registers. The subsystem-level strategy is to reuse the module-level test cases and verify the conversion link from the test access port to the debug module. The system-level strategy is to reuse test cases other than illegal random access and execute the complete debugging process. The built-in verification rules are automatically selected based on the verification strategy to automatically compare and verify the behavior of the debugging module.

7. The method according to claim 6, characterized in that, The target verification level is at the module level, and the method includes: Configure compiler macros to select the APB interface driver and configure the verification level to module level; Call the dm_dereset() API to complete the debug module de-reset; Call the acc_dm_reg() API to perform random read and write access to legal and illegal addresses in the debug module registers; Call the enter_dbg_mode() and quit_dbg_mode() APIs to control the processor to enter and exit debug mode and check the debug module request status; Call the abstract instruction execution class API to check if the instruction has been issued correctly; The cross-level transaction adaptation module adaptively converts the API test stimulus sequence into the APB test stimulus sequence; The hierarchical automatic verification module calls the first verification rule to verify the correctness of the register values, state transitions, and instruction issuance of the debugging module.

8. The method according to claim 6, characterized in that, The target verification level is at the subsystem level, and the method includes: Configure compiler macros to select the JTAG / CJTAG interface driver and configure the verification level to subsystem level; Reuse the entire API test stimulus sequence for module-level verification; The cross-level transaction adaptation module adaptively converts API test stimulus sequences into JTAG / CJTAG test stimulus sequences; The hierarchical automatic verification module simultaneously calls the first verification rule and the second verification rule to verify the internal behavior of the debugging module and the conversion link from the test access port to the debugging module and the behavior of the debugging module, respectively.

9. The method according to claim 6, characterized in that, The target verification level is system-level, and the method includes: Configure compiler macros to select the JTAG / CJTAG interface driver and configure the verification level to system level; Reuse the API test stimulus sequence in module-level verification, excluding the illegal random access to register test cases; Call the pbuff_cmd_issue() API to initialize the program buffer and issue instructions, and perform instruction verification. Call the enter_dbg_mode() API to put the processor into debug mode; Call the read_idcode() API to read and verify the device identification code; Call the acc_reg() and acc_mem() APIs to perform random access and automatic comparison of registers and memory; Configure breakpoints by calling the trigger_ini() API, and resume processor operation by calling the quit_dbg_mode() API; After a breakpoint is triggered, the trigger_mon_close() API is called to automatically monitor and check whether the processor has entered debug mode, whether the debug reason register is correct, and whether the breakpoint program counter is correct. The cross-level transaction adaptation module adaptively converts API test stimulus sequences into JTAG / CJTAG test stimulus sequences; The hierarchical automatic verification module calls the first, second, and third verification rules to verify the processor's debug mode entry / exit, breakpoint triggering correctness, and instruction execution results.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the cross-level unified verification method as described in any one of claims 6 to 9.

Images