Debugging system and method for RISC-V and FPGA system-on-chip

Abstract

The invention discloses a debugging system and method for RISC-V and FPGA system-on-chip. The system comprises a control module, a multiplexer, a debugging module and a JTAG interface, and the debugging module comprises an RISC-V DAP submodule and an FPGA TAP submodule; the control module is used for acquiring a debugging mode and sending a corresponding debugging link configuration instruction to the multiplexer; the multiplexer is used for configuring signal routing paths of the two submodules so as to form a debugging link; the RISC-V DAP submodule is used for debugging the debugging command and generating a debugging result when the debugging link routes the debugging command to the submodule to carry out RISC-V debugging; and the FPGA TAP submodule is used for debugging the debugging command and generating a debugging result when the debugging link routes the debugging command to the submodule to debug the FPGA. Therefore, by configuring different signal routing paths, construction of different signal debugging links is realized, support for multiple debugging modes is realized, and the debugging flexibility is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to a system-level chip debugging technology, in particular to a RISC-V and FPGA system-level chip debugging system. BACKGROUND

[0002] With the rapid development of embedded systems, Internet of Things, industrial control and intelligent terminals, the requirements for security, reliability and high performance of systems are increasing, which promotes the evolution of system-level chip (SoC) platforms towards heterogeneous integration.

[0003] Under this background, the flexibility of the debugging system, as a key link to ensure software development, fault diagnosis and system maintenance, is crucial.

[0004] However, in the related art, the SoC debugging system is constructed based on a fixed debugging mode, and once the debugging mode is determined, the system only supports debugging of the mode, thus lacking flexibility. SUMMARY

[0005] The embodiments of the present application provide a RISC-V and FPGA system-level chip debugging system, which comprises a control module, a multiplexer, a debugging module and a JTAG interface, wherein the debugging module comprises a RISC-V DAP submodule comprising a plurality of RISC-V debugging functions and an FPGA TAP submodule comprising a plurality of FPGA debugging functions. The control module is configured to obtain a debugging mode and send a debugging link configuration instruction corresponding to the debugging mode to the multiplexer. The multiplexer is configured to configure a signal routing path of the RISC-V DAP submodule and a signal routing path of the FPGA TAP submodule according to the debugging link configuration instruction to form a debugging link. The RISC-V DAP submodule is configured to, when the debugging command is routed to the submodule on the debugging link for RISC-V debugging, call the RISC-V debugging function contained in the debugging command to debug the RISC-V and generate a debugging result. The FPGA TAP submodule is configured to, when the debugging command is routed to the submodule on the debugging link for FPGA debugging, call the FPGA debugging function contained in the debugging command to debug the FPGA and generate a debugging result.

[0006] The embodiments of the present application provide a RISC-V and FPGA system-level chip debugging method, which is applied to the above-mentioned RISC-V and FPGA system-level chip debugging system, and comprises: The control module obtains a debugging mode, and sends a debugging link configuration instruction corresponding to the debugging mode to the multiplexer; The multiplexer configures a signal routing path of the RISC-V DAP submodule and a signal routing path of the FPGA TAP submodule according to the debugging link configuration instruction to form a debugging link. When the RISC-V DAP submodule routes the debugging command to the submodule for debugging of the RISC-V on the debugging link, the RISC-V debugging function contained in the debugging command is called according to the debugging command, the RISC-V is debugged, and a debugging result is generated. When the FPGA TAP submodule routes the debugging command to the submodule for debugging of the FPGA on the debugging link, the FPGA debugging function contained in the debugging command is called according to the debugging command, the FPGA is debugged, and a debugging result is generated.

[0007] The RISC-V and FPGA system-on-chip debugging system provided by the embodiment of the application includes a control module, a multiplexer, a RISC-V DAP submodule, and an FPGA TAP submodule. The control module obtains a debugging mode, and sends a debugging link configuration instruction corresponding to the debugging mode to the multiplexer. The multiplexer configures a signal routing path of the RISC-V DAP submodule and a signal routing path of the FPGA TAP submodule according to the debugging link configuration instruction to form a debugging link. The RISC-V DAP submodule is configured to, when the debugging command is routed to the submodule for debugging of the RISC-V on the debugging link, call a RISC-V debugging function contained in the debugging command according to the debugging command, debug the RISC-V, and generate a debugging result. The FPGA TAP submodule is configured to, when the debugging command is routed to the submodule for debugging of the FPGA on the debugging link, call an FPGA debugging function contained in the debugging command according to the debugging command, debug the FPGA, and generate a debugging result. Therefore, the construction of different debugging links of different signals is realized by configuring different signal routing paths, the support for multiple debugging modes is realized, and the flexibility of debugging is greatly improved.

[0008] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. Other advantages of the present application can be realized and attained by means of the instrumentalities and combinations particularly pointed out in the description and appended claims. BRIEF DESCRIPTION OF DRAWINGS

[0009] The accompanying drawings are included to provide a further understanding of the present application, and constitute a part of the specification, illustrate embodiments of the present application, and are used to explain the technical solutions of the present application, but do not constitute a limitation on the technical solutions of the present application.

[0010] Figure 1A structure schematic diagram of a debugging system of a RISC-V and FPGA system-level chip according to an embodiment of the present application; Figure 2 A structure schematic diagram of a debugging system of a RISC-V and FPGA system-level chip according to another embodiment of the present application; Figure 3 A schematic diagram of an independent debugging mode flow according to an embodiment of the present application; Figure 4 A schematic diagram of a cascaded debugging mode flow according to an embodiment of the present application; Figure 5 A schematic diagram of a running process of a debugging system according to an embodiment of the present application; Figure 6 A schematic diagram of a JTAG signal connection in a cascaded mode according to an embodiment of the present application; Figure 7 A structure schematic diagram of a RISC-V DAP submodule according to an embodiment of the present application; Figure 8 A structure schematic diagram of a FPGA TAP submodule according to an embodiment of the present application; Figure 9 A flow schematic diagram of a debugging method of a RISC-V and FPGA system-level chip according to an embodiment of the present application. DETAILED DESCRIPTION

[0011] The present application describes a plurality of embodiments, but the description is exemplary rather than limiting, and it will be apparent to those of ordinary skill in the art that more embodiments and implementations can be within the scope of the embodiments described herein. Although a number of possible combinations of features have been set forth herein, and discussed in the specific implementation, many other combinations of the disclosed features are possible. Unless specifically intended otherwise, any feature or element of any embodiment can be used in combination with any other feature or element of any other embodiment, or in combination with any other feature or element of the same embodiment.

[0012] The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features, and elements disclosed herein can also be combined with any conventional features or elements to form unique invention solutions. Any feature or element of any embodiment can also be combined with features or elements from other invention solutions to form another unique invention solution. Therefore, it should be understood that any feature shown and / or discussed in the present application can be implemented alone or in any appropriate combination. Accordingly, the embodiments are not to be restricted, except as by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0013] Moreover, in describing representative embodiments, the specification can have presented the method and / or process as a particular sequence of steps. However, to the extent that the method or process depends on the particular order of steps, this description should not be construe to imply that the steps are necessarily order dependent. Other steps could be performed in other sequences or omitted altogether without departing from the teachings of the disclosure. Therefore, the particular order of the steps set forth in the specification should not be construed as a limitation of the claims. Furthermore, the claims should not be construed as being limited to the particular sequences of steps described in the specification, as other sequences of steps could also be employed to carry out the claims.

[0014] The embodiments of the present disclosure provide a debugging system for RISC-V and FPGA system-on-chip, as shown in the accompanying drawings, comprising a control module 10, a multiplexer 11, a debugging module 12, and a JTAG interface 13, wherein the debugging module 12 comprises a RISC-V DAP submodule 120 comprising a plurality of RISC-V debugging functions, and an FPGA TAP submodule 121 comprising a plurality of FPGA debugging functions. Figure 1 The control module 10 is configured to obtain a debugging mode and send a debugging link configuration instruction corresponding to the debugging mode to the multiplexer 11. The multiplexer 11 is configured to configure a signal routing path of the RISC-V DAP submodule 120 and a signal routing path of the FPGA TAP submodule 121 according to the debugging link configuration instruction, to form a debugging link. The RISC-V DAP submodule 120 is configured to, when the debugging command is routed to the submodule for RISC-V debugging on the debugging link, invoke the RISC-V debugging function contained in the debugging command, debug the RISC-V and generate a debugging result. The FPGA TAP submodule 121 is configured to, when the debugging command is routed to the submodule for FPGA debugging on the debugging link, invoke the FPGA debugging function contained in the debugging command, debug the FPGA and generate a debugging result. The control module can determine the debugging mode by reading the configuration register value or the external jumper state.

[0015]

[0016] ​The RISC-V DAP submodule includes RISC-V debugging functions such as: register access, memory access, breakpoint setting, single-step execution, run / pause control, exception and interrupt handling, and multi-threaded debugging. Register access refers to reading and writing the processor's general-purpose registers and control status registers; memory access refers to directly accessing memory (e.g., reading and writing data or instructions) through the system bus or abstract commands; breakpoint setting refers to setting breakpoints through hardware triggers to pause program execution; single-step execution refers to executing instructions one by one to debug code logic; run / pause control refers to remotely controlling the processor's running state (e.g., pausing and resuming); exception and interrupt handling refers to managing exceptions and interrupt events during debugging; and multi-threaded debugging supports independent debugging of multiple hardware threads.

[0017] The FPGA debugging functions included in the FPGA TAP submodule can include: signal acquisition and analysis, real-time monitoring and modification, trigger and condition capture, resource usage analysis, and power consumption and temperature monitoring. Among them, signal acquisition and analysis refers to real-time observation of internal signal waveforms (such as ILA, SignalTap); real-time monitoring and modification refers to dynamic reading and writing of registers (such as VIO); trigger and condition capture refers to triggering data acquisition based on specific conditions (such as signal changes, error flags); resource usage analysis refers to statistical analysis of the usage of resources such as logic units, RAM, and timing; and power consumption and temperature monitoring refers to real-time monitoring of chip voltage and temperature through hardware verification such as XADC.

[0018] Debug commands are used to indicate what type of RISC-V debugging or FPGA debugging to perform. When the RISC-V DAP submodule and FPGA TAP submodule invoke the included FPGA debugging functions according to the debug commands, they invoke the corresponding FPGA debugging functions. For example, when the debug command is to access RISC-V registers, the RISC-V DAP submodule invokes the included register access debugging function to debug the RISC-V and generate debug results. When the debug command is to perform resource usage analysis on the FPGA, the FPGA TAP submodule invokes the included resource usage analysis function to debug the FPGA and generate debug results.

[0019] The RISC-V and FPGA system-on-a-chip debugging system provided in this application embodiment includes a control module that acquires a debugging mode and sends a debugging link configuration command corresponding to the debugging mode to a multiplexer. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debugging link configuration command to form a debugging link. The RISC-V DAP submodule, when the debugging link routes the debugging command to it for RISC-V debugging, invokes the included RISC-V debugging functions according to the debugging command to debug the RISC-V and generate debugging results. The FPGA TAP submodule, when the debugging link routes the debugging command to it for FPGA debugging, invokes the included FPGA debugging functions according to the debugging command to debug the FPGA and generate debugging results. Therefore, by configuring different signal routing paths, different debugging links for signals are constructed, supporting multiple debugging modes and greatly improving debugging flexibility.

[0020] In one exemplary instance, such as Figure 2 As shown, the RISC-V DAP submodule 120 includes a first JTAG interface 120a, and the FPGA TAP submodule 121 includes a second JTAG interface 121a. The debugging modes include an independent debugging mode and a cascaded debugging mode. When the debugging mode is the independent debugging mode, the outgoing modes of the first JTAG interface 120a and the second JTAG interface 121a include a first outgoing mode and a second outgoing mode. The first outgoing mode refers to a mode in which both the first JTAG interface 120a and the second JTAG interface 121a are outgoing, and the second outgoing mode refers to a mode in which the first JTAG interface 120a is not outgoing and the second JTAG interface 121a is outgoing. When the debugging mode is the independent debugging mode, and the outgoing mode of the first JTAG interface 120a and the second JTAG interface 121a is the first outgoing mode, the debugging link configuration command is the first independent debugging link configuration command. When the debugging mode is the independent debugging mode, and the outgoing mode of the first JTAG interface 120a and the second JTAG interface 121a is the second outgoing mode, the debugging link configuration command is the second independent debugging link configuration command. When the debugging mode is the cascaded debugging mode, the debugging link configuration command is the cascaded debugging link configuration command.

[0021] In independent debug mode, the first and second JTAG interfaces have two access modes: a first access mode and a second access mode. The first access mode is suitable for designs with ample chip pin resources, where the JTAG interfaces of both the RISC-V DAP submodule and the FPGA TAP submodule are accessed externally. The second access mode is suitable for designs with limited pins (such as small-package chips), where the JTAG interface of the RISC-V DAP submodule is not accessed, and only the JTAG interface of the FPGA TAP submodule is accessed externally. In the second access mode, debugging of the RISC-V processor can be achieved through the JTAG interface of the FPGA TAP submodule.

[0022] The RISC-V DAP submodule on the PS side strictly adheres to the RISC-V Debug specification, while the FPGA TAP submodule on the PL side strictly adheres to the IEEE 1149.1 standard. When cascading mode is to be implemented, the two are seamlessly cascaded through a multiplexer.

[0023] The RISC-V DAP submodule interacts with the RISC-V core using a high-speed bus interface (such as AXI Lite) to ensure real-time response to debug commands. Its hardware architecture is based on a layered modular design, modularizing functions such as command parsing, data processing, and status feedback to achieve an easily expandable and maintainable architecture. The FPGA TAP submodule supports boundary scan registers, online monitoring, and FPGA logic debugging, conforming to the IEEE 1149.1 standard to ensure compatibility with external debugging tools and the RISC-V DAP submodule.

[0024] In cascaded mode, TDI receives the RISC-V DAP TDO signal from the multiplexer, and TDO returns the processing result to the external debugging tool.

[0025] The multiplexer provided in this application supports dynamic routing of debugging signals, dynamically switching between independent and cascaded modes according to system configuration, ensuring signal isolation between the two debugging interfaces and avoiding switching interference; it uses high-speed analog switches or digital multiplexers to split or cascade TCK, TMS, TDI, and TDO signals, and its built-in mode control logic dynamically determines the working mode through preset registers or external configuration inputs, supports online dynamic switching, and provides status feedback to the upper-level debugging software for confirmation and adjustment of the debugging mode.

[0026] In one exemplary instance, when the debug link configuration instruction is a first independent debug link configuration instruction, the first JTAG interface is used to connect to a first debug tool, the second JTAG interface is used to connect to a second debug tool, and the debug command includes: a first debug command initiated by the first debug tool for debugging RISC-V, and a second debug command initiated by the second debug tool for debugging FPGA; The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer configures the signal routing path between the first JTAG interface and the first debugging tool, and the signal routing path between the second JTAG interface and the second debugging tool, according to the first independent debugging link configuration instruction, so as to form the debugging link; The debug link is used to route the first debug command to the RISC-V DAP submodule via the first JTAG interface, so that the RISC-V DAP submodule debugs the RISC according to the first debug command; and to route the second debug command to the FPGA TAP submodule via the second JTAG interface, so that the FPGA TAP submodule debugs the FPGA according to the second debug command.

[0027] The independent debugging mode process can be as follows: Figure 3 As shown, the RISC-V DAP submodule outputs debug signals via a separate JTAG interface for use by standard RISC-V debug tools (such as OpenOCD). The FPGA TAP submodule connects independently to another debug interface for internal FPGA debugging and logic verification. Both the RISC-V DAP and FPGA TAP output standard debug signals, allowing debug tools to be connected and debugged independently. There is no direct signal cascading between modules, ensuring independence in the debugging process and facilitating division of labor and individual verification.

[0028] In one exemplary instance, when the debug link configuration instruction is a second independent debug link configuration instruction, the second JTAG interface is used to connect a third debug tool and a fourth debug tool. The debug command includes: a third debug command initiated by the third debug tool for debugging RISC-V, and a fourth debug command initiated by the fourth debug tool for debugging FPGA. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer connects the first JTAG interface and the second JTAG interface in series according to the second independent debug link configuration instruction, and configures the signal routing path between the second JTAG interface and the third debug tool and the fourth debug tool to form the debug link; The debug link is used to route the third debug command to the RISC-V DAP submodule via the second JTAG interface, so that the RISC-V DAP submodule can debug the RISC according to the third debug command, and to route the fourth debug command to the FPGA TAP submodule via the second JTAG interface, so that the FPGA TAP submodule can debug the FPGA according to the fourth debug command.

[0029] In one exemplary instance, when the debug link configuration command is a cascaded debug link configuration command, the FPGA TAP submodule also includes a variety of RISC-V debugging functions. The FPGA TAP submodule is also used to call the included RISC-V debugging functions according to the debug command when the debug link routes the debug command to the submodule for RISC-V debugging, to debug RISC-V and generate debugging results. The second JTAG interface is used to connect to the fifth debugging tool. The debugging command includes: a fifth debugging command initiated by the fifth debugging tool for debugging RISC-V and FPGA; the fifth debugging command includes: a first sub-debugging command and a second sub-debugging command, wherein the first sub-debugging command is used to debug RISC-V and the second sub-debugging command is used to debug FPGA. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer connects the TDI of the fifth debugging tool to the TDI of the first JTAG interface, connects the TDO of the first JTAG interface to the TDI of the second JTAG interface, and connects the TDO of the second JTAG interface to the TDO of the fifth debugging tool according to the cascaded debugging link configuration instruction, so as to form the debugging link. The debug link is used to route the fifth debug command to the RISC-V DAP submodule via the second JTAG interface, so that the RISC-V DAP submodule parses the first sub-debug command therein, and routes the parsed first sub-debug command and the second sub-debug command to the FPGA TAP submodule, so that the FPGA TAP submodule debugs the RISC-V according to the parsed first sub-debug command, and debugs the FPGA according to the second sub-debug command.

[0030] The cascading debugging mode process can be as follows: Figure 4 As shown, in cascaded debug mode, the entire SoC platform connects the debug access port (DAP) on the RISC-V side and the test access port (TAP) on the FPGA side through internal signal routing, forming a unified JTAG chain. This allows external debug tools to access the PS (RISC-V) and PL (FPGA) parts sequentially by connecting to a single JTAG interface.

[0031] The operation process of the debugging system provided in this application embodiment is as follows: Figure 5 As shown, it includes: 1. System power-on and global reset After the system is powered on, the PL (FPGA side) loads the configuration file and completes the FPGA initialization, while the PS (processor side) enters the reset state and waits to start.

[0032] 2. Global reset complete and system initialization finished. Once the global reset is lifted, all modules of the system complete initialization.

[0033] 3. Debugging mode detection and selection The system detects the current debug mode through internal configuration registers or external jumpers to determine whether to use cascaded debug mode.

[0034] 4. Initialize and debug the control unit Based on the test results, load the corresponding DAP and TAP debugging firmware to complete the basic initialization of the debugging module.

[0035] 5. Configure a multiplexer (MUX) According to the cascade mode requirements, the internal multiplexer routes the TDO output signal of the RISC-V DAP to the TDI input of the FPGA TAP, while the TCK and TMS signals are distributed to the two modules in parallel.

[0036] 6. Establishment of Cascaded Debugging Link A continuous JTAG chain is formed through a multiplexer: from the TDI of the external debugging tool to the RISC-V DAP to the FPGA TAP to the TDO of the external debugging tool, achieving unified debugging.

[0037] 7. External debugging tool connection and online debugging Once the external debugging tool connects to the system's unified JTAG interface, it begins sending debugging commands and simultaneously provides feedback on the debugging status through the online status monitoring module, ensuring the stable and efficient operation of the entire debugging process.

[0038] The power-on and reset phase described above may include the following specific processes: 1. Power on the system After the system powers on, both the PS and PL undergo reset initialization. On the FPGA side, the internal logic of the PL is initialized by loading a configuration file, which includes a secure debug system module.

[0039] 2. Reset synchronization By using a cross-clock reset synchronizer, the RISC-V core and FPGA debug module are ensured to start in the same reset state.

[0040] The debugging mode detection and selection phase described above may include: 1. Pattern Detection The system detects the current debug mode at startup via a configuration register (which can be configured via an external jumper or software): Independent debugging mode: The RISC-V core and FPGA each have their own independent JTAG debugging port.

[0041] Cascaded debugging mode: The two JTAG signals are combined into a unified debugging chain through an internal multiplexer.

[0042] 2. Bootloader environment initialization During startup, the bootloader initializes the debugging system, including loading the debug controller firmware (DAP and TAP firmware), initializing signal routing, and setting the corresponding debug mode based on the detection results.

[0043] Debugging in cascaded debug mode can include: 1. Mode Selection and Initialization After the system powers on, each subsystem is initialized. The control module reads the configuration register or detects external jumpers to determine the debug mode. When configured for cascaded debug mode, the control unit instructs the multiplexer to cascade the debug signals of the RISC-VDAP and FPGATAP.

[0044] 2. Signal routing settings After system startup, the control unit of the debugging system determines the cascading mode through the configuration register, and the multiplexer switches to cascading operation. External JTAG debug signals are routed to the RISC-V DAP submodule via the built-in digital multiplexer or high-speed analog switch. The TCK and TMS signals are distributed in parallel between the RISC-V DAP and the FPGA TAP to ensure synchronization. The TDO output of the RISC-V DAP is dynamically routed to the TDI input of the FPGA TAP via the internal multiplexer. The FPGA TAP submodule processes debug commands according to the IEEE 1149.1 state machine, and can pass the commands down to the internal logic of the FPGA or directly return to the debug state, realizing the complete data flow of the cascading debug chain.

[0045] 3. Establishment of Cascaded Test Link In cascaded mode, the entire debug chain is ordered as follows: TDI of the external debug tool to RISCVDAP to FPGATAP to TDO of the external debug tool.

[0046] After switching to cascade mode, the multiplexer will directly connect the TDO output of the RISC-V DAP to the TDI input of the FPGA TAP, while ensuring that the clock (TCK) and mode selection signal (TMS) in the link are consistently delivered to each module.

[0047] 4. Debugging command transmission and data return External debugging tools send debugging commands via the JTAG chain. The RISC-V DAP submodule receives and parses these commands (such as read / write registers, single-step execution), stores the processing results in internal registers, and outputs them via TDO. This signal is dynamically routed to the TDI input of the FPGA TAP submodule via an internal multiplexer. The FPGA TAP submodule processes the debugging commands according to the IEEE 1149.1 state machine and outputs the results via its TDO, which are then returned to the TDO interface of the external debugging tool via a cascaded chain. The debugging status monitoring module monitors the working status, signal integrity, and data transmission latency of each node in real time to ensure the integrity and low latency of the link transmission.

[0048] In cascaded mode, the main signals of the JTAG interface include TCK, TMS, TDI, and TDO. The connections and routing of each signal are as follows: 1. TCK and TMS signals The TCK (clock) and TMS (mode select) signals provided by the external debugging tools are simultaneously distributed to the RISC-V DAP and FPGA TAP submodules by an internal distributor, ensuring synchronous operation of the two parts. To ensure signal integrity, buffers and level shifters are typically added to the input of each module to accommodate different voltage domain requirements.

[0049] 2. Cascading connection of TDI signals In cascaded mode, the TDI signal from the external debug tool is first fed into the TDI input of the RISC-V DAP submodule. After processing the debug command (the source of the parsed JTAG instruction), the RISC-V DAP submodule outputs a TDO signal; this TDO signal is automatically routed to the TDI input of the FPGA TAP submodule via an internal multiplexer. This connection process requires ensuring that the TDO signal transmission has no delay transitions in timing; therefore, short paths and appropriate clock buffering designs are typically used in the internal signal routing.

[0050] 3. Return of TDO signal After receiving a debug command, the FPGA TAP submodule outputs the debug processing result through its TDO; this TDO output signal is directly sent back to the TDO interface of the external debug tool. Throughout the entire link, the transmission between the TDOs and TDIs of each module is cascaded to ensure the continuity of the data link.

[0051] Cascaded JTAG signal connections can be as follows Figure 6 As shown, the TDI signal of the external debugging tool first enters the RISC-V DAP submodule; the TDO output of the DAP module is routed through a multiplexer and then transmitted to the TDI input of the FPGA TAP submodule; the TDO signal output by the FPGA TAP submodule after processing is returned to the external debugging tool, forming a complete cascaded debugging chain.

[0052] In one exemplary instance, the FPGA TAP submodule debugs the RISC-V according to the parsed first sub-debug command and debugs the FPGA according to the second sub-debug command in the following ways: serial debugging mode and parallel debugging mode; The serial debugging method refers to the FPGA TAP submodule first debugging the RISC-V according to the parsed first sub-debugging command, and then debugging the FPGA according to the second sub-debugging command after the RISC-V debugging is completed; or, debugging the FPGA according to the second sub-debugging command first, and then debugging the RISC-V according to the parsed first sub-debugging command after the FPGA debugging is completed. The parallel debugging method involves the FPGA TAP submodule first debugging the RISC-V according to the parsed first sub-debugging command, and then debugging the FPGA according to the second sub-debugging command during the RISC-V debugging process; or first debugging the FPGA according to the second sub-debugging command, and then debugging the RISC-V according to the parsed first sub-debugging command during the FPGA debugging process.

[0053] In one exemplary instance, such as Figure 2 As shown, the debugging system also includes: a debugging status monitoring module 13; The debugging status monitoring module 13 is used to detect the integrity of the debugging link and monitor the status of the debugging link.

[0054] The debug status monitoring module monitors the operating status, signal integrity, and data transmission latency of the RISC-V DAP and FPGA TAP in real time, capturing error messages and timing anomalies to help developers quickly locate problems. This module has built-in monitoring registers and counters to record key timing parameters and error events, and feeds back monitoring data to debugging tools through dedicated interfaces such as JTAG or UART, supporting automatic retry or manual intervention error recovery mechanisms.

[0055] In one exemplary instance, such as Figure 2 As shown, the debugging system further includes: a buffer isolation circuit 14; The buffer isolation circuit 14 is used to isolate different power domains between the RISC-V side and the FPGA side; it is also used to add a low-jitter clock buffer to TCK with a frequency higher than a preset frequency threshold; and it is also used to add edge alignment logic to the input of the parallel TDI / TMS.

[0056] In one exemplary instance, such as Figure 2 As shown, the debugging system also includes: a synchronizer circuit 15; The synchronizer circuit 15 is used to synchronize the TMS and TDI of the first JTAG interface to the FPGA-side clock domain before the parsed first sub-debugging command is transmitted to the FPGA TAP sub-module.

[0057] The RISC-V DAP submodule in the RISC-V and FPGA system-on-a-chip debugging system provided in this application embodiment has an architecture based on a hierarchical modular design. The hardware architecture of the RISC-V DAP submodule can be as follows: Figure 7 As shown, it includes: command parsing and control logic, implemented using a finite state machine, used to parse JTAG commands from external debugging tools and control the kernel state; a data processing unit, used to support register read / write and memory access with the RISC-V kernel; a FIFO cache and internal registers, used to store and buffer debug data to ensure transmission stability; a high-speed bus interface, used to achieve high-speed data exchange with the kernel via AXI Lite or a dedicated debug bus; and a JTAG standard interface, used to provide TDI, TDO, TCK, and TMS standard signals, fully compatible with the RISC-V Debug specification, and supporting seamless integration with mainstream debugging tools such as OpenOCD and GDB.

[0058] The FPGA TAP submodule in the RISC-V and FPGA system-on-a-chip debugging system provided in this application adopts a modular design, supports efficient and low-latency boundary scan operations, realizes online acquisition of internal FPGA signals, and ensures seamless integration with the RISC-V DAP submodule in cascaded debugging mode. The architecture of the FPGA TAP submodule can be as follows: Figure 8 As shown, it includes: a TAP controller based on the IEEE 1149.1 standard for control state management and command processing, supporting state transitions such as Test-Logic-Reset, Run-Test / Idle, Shift-DR, Capture-DR, and Update-DR; a signal capture unit integrating boundary scan registers and Scan Chain for capturing and transmitting FPGA logic signals; dedicated signal buffers and isolation circuits to ensure the stability of debug data in cascaded mode; and standard JTAG interfaces (TDI, TDO, TCK, TMS, for connecting external debug tools and RISC-V DAP submodules).

[0059] In related technologies, SOC debugging systems often have the following drawbacks: 1. Individual debugging mode Existing solutions often design separate JTAG interfaces for the RISC-V core and FPGA. Although it is more convenient to debug each module, it occupies more pins and resources in actual products, and lacks a unified view during the debugging process.

[0060] 2. Cascaded debugging scheme, but lacks flexibility. Some designs attempt to use a fixed JTAG daisy chain to connect RISC-V and FPGA, but it is difficult to ensure the compatibility and signal integrity of the two different debugging protocols (RISC-V DAP and FPGA TAP), and the debugging mode cannot be flexibly switched.

[0061] 3. Insufficient standard compatibility Currently, some systems fail to fully meet the RISC-V Debug specification when implementing RISC-V debugging. At the same time, the TAP design on the FPGA side also has problems with poor integration with industry standards, resulting in low compatibility of debugging tools and low debugging efficiency.

[0062] The debugging system provided in this application embodiment is a flexible and efficient debugging system designed for multi-core RISC-V and FPGA SoC platforms, including: 1. Multiplexer and Mode Control Unit Design The system provides two debug link connection methods: standalone mode and cascaded mode. In standalone mode, the RISC-V processor side and the FPGA side each independently connect to debug tools through dedicated JTAG / debug interfaces (DAP and TAP). In cascaded mode, the debug interfaces on both sides are connected in series and share a set of JTAG signal lines, enabling single-port access to the entire SoC platform. To this end, a dynamically switchable multiplexer (MUX) and mode control logic are designed: First, a mode selection pin or register is added in hardware to determine the current operating mode after system reset or software control. This mode selection signal drives the internal multiplexer to route external JTAG signals (TCK, TMS, TDI) to different configurations of the RISC-V side DAP and the FPGA side TAP. Standalone Mode: The MUX enables direct connection of the FPGA-side JTAG port to an external debugger, while the RISC-V-side DAP is isolated from the external link and exposed to the outside via a separate channel for use by a second debug chain. In this mode, each debug interface operates independently, and the software can configure the DAP and TAP separately to ensure compatibility with single-device debug tools.

[0063] Cascading Mode: The MUX connects the RISC-V-side DAP and the FPGA-side TAP in series, exposing only one set of JTAG pins for external connection. For example, it can be designed with the RISC-V DAP as the chain front end and the FPGA TAP as the chain back end. External TDI inputs sequentially enter the DAP and then the TAP, finally outputting through TDO. This link structure follows the IEEE 1149.1 daisy-chain rule, ensuring that one interface can access the debug ports on multiple chips.

[0064] In hardware implementation, the multiplexer can employ a tri-state buffer or a decoder control gateway: when the mode switch is independent, the JTAG path of the RISC-V side DAP is disconnected or placed in bypass mode, while the TAP path of the FPGA side is closed; conversely, the two are interconnected. The mode control unit contains a simple state machine: upon receiving a mode switching command, it first pauses the JTAG clock (TCK), resets each debugger chain (via the TRST signal), then updates the MUX selection bit, and finally re-enables the clock to restore communication. This idle-cycle switching mechanism prevents signal race conditions or corruption, ensuring interface compatibility and stable switching. This mode can be determined by hardware pins upon reset or dynamically switched by writing registers in software; during the switching process, all relevant TAPs / DAPs enter a safe bypass state, avoiding undefined behavior at the moment of switching. Furthermore, to support multi-core processors, link selection control logic can be introduced before the multiplexer: adding a link selection instruction register, decoder, and multiplexer structure within the SoC chip allows selection of the core to be activated via specific JTAG instructions or command words. In this way, a single JTAG port can be used to debug multiple RISC-V cores sequentially through multiplexing, achieving hardware and software collaborative debugging multiplexing.

[0065] 2. Cascaded JTAG Link Structure Design In cascaded mode, the debug access port (DAP) on the RISC-V side and the test access port (TAP) on the FPGA side are physically connected in series via a JTAG link, enabling single-port access to the entire SoC platform. During routing, external JTAG connectors (CPU_TCK, CPU_TMS, CPU_TDI inputs, and CPU_TDO outputs) are connected to the JTAG I / O pads on the FPGA side (e.g., FPGA_TCK, FPGA_TMS, FPGA_TDI, FPGA_TDO). Internally, the FPGA-side TAP and RISC-V-side DAP are logically cascaded: the FPGA-side TDI signal is connected to the TDI input of the RISC-V DAP, and the RISC-V DAP's TDO is sent to the FPGA-side TMS / TDI path via a MUX. Ultimately, the RISC-V DAP's TDO and the FPGA TAP's TDI are connected in series to form the overall link. The clock TCK and mode TMS signals are directly fed into both externally (distributed via a MUX) and can be driven in parallel where necessary to ensure signals reach both stages simultaneously. All JTAG chains share a single set of clock and data lines, and are configured in a daisy-chain configuration compliant with the IEEE 1149.1 standard, requiring only one test port to access all of them.

[0066] To ensure signal integrity and electrical compatibility, dedicated level isolation / buffering units are used in the link design. For example, level shifters or high-speed buffer drivers are added at cross-domain connections to match different supply voltages or signal standards between domains and ensure sufficient drive capability. The clock line (TCK) is distributed using a low-skew clock buffer to avoid transmission delays and timing deviations. Simultaneously, appropriate resistors are added to each signal line to achieve impedance matching and reduce reflections. The reset signal TRST can employ two-stage isolation: an external low-level active reset is buffered by a set of flip-flops and then drives the reset pins of DAP and TAP respectively, ensuring that each unit returns to a known state during reset.

[0067] A unified distribution mechanism for cascaded links: External TCK and TMS inputs are first sent in parallel to the RISC-V DAP and FPGA TAP via distribution logic. The TDO of the RISC-V DAP acts as an intermediate node in the serial chain, forwarding it to the TDI of the FPGA TAP through the internal MUX. The TDO of the FPGA TAP then serves as the final output of the entire link, sent back to the debugger. The entire link can also be configured with a chain selection ID or BYPASS register, allowing the debug tool to sequentially locate devices at each layer. With this design, regardless of the number of debug terminals contained within the SoC (multiple DAPs in a multi-core RISC-V system or multiple TAPs within an FPGA), they can all be mapped to a single serial JTAG chain (each TAP is linked sequentially via BYPASS or IDCODE), enabling single-port debug access.

[0068] 3. Signal isolation and link stabilization mechanisms In cascaded mode, debug signals traverse multiple logic and power domains, posing a higher risk of signal attenuation and timing mismatch. Therefore, dedicated buffering and isolation circuits, as well as timing adjustment mechanisms, were designed to improve reliability. Specifically, when transmitting TCK / TMS / TDI across domains, bidirectional buffers or digital isolators are first used to isolate different power domains to avoid power supply noise interference. For higher-frequency TCK, a low-jitter clock buffer is added to enhance drive capability and minimize clock skew. For parallel TDI / TMS data lines, edge-aligned logic can be added to the inputs to adjust the relative phase of TMS / TDI when entering each TAP, avoiding race conditions caused by timing differences between different paths.

[0069] 4. To address the synchronization issue across clock domains, a synchronization flip-flop (dual D flip-flop synchronizer) is added at the critical signal entry point. Two stages of D flip-flops can be used to sample and synchronize asynchronous JTAG command signals (e.g., chain select pulses). This synchronizer circuit includes an SR latch to capture the input signal pulse, which is then synchronized to the local clock domain via two cascaded D flip-flops, thereby generating control pulses aligned with the local clock. This synchronization scheme ensures transparent conversion of JTAG control signals to the processor's internal logic clock, avoiding isostatic states.

[0070] 5. To further enhance link reliability, the system integrates a status monitoring module responsible for online detection and debugging of link integrity and TAP status. This module periodically sends IDCODE read or BYPASS diagnostic commands to the link and verifies whether the IDCODE values ​​returned by each level of TAP are consistent with the pre-configured expected values, quickly locating link interruptions or device loss. Simultaneously, it can poll the state machine status of each TAP (by scanning the TMS sequence to enter different TAP states) to ensure that no TAP is in an unresponsive or erroneous state. Once an anomaly is detected (such as link interruption, TAP freezing, or incorrect return value), the monitoring module reports the error to the main control or debugging management unit via interrupt or status register, triggering rollback measures (such as resetting the link or rebuilding the debugging session).

[0071] The debugging system provided in this application integrates the RISC-V standard DAP module and the FPGA-side TAP module into the same SoC platform, and employs a flexible multiplexer and mode control unit to achieve two debugging modes: 1. Independent debugging mode: RISC-V and FPGA can be debugged separately, facilitating independent development and maintenance; 2. Cascaded debugging mode: By cascading debugging signals, a unified JTAG chain is formed, allowing external debugging tools to perform overall system debugging through a single interface.

[0072] The mode switching control logic can be summarized as follows: 1. Configuration detection The control unit reads the configuration register value or external jumper status when the system starts up to determine whether the debugging mode is independent debugging or cascaded debugging.

[0073] 2. Signal switching In cascade mode, the control multiplexer connects the TDO of the RISC-V DAP to the TDI of the FPGA TAP, and distributes the TCK and TMS signals to the two modules in parallel.

[0074] During the switching process, the current debug chain status is reported to the upper-level debug software in real time through the built-in status feedback register to ensure that there is no signal loss or interference during the switching process.

[0075] 3. Online dynamic adjustment The system supports dynamically adjusting mode switching parameters during operation via debugging software to adapt to different debugging needs. For example, in the initial stage of system operation, a cascaded mode can be used for overall debugging, and when it is necessary to debug a subsystem separately later, the system can be temporarily switched to an independent debugging mode.

[0076] The debugging system provided in this application has the following characteristics: 1. Flexible and efficient debugging capabilities: Supports both independent debugging of RISC-V and FPGA and unified cascaded debugging modes, which not only meet the needs of system division of labor development, but also facilitate the overall system debugging, greatly improving debugging efficiency and system maintainability.

[0077] 2. Reduce debugging hardware costs and number of interfaces: In cascaded mode, only a single debugging port is needed to achieve unified debugging of PS and PL, effectively reducing debugging pins and hardware resource consumption.

[0078] 3. Standards Compatibility and Ease of Use: The system debugging module fully complies with the RISC-V Debug specification and the IEEE 1149.1 standard, and supports mainstream debugging tools (such as OpenOCD, J-Link, etc.), improving the compatibility and ease of use of the debugging system.

[0079] 4. Real-time monitoring and fault recovery: The built-in debug status monitoring and error detection module can quickly provide feedback when a debug chain failure occurs, and automatically start the retransmission or isolation mechanism to ensure the stability and reliability of the debugging process.

[0080] 5. Dynamic debugging mode switching and online optimization: Through multiplexers and mode control units, it supports online dynamic switching of debugging modes to adapt to different debugging scenarios, which facilitates later system upgrades and debugging strategy optimization.

[0081] The debugging system provided in this application supports network-based remote debugging, replacing the traditional single JTAG physical interface. The system integrates a high-speed Ethernet interface and adopts a networked debugging architecture, encapsulating debugging data and transmitting it via standard network protocols. An on-chip embedded debug agent is responsible for collecting debugging information from various modules within the SoC and forwarding it to the host debugging software via a network communication module. This enables real-time monitoring of the chip's operating status, fault diagnosis, and performance analysis, significantly improving debugging flexibility and remote accessibility. It is particularly suitable for the development and maintenance needs of complex SoCs in FPGA prototyping or embedded deployment scenarios.

[0082] The debugging system provided in this application embodiment also supports a hybrid debugging mode combining software debugging agents, breaking through the limitations of traditional pure hardware debugging modules (such as DAP and TAP). While retaining standard hardware debugging interfaces, the system can integrate software-implemented debugging agents or debugging middleware, providing debugging functions through standard system interfaces (such as memory-mapped I / O or dedicated communication channels). In this mode, debugging commands sent by the host are transmitted via a communication link to the embedded software debugging agent, which is responsible for parsing the instructions and distributing them to the corresponding debugging modules, enabling operations such as breakpoint control, register access, memory read / write, and runtime status monitoring of the target system. This hardware-software co-working debugging architecture not only reduces dependence on dedicated hardware resources but also improves the flexibility and scalability of debugging functions, making it suitable for complex SoC systems with limited resources or requiring dynamic configuration.

[0083] The debugging system provided in this application adopts a dynamic switching architecture based on programmable logic for debugging signal routing, breaking through the design limitations of traditional fixed multiplexers. It fully utilizes the reconfigurable characteristics of FPGAs, implementing fully soft-core debugging signal path configuration through programmable logic, supporting dynamic adjustment of the debugging chain connection topology and operating mode via software instructions at runtime. Specifically, reconfigurable logic IP cores can be deployed to replace traditional static multiplexers, enabling online reconfiguration of debugging signal routing, thereby achieving flexible interconnection between different debugging modules, test nodes, or functional units. This solution significantly improves the adaptability and resource utilization of the debugging system, supports remote debugging needs in multiple scenarios and modes, and provides highly customizable observability support for complex SoCs at different development and maintenance stages.

[0084] Corresponding to the aforementioned debugging system for RISC-V and FPGA system-on-a-chip, this application also provides a debugging method for RISC-V and FPGA system-on-a-chip. For example... Figure 9 As shown in the embodiments of this application, the debugging method for RISC-V and FPGA system-on-a-chip includes: Step 200: The control module obtains the debug mode and sends the debug link configuration command corresponding to the debug mode to the multiplexer; Step 210: The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link; Step 220: When the debug link routes the debug command to the RISC-V DAP submodule for RISC-V debugging, the RISC-V DAP submodule calls the included RISC-V debug function according to the debug command to debug the RISC-V and generate debug results. Step 230: When the debug link routes the debug command to the FPGA TAP submodule for FPGA debugging, the FPGA TAP submodule calls the included FPGA debugging function according to the debug command to debug the FPGA and generate debug results.

[0085] Steps 220 and 230 are either selectively executed or executed in parallel. When the debug link routes the debug command to this submodule for RISC-V debugging, step 220 is executed. When the debug link routes the debug command to this submodule for FPGA debugging, step 230 is executed. When the debug link routes the debug command to this submodule for both RISC-V and FPGA debugging, steps 220 and 230 are executed.

[0086] In one exemplary instance, the RISC-V DAP submodule includes a first JTAG interface, and the FPGA TAP submodule includes a second JTAG interface. The debug modes include an independent debug mode and a cascaded debug mode. When the debug mode is the independent debug mode, the outgoing modes of the first JTAG interface and the second JTAG interface include a first outgoing mode and a second outgoing mode. The first outgoing mode refers to a mode in which both the first JTAG interface and the second JTAG interface are outgoing, and the second outgoing mode refers to a mode in which the first JTAG interface is not outgoing and the second JTAG interface is outgoing. When the debug mode is independent debug mode, and the first JTAG interface and the second JTAG interface are exposed in the first exposed mode, the debug link configuration command is the first independent debug link configuration command. When the debug mode is independent debug mode and the first JTAG interface and the second JTAG interface are exposed in the second exposure mode, the debug link configuration command is the second independent debug link configuration command. When the debug mode is cascaded debug mode, the debug link configuration command is the cascaded debug link configuration command.

[0087] In one exemplary instance, when the debug link configuration instruction is a first independent debug link configuration instruction, the first JTAG interface is used to connect to the first debug tool, the second JTAG interface is used to connect to the second debug tool, and the debug commands include: a first debug command initiated by the first debug tool for debugging RISC-V, and a second debug command initiated by the second debug tool for debugging FPGA; The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer configures the signal routing path between the first JTAG interface and the first debugging tool, and the signal routing path between the second JTAG interface and the second debugging tool, according to the first independent debugging link configuration instruction, so as to form a debugging link; The debug link routes the first debug command to the RISC-V DAP submodule through the first JTAG interface, so that the RISC-V DAP submodule can debug the RISC according to the first debug command; and routes the second debug command to the FPGA TAP submodule through the second JTAG interface, so that the FPGA TAP submodule can debug the FPGA according to the second debug command.

[0088] In one exemplary instance, when the debug link configuration instruction is the second independent debug link configuration instruction, the second JTAG interface is used to connect the third debug tool and the fourth debug tool. The debug commands include: a third debug command initiated by the third debug tool for debugging RISC-V, and a fourth debug command initiated by the fourth debug tool for debugging FPGA. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer connects the first JTAG interface and the second JTAG interface in series according to the second independent debug link configuration instruction, and configures the signal routing path between the second JTAG interface and the third and fourth debug tools to form a debug link. The debug link will route the third debug command to the RISC-V DAP submodule through the second JTAG interface, so that the RISC-V DAP submodule can debug the RISC according to the third debug command, and will route the fourth debug command to the FPGA TAP submodule through the second JTAG interface, so that the FPGA TAP submodule can debug the FPGA according to the fourth debug command.

[0089] In one exemplary instance, when the debug link configuration command is a cascade debug link configuration command, the FPGA TAP submodule also includes a variety of RISC-V debugging functions. The FPGA TAP submodule is also used to call the included RISC-V debugging functions according to the debug command when the debug link routes the debug command to the submodule for RISC-V debugging, to debug the RISC-V and generate debugging results. The second JTAG interface is used to connect to the fifth debugging tool. The debugging commands include: the fifth debugging command initiated by the fifth debugging tool for debugging RISC-V and FPGA; the fifth debugging command includes: the first sub-debugging command and the second sub-debugging command, the first sub-debugging command is used to debug RISC-V, and the second sub-debugging command is used to debug FPGA. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer connects the TDI of the fifth debugging tool to the TDI of the first JTAG interface, connects the TDO of the first JTAG interface to the TDI of the second JTAG interface, and connects the TDO of the second JTAG interface to the TDO of the fifth debugging tool according to the cascaded debugging link configuration instruction, so as to form a debugging link. The debug link is used to route the fifth debug command to the RISC-V DAP submodule via the second JTAG interface, so that the RISC-V DAP submodule parses the first sub-debug command and routes the parsed first and second sub-debug commands to the FPGA TAP submodule, so that the FPGA TAP submodule debugs the RISC-V according to the parsed first sub-debug command and debugs the FPGA according to the second sub-debug command.

[0090] In one exemplary instance, the FPGA TAP submodule debugs the RISC-V according to the parsed first sub-debug command and debugs the FPGA according to the second sub-debug command in the following ways: serial debugging mode and parallel debugging mode; Among them, the serial debugging method means that the FPGA TAP submodule first debugs the RISC-V according to the parsed first sub-debugging command, and then debugs the FPGA according to the second sub-debugging command after the RISC-V is debugged; or, the FPGA is first debugged according to the second sub-debugging command, and then the RISC-V is debugged according to the parsed first sub-debugging command after the FPGA is debugged. The parallel debugging method involves the FPGA TAP submodule first debugging the RISC-V according to the parsed first sub-debugging command, and then debugging the FPGA according to the second sub-debugging command during the RISC-V debugging process; or first debugging the FPGA according to the second sub-debugging command, and then debugging the RISC-V according to the parsed first sub-debugging command during the FPGA debugging process.

[0091] In one exemplary instance, the debugging system further includes: a debugging status monitoring module; the method further includes: The debug status monitoring module detects the integrity of the debug link and monitors its status.

[0092] In one exemplary instance, the debugging system further includes: a buffer isolation circuit; the method further includes: The buffer isolation circuit isolates the different power domains of the RISC-V side and the FPGA side; a low-jitter clock buffer is added to the TCK with a frequency higher than the preset frequency threshold; and edge alignment logic is added to the input of the parallel TDI / TMS.

[0093] In one exemplary instance, the debugging system further includes: a synchronizer circuit; the method further includes: Before the parsed first sub-debug command is transmitted to the FPGA TAP submodule, the synchronizer circuit synchronizes the TMS and TDI of the first JTAG interface to the FPGA-side clock domain.

[0094] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A debugging system for RISC-V and FPGA system-on-a-chip, characterized in that, include: The system includes a control module, a multiplexer, a debugging module, and a JTAG interface. The debugging module comprises a RISC-V DAP submodule with various RISC-V debugging functions and an FPGA TAP submodule with various FPGA debugging functions. The control module is used to acquire the debug mode and send a debug link configuration command corresponding to the debug mode to the multiplexer; The multiplexer is used to configure the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link; The RISC-V DAP submodule is used to call the included RISC-V debugging function according to the debugging command when the debugging link routes the debugging command to the submodule for RISC-V debugging, to debug RISC-V and generate debugging results; The FPGA TAP submodule is used to call the included FPGA debugging function according to the debugging command when the debugging link routes the debugging command to the submodule for FPGA debugging, to debug the FPGA and generate debugging results.

2. The debugging system according to claim 1, characterized in that, The RISC-V DAP submodule includes a first JTAG interface, and the FPGA TAP submodule includes a second JTAG interface. The debugging modes include an independent debugging mode and a cascaded debugging mode. When the debugging mode is the independent debugging mode, the outgoing modes of the first JTAG interface and the second JTAG interface include a first outgoing mode and a second outgoing mode. The first outgoing mode refers to a mode in which both the first JTAG interface and the second JTAG interface are outgoing, and the second outgoing mode refers to a mode in which the first JTAG interface is not outgoing and the second JTAG interface is outgoing. When the debugging mode is the independent debugging mode, and the export mode of the first JTAG interface and the second JTAG interface is the first export mode, the debugging link configuration command is the first independent debugging link configuration command. When the debugging mode is the independent debugging mode and the export mode of the first JTAG interface and the second JTAG interface is the second export mode, the debugging link configuration command is the second independent debugging link configuration command. When the debugging mode is the cascaded debugging mode, the debugging link configuration command is the cascaded debugging link configuration command.

3. The debugging system according to claim 2, characterized in that, When the debug link configuration instruction is a first independent debug link configuration instruction, the first JTAG interface is used to connect to the first debug tool, the second JTAG interface is used to connect to the second debug tool, and the debug command includes: a first debug command initiated by the first debug tool for debugging RISC-V, and a second debug command initiated by the second debug tool for debugging FPGA; The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer configures the signal routing path between the first JTAG interface and the first debugging tool, and the signal routing path between the second JTAG interface and the second debugging tool, according to the first independent debugging link configuration instruction, so as to form the debugging link; The debug link is used to route the first debug command to the RISC-V DAP submodule through the first JTAG interface, so that the RISC-V DAP submodule can debug the RISC according to the first debug command; and to route the second debug command to the FPGA TAP submodule through the second JTAG interface, so that the FPGA TAP submodule can debug the FPGA according to the second debug command.

4. The debugging system according to claim 2, characterized in that, When the debug link configuration instruction is the second independent debug link configuration instruction, the second JTAG interface is used to connect the third debug tool and the fourth debug tool. The debug command includes: the third debug command initiated by the third debug tool for debugging RISC-V, and the fourth debug command initiated by the fourth debug tool for debugging FPGA. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer connects the first JTAG interface and the second JTAG interface in series according to the second independent debug link configuration instruction, and configures the signal routing path between the second JTAG interface and the third debug tool and the fourth debug tool to form the debug link; The debug link is used to route the third debug command to the RISC-V DAP submodule via the second JTAG interface, so that the RISC-V DAP submodule can debug the RISC according to the third debug command, and to route the fourth debug command to the FPGA TAP submodule via the second JTAG interface, so that the FPGA TAP submodule can debug the FPGA according to the fourth debug command.

5. The debugging system according to claim 2, characterized in that, When the debug link configuration command is a cascaded debug link configuration command, the FPGA TAP submodule also includes a variety of RISC-V debugging functions. The FPGA TAP submodule is also used to call the included RISC-V debugging functions according to the debug command when the debug link routes the debug command to the submodule for RISC-V debugging, to debug RISC-V and generate debugging results. The second JTAG interface is used to connect to the fifth debugging tool. The debugging command includes: a fifth debugging command initiated by the fifth debugging tool for debugging RISC-V and FPGA; the fifth debugging command includes: a first sub-debugging command and a second sub-debugging command, wherein the first sub-debugging command is used to debug RISC-V and the second sub-debugging command is used to debug FPGA. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link, including: The multiplexer connects the TDI of the fifth debugging tool to the TDI of the first JTAG interface, connects the TDO of the first JTAG interface to the TDI of the second JTAG interface, and connects the TDO of the second JTAG interface to the TDO of the fifth debugging tool according to the cascaded debugging link configuration instruction, so as to form the debugging link. The debug link is used to route the fifth debug command to the RISC-V DAP submodule via the second JTAG interface, so that the RISC-V DAP submodule parses the first sub-debug command therein, and routes the parsed first sub-debug command and the second sub-debug command to the FPGA TAP submodule, so that the FPGA TAP submodule debugs the RISC-V according to the parsed first sub-debug command, and debugs the FPGA according to the second sub-debug command.

6. The debugging system according to claim 5, characterized in that, The FPGA TAP submodule debugs the RISC-V according to the parsed first sub-debug command and debugs the FPGA according to the second sub-debug command in the following ways: serial debugging mode and parallel debugging mode; The serial debugging method refers to the FPGA TAP submodule first debugging the RISC-V according to the parsed first sub-debugging command, and then debugging the FPGA according to the second sub-debugging command after the RISC-V debugging is completed; or, debugging the FPGA according to the second sub-debugging command first, and then debugging the RISC-V according to the parsed first sub-debugging command after the FPGA debugging is completed. The parallel debugging method involves the FPGA TAP submodule first debugging the RISC-V according to the parsed first sub-debugging command, and then debugging the FPGA according to the second sub-debugging command during the RISC-V debugging process; or first debugging the FPGA according to the second sub-debugging command, and then debugging the RISC-V according to the parsed first sub-debugging command during the FPGA debugging process.

7. The debugging system according to any one of claims 1-6, characterized in that, The debugging system also includes: a debugging status monitoring module; The debugging status monitoring module is used to detect the integrity of the debugging link and monitor the status of the debugging link.

8. The debugging system according to claim 5, characterized in that, The debugging system also includes: a buffer isolation circuit; The buffer isolation circuit is used to isolate different power domains between the RISC-V side and the FPGA side; it is also used to add a low-jitter clock buffer to TCK with a frequency higher than a preset frequency threshold; and it is also used to add edge alignment logic to the input of the parallel TDI / TMS.

9. The debugging system according to claim 5, characterized in that, The debugging system also includes: a synchronizer circuit; The synchronizer circuit is used to synchronize the TMS and TDI of the first JTAG interface to the FPGA-side clock domain before the parsed first sub-debugging command is transmitted to the FPGA TAP submodule.

10. A debugging method for RISC-V and FPGA system-on-a-chip, characterized in that, A debugging system for RISC-V and FPGA system-on-a-chip as described in any one of claims 1-9, the method comprising: The control module acquires the debug mode and sends a debug link configuration command corresponding to the debug mode to the multiplexer. The multiplexer configures the signal routing paths of the RISC-V DAP submodule and the FPGA TAP submodule according to the debug link configuration instructions to form a debug link; When the debug link routes the debug command to the submodule for RISC-V debugging, the RISC-V DAP submodule invokes the included RISC-V debug function according to the debug command to debug RISC-V and generate debug results. When the debug link routes the debug command to the FPGA TAP submodule for FPGA debugging, the FPGA TAP submodule calls the included FPGA debugging functions according to the debug command to debug the FPGA and generate debug results.

Images