Multi-core NPU debugging information collection and time synchronization method

Abstract

This application relates to the field of data processing technology, and provides a method for multi-core NPU debugging information acquisition and time synchronization. It synchronously resets the timers of each debugging acquisition unit through a global hardware clear signal line, ensuring that all timers start counting synchronously on the same clock edge. When the count value jumps from its maximum value to zero, a toggle record data packet is generated and written to external memory. Hardware events in each neural network processing unit core and inter-core communication module are captured, encapsulated into debug data packets according to a predefined format, and arbitrated according to a fixed priority order for each data packet. Applying this technical solution, software delay errors are eliminated through hardware-level time synchronization; chip area and power consumption are reduced through the toggle record mechanism; and a unified format and channel enable full coverage acquisition of heterogeneous information of various types, including microinstructions, synchronization instructions, cyclic redundancy checks, and on-chip memory accesses, improving the system observability of the NPU chip during startup debugging and performance tuning phases.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method for collecting debugging information and synchronizing time for a multi-core NPU. Background Technology

[0002] With the explosive growth in demand for large-scale model inference, AI (Artificial Intelligence) inference chips integrating multiple NPU (Neural Processing Unit) computing cores and dedicated inter-core communication modules have become the mainstream architecture. During the debugging and performance optimization of AI inference chips, accurately collecting the internal operating status of each computing core and communication module, and performing time-aligned analysis of cross-core events, is crucial to ensuring rapid mass production and optimizing inference efficiency.

[0003] In existing technologies, debugging tools primarily achieve debugging functionality through software instrumentation and performance counter sampling at the driver level. These approaches not only significantly intrude on the performance of the task being debugged but also struggle to capture the nanosecond-level micro-instruction timing at the hardware level. Furthermore, some NPUs employ debugging schemes that typically use independent debugging information acquisition units and generate timestamps using local counters with fixed bit widths. However, these methods suffer from the following drawbacks: First, to address the timestamp counter flipping problem, existing technologies typically employ a solution that increases the counter bit width (e.g., extends it to 64 bits) to circumvent it. However, this significantly increases chip area and power consumption in NPU scenarios where hardware resources are limited. If a solution is adopted where software periodically reads the high-order counter bits, frequent software intervention will introduce latency, making it easy to lose flipping events in high-precision timing analysis scenarios and failing to accurately reconstruct absolute time.

[0004] Secondly, in terms of multi-core time synchronization, existing solutions mostly rely on software writing or protocols such as IEEE 1588 PTP for synchronization. Due to software execution delay and bus transmission delay, the synchronization error is usually at the microsecond level, which cannot meet the micro-instruction timing analysis requirements of nanosecond precision inside the NPU.

[0005] Finally, existing processor debugging solutions typically only support program counter tracing or single event types, lacking the ability to uniformly collect and time-align various heterogeneous debugging information unique to the NPU, such as microinstruction execution times, synchronization instructions, cyclic redundancy check results, and on-chip memory read / write addresses. This results in insufficient debugging visibility and makes it difficult to fully locate system bottlenecks. Summary of the Invention

[0006] This application provides a method for collecting and synchronizing debugging information for a multi-core NPU, which solves the problems of high overhead in the processing of timestamp counter flipping in multi-core NPUs, insufficient accuracy of multi-core time synchronization, and difficulty in uniformly collecting heterogeneous debugging information in the prior art.

[0007] This application provides a method for acquiring debugging information and synchronizing time in a multi-core NPU. This method is applied to a hardware structure including multiple NPU cores and an inter-core communication module, where each NPU core and inter-core communication module is equipped with a debugging acquisition unit. The method includes: In response to the received debug start command, the timers of each debug acquisition unit are synchronously reset through the global hardware clear signal line, so that each timer starts counting synchronously on the same clock edge; Monitor the timer's count value. When the count value jumps from the maximum value to zero, control the debugging acquisition unit to generate a flip record data packet that includes the current flip count value and the current timestamp, and write the flip record data packet to the external memory. Capture hardware events in each NPU core and the inter-core communication module, and encapsulate the hardware events into corresponding debug data packets according to a predefined format; Arbitration selection is performed on each debug data packet and flip record data packet according to a preset fixed priority order, and the selected output data packet is written to external memory through the direct memory access channel.

[0008] This approach, using a global hardware reset signal line to achieve hardware-level synchronous startup of timers for each neural network processing unit core and inter-core communication module, helps eliminate errors caused by instruction execution latency and bus transmission latency in software synchronization schemes, providing a unified and accurate time reference for causal analysis of multi-core parallel inference tasks. Simultaneously, by introducing a flip-record data packet mechanism, compared to directly expanding the counter bit width, it helps reduce chip area and power consumption. Furthermore, by defining a unified debug data packet format and transmission channel, it achieves full coverage acquisition of various types of heterogeneous debug information, including microinstructions, synchronization instructions, cyclic redundancy checks, and on-chip memory accesses, improving the system observability of the NPU chip during the startup debugging and performance tuning phases.

[0009] In some embodiments, the step of synchronously resetting the timers of each debugging acquisition unit via a global hardware reset signal line includes: Set the global hardware clear signal line to an active level to reset the timers of each debugging and acquisition unit to zero. After maintaining an active level for at least one clock cycle, the global hardware clear signal line is set to an inactive level, and each timer starts counting synchronously on the same clock edge when the global hardware clear signal line is set to an inactive level.

[0010] In this way, by controlling the global reset signal logic by first setting it to 1 and then to 0, and ensuring that the effective level is maintained for at least one full clock cycle, the problem of some timers failing to reset due to metastability in cross-clock domain reset signals is effectively solved. This ensures that all timers start counting uniformly on the same clock edge when an invalid level is detected, strictly controlling the timing deviation between multiple cores within a single clock cycle, thereby achieving extremely high-precision hardware-level time alignment and laying a solid physical foundation for subsequent complex cross-core microinstruction timing analysis.

[0011] In some embodiments, the multi-core NPU debugging information acquisition and time synchronization method further includes: Each debugging and acquisition unit maintains its own toggle counter; In response to the debug start command and after the synchronous reset is completed, an initial flip record data packet including the initial flip count value and the initial timestamp is generated and written to the external memory; During the timer counting process, monitor the timer count value of any debugging acquisition unit. When the count value jumps from the maximum value to zero, control the debugging acquisition unit to increment its own toggle counter by 1. The incremented flip count value is used as the high-order extension value and encapsulated together with the currently captured timestamp into the flip record data packet.

[0012] In this way, by configuring an independent toggle counter for each debugging acquisition unit and automatically generating an initial toggle record data packet at the start of debugging, a definite time anchor point is provided for software parsing. This not only solves the problem of the absolute time being uncertain after a timer toggle, but also avoids the performance overhead and risk of missing toggle events caused by frequent polling of the high bits of the counter by the hardware-automatic incrementing of the toggle counter and recording the current timestamp. Even in long-running inference tasks, the software can accurately and unambiguously reconstruct the global absolute timestamp of any event based on the initial value and incrementing pattern.

[0013] In some embodiments, the debug data packet includes at least one of microinstruction execution logging data, synchronous instruction tracing data, cyclic redundancy check result data, and on-chip memory access data. The default fixed priority order is: The priority of the flip record data packet is higher than the priority of the scheduler timestamp data packet; The scheduler timestamp data packet has a higher priority than the microinstruction execution data packet, the synchronization instruction tracking data packet, and the cyclic redundancy check result data packet. The priority of microinstruction execution dotted data packets, the priority of synchronization instruction tracking data packets, and the priority of cyclic redundancy check result data packets are higher than the priority of on-chip memory access data packets.

[0014] In this way, by setting a four-level fixed priority arbitration order, it is ensured that the most critical time reference information and process skeleton information can be transmitted first in time-sensitive or bandwidth-contested scenarios, avoiding the loss of critical debugging information due to the blockage of channels by a large number of low-priority on-chip memory access data.

[0015] In some embodiments, arbitration selection is performed on each debug data packet and flip record data packet according to a preset fixed priority order, including: The first-level arbitrator uses a polling method to arbitrate micro-instruction execution data packets, synchronization instruction tracking data packets, and cyclic redundancy check result data packets of the same priority, and outputs the first arbitration result. The second-level arbitrator arbitrates the flip record data packet, the scheduler timestamp data packet, the first arbitration result, and the on-chip memory access data packet in a fixed priority order, and outputs the final selection result.

[0016] This two-tiered arbitration architecture, employing both round-robin with equal priority and fixed priority across different priorities, ensures the absolute priority of high-priority data while achieving fair bandwidth allocation among data sources of equal priority through the first-level round-robin arbitration mechanism. This effectively avoids the problem of other important data sources being overwhelmed by excessive traffic from one data source of the same priority, ensuring both arbitration efficiency and comprehensive data collection, and optimizing the integrity of overall debugging information.

[0017] In some embodiments, the header of the debug data packet includes a 2-bit type identifier field, which distinguishes debug data packets of different data types. The microinstruction execution tracking data packet includes the functional unit identifier, tracking type identifier, task identifier, and the timestamp corresponding to the microinstruction execution time. The synchronization instruction tracking data packet includes a functional unit identifier, a synchronization instruction field, and a timestamp corresponding to the execution time of the synchronization instruction. The cyclic redundancy check result data packet contains the functional unit identifier, task identifier, and check result; The on-chip memory access data packet includes the functional unit identifier, access address, read / write direction, and timestamp corresponding to the memory access time; The header of the flip record data packet contains a 2-bit type identifier field, a flip count value, and a timestamp corresponding to the flip time.

[0018] In this way, by defining a unified data packet format including a 2-bit type identifier field, the hardware can assemble data packets with extremely simple logic, while facilitating rapid parsing and classification by the software. Customized field designs for different types of debugging information maximize the retention of contextual information for various hardware events while ensuring information density, providing rich data support for subsequent detailed performance profiling and error tracing.

[0019] In some embodiments, writing the selected output data packet to external memory via a direct memory access channel includes: Based on the pre-configured burst length parameters, the data selected by arbitration is written to the designated address space of the external memory using the AXI bus burst transmission method; When no new arbitration selection data is received for several consecutive clock cycles, the idle timeout mechanism is triggered, and the data already buffered in the current buffer is rounded up to the bus width before a single transmission is initiated. Monitor the storage status of each data buffer, and when the data buffer corresponding to any debugging acquisition unit overflows, generate and store the corresponding buffer overflow status identifier; Monitor bus transmission status, and when a bus transmission error occurs, generate and store the corresponding bus error status identifier.

[0020] In this way, by configuring AXI burst transmission and idle timeout mechanisms, bus bandwidth utilization is improved, the number of bus transaction interactions is reduced, and the power consumption and latency of external memory access are lowered. Simultaneously, by setting independent overflow status registers and bus error status registers, comprehensive hardware monitoring of the data transmission process is achieved. This allows the software to explicitly detect data loss or transmission anomalies, enabling accurate assessment of data integrity during analysis and debugging, and avoiding erroneous performance analysis conclusions due to implicit data loss.

[0021] In some embodiments, the marker type identifier of the microinstruction execution marker data packet includes a segment start identifier and a segment end identifier, wherein the segment start identifier is generated when the NPU core's task starts and the segment end identifier is generated when the NPU core's task execution is completed; the synchronization instruction tracking data packet is generated when the synchronization management module executes a wait-type or update-type synchronization instruction.

[0022] In this way, by refining the micro-instruction to the start and end of segments and precisely tracing synchronization instructions, the debugging system can capture the micro-timing details of NPU task scheduling and inter-core synchronization. This provides nanosecond-level execution trajectories for analyzing multi-core load balancing, identifying pipeline bubbles, and locating synchronization deadlocks, enhancing the debugging tools' ability to analyze complex parallel computing tasks.

[0023] In some embodiments, the multi-core NPU debugging information acquisition and time synchronization method further includes: Read the flip record data packet and debug data packet from external storage; Maintain the current flip count value and iterate through the flip record data packets and debug data packets read in chronological order; When the timestamp of the current debug data packet is less than the timestamp of the previous parsed record, and the current debug data packet is not a flip record data packet, it is determined that a timer flip has occurred, and the current flip count value is updated based on the flip count value carried in the flip record data packet. Calculate the absolute timestamp corresponding to the current debug data packet based on the current toggle count value and the timestamp carried by the current debug data packet.

[0024] In this way, the provided software-side absolute time reconstruction method uses the hardware-generated flip records as a reference, and by detecting timestamp wrap-around and dynamically correcting the flip count value, it successfully maps the discrete timestamps scattered in each NPU core and each flip cycle onto a continuous global time axis.

[0025] In some embodiments, after reading the flip record data packet and the debug data packet from external memory, the method further includes: Identify the type identifier field in the flip record data packet to distinguish it from the debug data packet; Extract the initial flip count value from the first flip record data packet to calibrate the initial value of the current flip count value.

[0026] In this way, by extracting the initial flip count value from the first flip record data packet, the initial values ​​of the software's parsed variables are calibrated, resolving the parsing baseline offset issue caused by multiple flips of the timer before debugging begins. This ensures that even in test environments with long-term operation or repeated start-stop cycles, the absolute timestamps parsed by the software maintain global consistency and accuracy, further enhancing the robustness and reliability of debug data analysis.

[0027] This application provides a method for multi-core NPU debugging information acquisition and time synchronization, including: in response to receiving a debug start command, synchronously resetting the timers of each debug acquisition unit through a global hardware clear signal line, so that each timer starts counting synchronously on the same clock edge; monitoring the count value of the timer, and when the count value jumps from the maximum value to zero, controlling the debug acquisition unit to generate a toggle record data packet including the current toggle count value and the current timestamp, and writing the toggle record data packet to external memory; capturing hardware events in each NPU core and the inter-core communication module, and encapsulating the hardware events into corresponding debug data packets according to a predefined format; arbitrating and selecting each debug data packet and toggle record data packet according to a preset fixed priority order, and writing the selected output data packet to external memory through a direct memory access channel.

[0028] This approach, using a global hardware reset signal line to achieve hardware-level synchronous startup of timers for each neural network processing unit core and inter-core communication module, helps eliminate errors caused by instruction execution latency and bus transmission latency in software synchronization schemes, providing a unified and accurate time reference for causal analysis of multi-core parallel inference tasks. Simultaneously, by introducing a flip-record data packet mechanism, compared to directly expanding the counter bit width, it helps reduce chip area and power consumption. Furthermore, by defining a unified debug data packet format and transmission channel, it achieves full coverage acquisition of various types of heterogeneous debug information, including microinstructions, synchronization instructions, cyclic redundancy checks, and on-chip memory accesses, improving the system observability of the NPU chip during the startup debugging and performance tuning phases. Attached Figure Description

[0029] To more clearly illustrate the implementation methods in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0030] Figure 1 A flowchart illustrating a method for acquiring debugging information and synchronizing time in a multi-core NPU, as provided in this application embodiment. Figure 1 ; Figure 2 A flowchart illustrating a method for acquiring debugging information and synchronizing time in a multi-core NPU, as provided in this application embodiment. Figure 2 ; Figure 3 A flowchart illustrating a method for acquiring debugging information and synchronizing time in a multi-core NPU, as provided in this application embodiment. Figure 3 ; Figure 4 A flowchart illustrating a method for acquiring debugging information and synchronizing time in a multi-core NPU, as provided in this application embodiment. Figure 4 ; Figure 5 A flowchart illustrating a method for acquiring debugging information and synchronizing time in a multi-core NPU, as provided in this application embodiment. Figure 5 . Detailed Implementation

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

[0032] It should be noted that many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

[0033] This application provides a hardware debugging information acquisition and time synchronization method for multi-core NPUs. The method is applied to a hardware architecture including multiple NPU cores and an inter-core communication module. The hardware architecture used in this application includes multiple NPU cores and a global inter-core communication module. Each NPU core and the global inter-core communication module has an independent debugging acquisition unit internally.

[0034] like Figure 1 As shown, the method for collecting debugging information and synchronizing time for a multi-core NPU includes steps S110 to S140.

[0035] In step S110, in response to receiving the debug start command, the timers of each debug acquisition unit are synchronously reset through the global hardware clear signal line, so that each timer starts counting synchronously on the same clock edge.

[0036] In response to the debug start command issued by the host computer, the driver software triggers the global hardware reset signal line through the configuration register. The global hardware reset signal line is a dedicated physical hardware connection, connected to both the timer reset terminal inside the global inter-core communication module and the timer reset terminal inside the debug acquisition unit of all NPU cores. This solves the problem of inconsistent multi-core time bases caused by software synchronization delays in existing technologies, achieving hardware-level synchronization start control.

[0037] Step S120: Monitor the timer's count value. When the count value jumps from the maximum value to zero, control the debugging acquisition unit to generate a flip record data packet including the current flip count value and the current timestamp, and write the flip record data packet to the external memory.

[0038] The system monitors the count values ​​of M-bit (e.g., 32-bit) free-running timers within each debugging acquisition unit. When the count value of any timer jumps from its maximum value (e.g., 32'hFFFF_FFFF) to zero, i.e., when the count value overflows (i.e., jumps from an all-1 state to an all-0 state), it indicates that the timer has toggled. At this time, the hardware comparator inside the debugging acquisition unit automatically triggers the toggle recording logic, controlling the debugging acquisition unit to generate a toggle recording data packet. The toggle recording data packet includes the current value of the N-bit (typically 32-bit) toggle counter maintained by the debugging acquisition unit and an M-bit timestamp indicating the time of the toggle.

[0039] The toggle record data packets are written to external memory, such as Double Data Rate Synchronous Dynamic Random-Access Memory (DDR). This solves the problem of indistinguishable absolute time after a finite-width timer toggle, significantly reducing hardware overhead compared to extending the counter bit width.

[0040] Step S130: Capture hardware events in each NPU core and the inter-core communication module, and encapsulate the hardware events into corresponding debug data packets according to a predefined format.

[0041] The debug data package includes at least one of the following: microinstruction execution tracking data, synchronous instruction tracing data, cyclic redundancy check result data, and on-chip memory access data.

[0042] It should be noted that after synchronously resetting the timers of each debug acquisition unit via the global hardware reset signal line, the timer count values ​​are monitored in real time to ensure that each debug acquisition unit captures hardware events in real time. Hardware events are encapsulated into corresponding debug data packets according to a predefined, unified format. For example, the Execution Unit (EU) within the NPU core generates microinstruction execution tracking data when a task starts or completes; the Synchronization Manager (SM) generates synchronization instruction trace data when executing wait-type or update-type synchronization instructions; and the Execution Unit generates cyclic redundancy check result data during data read / write operations. The on-chip memory controller generates access data when the monitored address range conditions are met.

[0043] Step S140: Arbitrate and select each debug data packet and flip record data packet according to a preset fixed priority order, and write the selected output data packet to the external memory through the direct memory access channel.

[0044] Based on a preset fixed priority order, each debug data packet and toggle record data packet is arbitrated for selection. After the arbitration module outputs the selection result, the write direct memory access module writes the selected data packet to the designated address space of external memory via the AXI (Advanced eXtensible Interface) bus. The process of writing the arbitrated debug data packet and toggle record data packet to external memory through the direct memory access channel does not require CPU software intervention, ensuring low intrusion of the debugging process on the inference task.

[0045] This approach, using a global hardware reset signal line to achieve hardware-level synchronous startup of timers for each neural network processing unit core and inter-core communication module, helps eliminate errors caused by instruction execution latency and bus transmission latency in software synchronization schemes, providing a unified and accurate time reference for causal analysis of multi-core parallel inference tasks. Simultaneously, by introducing a flip-record data packet mechanism, compared to directly expanding the counter bit width, it helps reduce chip area and power consumption. Furthermore, by defining a unified debug data packet format and transmission channel, it achieves full coverage acquisition of various types of heterogeneous debug information, including microinstructions, synchronization instructions, cyclic redundancy checks, and on-chip memory accesses, improving the system observability of the NPU chip during the startup debugging and performance tuning phases.

[0046] In some embodiments, such as Figure 2 As shown, the steps for synchronously resetting the timers of each debugging acquisition unit through the global hardware clear signal line include steps S210 to S220.

[0047] Step S210: Set the global hardware clear signal line to an active level so that the timers of each debugging acquisition unit are reset to zero.

[0048] To address the errors introduced by software synchronization, this application employs a pure hardware signal synchronization mechanism. Specifically, the driver software first sets the global hardware clear signal line to an active level (e.g., high level). This active level signal is fanned out to all debugging and acquisition units via a dedicated wiring network, forcing the M-bit timer in all debugging and acquisition units to reset to zero.

[0049] In step S220, after maintaining the active level for at least one clock cycle, the global hardware clear signal line is set to an inactive level, and each timer starts counting synchronously on the same clock edge when the global hardware clear signal line is set to an inactive level.

[0050] To ensure the reset signal can be stably sampled across all clock domains, the system maintains this valid level for at least one global clock cycle. The driver software then sets the global hardware clear signal line to an invalid level (e.g., low). Upon detecting this invalid level on the same rising edge of the clock, the timers in all debug acquisition units synchronously release the reset state and begin incrementing. Because the propagation delay of the reset signal is balanced during physical routing, the counting deviation between timers is controlled within a single clock cycle (typically on the nanosecond level), thus achieving extremely high precision in global time base unification.

[0051] In this way, by controlling the global reset signal logic by first setting it to 1 and then to 0, and ensuring that the effective level is maintained for at least one full clock cycle, the problem of some timers failing to reset due to metastability in cross-clock domain reset signals is effectively solved. This ensures that all timers start counting uniformly on the same clock edge when an invalid level is detected, strictly controlling the timing deviation between multiple cores within a single clock cycle, thereby achieving extremely high-precision hardware-level time alignment and laying a solid physical foundation for subsequent complex cross-core microinstruction timing analysis.

[0052] In some embodiments, to accurately record flip events, each debug acquisition unit maintains an independent N-bit flip counter. That is, each debug acquisition unit maintains its own flip counter.

[0053] During the debug startup phase, in response to the debug startup command and after the global timer synchronous reset is completed, the hardware logic automatically generates a special initial toggle record data packet. The initial toggle record data packet includes an initial toggle count value (e.g., 0x00) and an initial timestamp (the first timestamp after the reset is completed). The initial toggle record data packet is preferentially written to external memory as the absolute time reference anchor point during software parsing.

[0054] It should be noted that the initial flip record data packet and the flip record data packet have the same data packet format, the only difference being that the content of the data packet is 0 or a specific value.

[0055] After the timer enters the free-running phase, during the timer counting process, the timer count value of any debug acquisition unit is monitored. The hardware logic continuously monitors the timer count value of any debug acquisition unit. When a toggle event is detected where the count value jumps from the maximum value to zero, the debug acquisition unit increments its own toggle counter by 1. The incremented toggle count value is then used as the high-order extension value of the timer and assembled with the currently captured M-bit timestamp to form a toggle record data packet. This means that the toggle record data packet is encapsulated along with the latest current timestamp in the timing sequence. This ensures that even with frequent timer toggles, the software can accurately reconstruct the 64-bit or wider absolute timestamp by accumulating the toggle counter.

[0056] In this way, by configuring an independent toggle counter for each debugging acquisition unit and automatically generating an initial toggle record data packet at the start of debugging, a definite time anchor point is provided for software parsing. This not only solves the problem of the absolute time being uncertain after a timer toggle, but also avoids the performance overhead and risk of missing toggle events caused by frequent polling of the high bits of the counter by the hardware-automatic incrementing of the toggle counter and recording the current timestamp. Even in long-running inference tasks, the software can accurately and unambiguously reconstruct the global absolute timestamp of any event based on the initial value and incrementing pattern.

[0057] In some embodiments, to ensure that critical debugging information is not lost, this application defines a four-level priority architecture based on the importance of events.

[0058] The default fixed priority order is: The priority of the flip record data packet is higher than the priority of the scheduler timestamp data packet.

[0059] The scheduler timestamp data packet has a higher priority than the microinstruction execution data packet, the synchronization instruction tracking data packet, and the cyclic redundancy check result data packet.

[0060] The priority of microinstruction execution dotted data packets, the priority of synchronization instruction tracking data packets, and the priority of cyclic redundancy check result data packets are higher than the priority of on-chip memory access data packets.

[0061] The highest priority is allocated to the flip record data packet. This is because if the flip record is lost, the parsing of all subsequent timestamps will fail, rendering the entire debug data invalid. The second highest priority is allocated to the scheduler timestamp data packet. The scheduler is responsible for allocating tasks and resources, and its timestamp data is crucial information for reconstructing the inference process framework. The third highest priority (equivalent to the first highest priority) is allocated to the microinstruction execution timestamp data packet, the synchronization instruction trace data packet, and the on-chip memory result data packet. This data directly reflects the execution status and result correctness of the computation core, and is essential for performance analysis and error localization. The lowest priority is allocated to the on-chip memory access data packet. While on-chip memory access data is large, its importance in timing analysis is relatively low.

[0062] In this way, by setting a four-level fixed priority arbitration order, it is ensured that in time-sensitive or bandwidth-contested scenarios, the most critical time reference information (flip record) and process skeleton information (scheduler marker) can be transmitted first, avoiding the loss of critical debugging information due to the blockage of channels by a large number of low-priority on-chip memory access data.

[0063] In some embodiments, such as Figure 3As shown, arbitration selection is performed on each debug data packet and flip record data packet according to a preset fixed priority order, including steps S310 to S320.

[0064] In step S310, the first-level arbitrator arbitrates the micro-instruction execution dotted data packets, synchronization instruction tracking data packets, and cyclic redundancy check result data packets under the same priority using a polling method, and outputs the first arbitration result.

[0065] The first-level arbitrator receives three types of input data streams of equal priority: microinstruction execution tracking data packets, synchronization instruction tracking data packets, and cyclic redundancy check result data packets. Internally, the first-level arbitrator employs a round-robin arbitration algorithm to allocate outbound bandwidth to these three data sources, preventing starvation due to excessive traffic from one data source.

[0066] The arbitration result (first arbitration result) output by the first-level arbitrator, along with the flip record data packet, the scheduler timestamp data packet, and the on-chip memory access data packet, are input to the second-level arbitrator.

[0067] In step S320, the second-level arbitrator arbitrates the flip record data packet, the scheduler timestamp data packet, the first arbitration result, and the on-chip memory access data packet in a fixed priority order, and outputs the final selection result.

[0068] The second-level arbitrator arbitrates step-by-step according to a fixed priority order. For example, the second-level arbitrator is implemented using combinational logic comparators to ensure that the final winning data packet can be determined within one clock cycle and sent to the write buffer of the write direct memory access module.

[0069] This two-tiered arbitration architecture, employing both round-robin with equal priority and fixed priority across different priorities, ensures the absolute priority of high-priority data (such as flipped records) while achieving fair bandwidth allocation among data sources of equal priority (microinstructions, synchronization instructions, and cyclic redundancy checks) through the first-level round-robin arbitration mechanism. This effectively avoids the problem of other important data sources being starved due to excessive traffic from one data source of the same priority, ensuring arbitration efficiency while maintaining the comprehensiveness of data collection and optimizing the integrity of overall debugging information.

[0070] To ensure the integrity of debug data and provide hardware-level observability, this application configures a fine-grained status monitoring and reporting mechanism in the write direct memory access module. Specifically, for each debug data input channel, including microinstruction execution logging, synchronous instruction tracing, cyclic redundancy check results, on-chip memory access, and timer toggle recording, the write direct memory access module has an independent overflow status register (OSR).

[0071] Each channel's overflow flag register has a write-1-to-clear (w1c) attribute. When the arbitration module selects a channel to write data to the write buffer of the direct memory access module, if it detects that the write buffer for that channel is full and new data is still attempting to be written, the hardware automatically sets the corresponding overflow flag in the overflow flag register of that channel to logic 1. The overflow flag register can be read by configuring periodic polling or interrupt mode on the bus; if the overflow flag of a certain channel is read as 1, it can be accurately determined that data loss has occurred during the acquisition of this type of debugging information, and the flag can be cleared by writing 1 to reset the monitoring state.

[0072] In addition, the write direct memory access module is configured with a global bus error status register (BESR) on the Advanced Extensible Interface (AXI) bus master interface side. When the write direct memory access module writes data to external memory via the AXI bus, if it receives a DECERR (decoding error) or SLVERR (slave error) response from the slave device, the hardware automatically captures the error signal, sets the Bus Error Valid (BEV) bit in the bus error status register to 1, and latches the address and control information of the currently failed AXI transaction to an auxiliary field. The bus error status register also has the attribute of clearing to 1 by writing to 1. After the software responds to an interrupt or polls the register, it can obtain detailed error reasons and clear the error status by writing to 1 to restore system operation.

[0073] Through the above mechanism, this application achieves a refined distinction of the causes of data loss: the software can determine that data loss originates from internal bandwidth congestion through the overflow flag register, and that data loss originates from external storage system failure through BESR. This explicit hardware anomaly reporting and standard register read / write interface greatly improve the robustness and diagnosability of the debugging system, ensuring that debugging personnel can accurately assess data integrity and avoid erroneous performance analysis conclusions due to implicit data loss.

[0074] In some embodiments, in order to achieve unified acquisition, all data packets adopt a unified header structure. The header contains a 2-bit type identifier field, which distinguishes debug data packets of different data types.

[0075] For example, when the type identifier field is 2'b00, the functional unit identifier further distinguishes them: when the functional unit identifier is an execution unit, it indicates a microinstruction execution tracking data packet; when the functional unit identifier is a synchronization management module, it indicates a synchronization instruction tracking data packet. That is, microinstruction tracking data packets and synchronization instruction tracking data packets share the same type identifier field (e.g., 00), and the functional unit identifier further distinguishes whether it is a microinstruction tracking data packet or a synchronization instruction tracking data packet.

[0076] The microinstruction execution tracking data packet includes the functional unit identifier, tracking type identifier, task identifier, and a timestamp corresponding to the microinstruction execution time. The synchronization instruction tracking data packet includes the functional unit identifier, synchronization instruction field, and a timestamp corresponding to the synchronization instruction execution time.

[0077] When the type identifier field is 2'b01, it indicates a cyclic redundancy check result data packet, which contains the functional unit identifier, task identifier, and check result.

[0078] When the type identifier field is 2'b10, it indicates an on-chip memory access data packet. The on-chip memory access data packet contains the functional unit identifier, access address, read / write direction, and timestamp corresponding to the memory access time.

[0079] When the type identifier field is 2'b11, it indicates that the timer toggles the record data packet. The toggles record data packet contains the toggles count value and the timestamp corresponding to the toggles time.

[0080] In this way, by defining a unified data packet format including a 2-bit type identifier field, the hardware can assemble data packets with extremely simple logic, while facilitating rapid parsing and classification by the software. Customized field designs for different types of debugging information maximize the retention of contextual information for various hardware events while ensuring information density, providing rich data support for subsequent detailed performance profiling and error tracing.

[0081] In some embodiments, to improve bus utilization and ensure data integrity, such as Figure 4 As shown, the selected output data packet is written to external memory through a direct memory access channel, including steps S410 to S440.

[0082] Step S410: According to the pre-configured burst length parameter, write the data selected by arbitration into the specified address space of the external memory in the AXI bus burst transmission mode.

[0083] The write direct memory access module supports configurable burst length. When the amount of data cached in the write buffer reaches the configured burst length threshold, the write direct memory access module initiates an AXI burst write transaction to efficiently write the data to the specified address space of external memory, reducing bus handshake overhead.

[0084] Step S420: When no new arbitration selected data is received for several consecutive clock cycles, the idle timeout mechanism is triggered, and the data already cached in the current buffer is rounded up to the bus width before a single transmission is initiated.

[0085] The write direct memory access module has a built-in idle timeout mechanism. When no new arbitration selected data is received within the pre-configured idle timeout period (e.g., 128 clock cycles), the write direct memory access module will round up the data already cached in the current buffer to the AXI bus width (e.g., 512 bits) and initiate a single transmission to prevent a small amount of residual data from being stuck for a long time and causing parsing delay.

[0086] Step S430: Monitor the storage status of each data buffer. When the data buffer corresponding to any debugging acquisition unit overflows, generate and store the corresponding buffer overflow status identifier.

[0087] The direct memory access module monitors the data buffer level and bus response status of each channel in real time to monitor the storage status of each data buffer. When the data buffer corresponding to any debugging acquisition unit overflows, it generates and stores the corresponding buffer overflow status identifier.

[0088] Step S440: Monitor the bus transmission status. When a bus transmission error occurs, generate and store the corresponding bus error status identifier.

[0089] When the AXI bus returns an error response (such as an AXI bus slave device error response or a decoding error response), a corresponding bus error status flag is generated and stored, and the bus error status register is set. Software can accurately detect packet loss or transmission anomalies during debugging by reading these status registers, ensuring the accuracy of debugging conclusions.

[0090] In this way, by configuring AXI burst transmission and idle timeout mechanisms, bus bandwidth utilization is improved, the number of bus transaction interactions is reduced, and the power consumption and latency of external memory access are lowered. Simultaneously, by setting independent overflow status registers and bus error status registers, comprehensive hardware monitoring of the data transmission process is achieved. This allows the software to explicitly detect data loss or transmission anomalies, enabling accurate assessment of data integrity during analysis and debugging, and avoiding erroneous performance analysis conclusions due to implicit data loss.

[0091] In some embodiments, the marker type identifier of the microinstruction execution marker data packet includes a segment start identifier and a segment end identifier, wherein the segment start identifier is generated when the NPU core's task starts and the segment end identifier is generated when the NPU core's task execution is completed; the synchronization instruction tracking data packet is generated when the synchronization management module executes a wait-type or update-type synchronization instruction.

[0092] When an execution unit receives a new task assigned by the scheduler and begins execution, a segment is started with a marker, and the corresponding marker type identifier is set to a specific value (such as 0x1). When all microinstructions of the task have been executed, the segment ends with a marker, and the corresponding marker type identifier is set to another specific value (such as 0x2). This segmented marker mechanism allows the software to accurately calculate the execution time of each task.

[0093] Meanwhile, the synchronization management module records key points and generates synchronization instruction trace data packets when performing cross-core or intra-core synchronization operations. When executing wait-type instructions, blocking the current pipeline until the synchronization condition is met, a synchronization instruction trace data packet is generated; similarly, when the synchronization management module executes update-type instructions, notifying other waiting units that the synchronization condition has been met, a data packet is also generated. These data packets record the synchronization instruction fields and the timestamp of the execution time, providing crucial information for analyzing dependencies and deadlock issues during multi-core parallel execution.

[0094] In this way, by refining the micro-instruction to the start and end of segments and precisely tracing synchronization instructions, the debugging system can capture the micro-timing details of NPU task scheduling and inter-core synchronization. This provides nanosecond-level execution trajectories for analyzing multi-core load balancing, identifying pipeline bubbles, and locating synchronization deadlocks, enhancing the debugging tools' ability to analyze complex parallel computing tasks.

[0095] In some embodiments, since the hardware only records relative timestamps with a limited bit width, the software needs to perform post-processing to restore the true timing sequence. For example... Figure 5 As shown, the synchronization method also includes steps S510 to S540.

[0096] Step S510: Read the flip record data packet and debug data packet from the external memory.

[0097] The offline parsing tool reads all raw debug data packets and flip log data packets from external storage. The parsing tool maintains a global current flip count value.

[0098] Step S520: Maintain the current flip count value and iterate through the read flip record data packets and debug data packets in chronological order.

[0099] Step S530: When the timestamp of the current debug data packet is less than the timestamp of the previous parsed record, and the current debug data packet is not a flip record data packet, it is determined that a timer flip has occurred, and the current flip count value is updated based on the flip count value carried in the flip record data packet.

[0100] The parsing tool traverses all data packets in chronological order of timestamps. When a debug data packet is encountered, the tool compares its timestamp with that of the previously parsed debug data packet, excluding the current debug data packet which is not a wraparound record. If the current timestamp is found to be less than the previous timestamp (i.e., a wraparound has occurred), the tool determines that a timer has toggled and updates the current toggle count based on the toggle count carried in the toggle record data packet.

[0101] Step S540: Calculate the absolute timestamp corresponding to the current debug data packet based on the current flip count value and the timestamp carried by the current debug data packet.

[0102] Specifically, first, the bit width M of the timer is obtained; then, the current toggle count value is shifted left by M bits, and a logical OR operation is performed with the timestamp carried in the current debug data packet. The result is then determined as the absolute timestamp. In this way, discrete timestamps scattered across multiple cores and multiple toggle cycles can be uniformly mapped onto a continuous global timeline, thereby enabling precise causal analysis of cross-core events.

[0103] Wherein, M is the bit width of the free-running timer, and in one embodiment of this application, M=32, but is not limited thereto; N is the bit width of the toggle counter, and in one embodiment of this application, N=8, but is not limited thereto.

[0104] In this way, the provided software-side absolute time reconstruction method uses the hardware-generated flip records as a reference, and by detecting timestamp wrap-around and dynamically correcting the flip count value, it successfully maps the discrete timestamps scattered in each NPU core and each flip cycle onto a continuous global time axis.

[0105] In practical applications, to address the technical problem that the low 32-bit timestamp of the flip record data packet itself (usually a very small value) is easily misjudged as a normal data packet timestamp wrap-around, leading to repeated accumulation of the flip counter and incorrect calculation of the absolute timestamp, this application also provides a specific judgment and reconstruction process.

[0106] In this embodiment, the free-running timer is set to a bit width of 32 bits (maximum count value is 0xFFFFFFFF), and the toggle counter is set to a bit width of 8 bits. The initial toggle count value carried by the first toggle record data packet after the debugging acquisition begins is 0x05; the software parsing tool maintains two core variables: the currently valid toggle count value and the timestamp of the previous parsed record.

[0107] In practice, after the software parsing tool reads the data packet from external memory, it first identifies the 2-bit type identifier field in the packet header. The hardware side forces the type identifier field to be set to 2'b11 when generating the flip record data packet to ensure unique and identifiable type. If the type identifier field is identified as 2'b11, the data packet is determined to be a flip record data packet. The system directly sends the flip record data packet to the flip record parsing branch, extracts the flip count value contained within it to update the valid flip count value, and skips subsequent flip determination logic. If the type identifier field is not 2'b11, the data packet is determined to be a normal debug data packet, and the flip determination process begins. During the determination process, the system compares the timestamp carried by the current normal debug data packet with the timestamp of the previous parsed record. If the timestamp carried by the current normal debug data packet is greater than or equal to the timestamp of the previous parsed record, the timer is determined not to have flipped, and the timestamp of the previous parsed record remains unchanged. If the timestamp carried by the current normal debug data packet is less than the timestamp of the previous parsed record, the timer is determined to have flipped, and the system increments the value of the timestamp of the previous parsed record by 1. Subsequently, the system calculates the absolute timestamp based on the updated timestamp of the previous parsed record and the timestamp carried in the current normal debug data packet.

[0108] Taking a specific scenario as an example, if the preceding record is a micro-instruction dot packet, the timestamp of the previous parsed record is 0xFFFFFFF0, the effective toggle count is 0x05, and the currently read data packet is a toggle record packet with a type identifier field of 2'b11 and a timestamp of 0x00000010, the system recognizes the data packet as a toggle record packet, directly extracts the toggle value 0x06 to update the effective toggle count, does not trigger the toggle judgment logic, and the final calculated absolute timestamp is correct. Conversely, if the preceding judgment step of whether the current data packet is a toggle record packet is not added, the system will mistakenly compare the timestamp of the toggle record packet 0x00000010 with the timestamp of the previous parsed record 0xFFFFFFF0, incorrectly judging that a timer toggle has occurred, causing the effective toggle count to be incorrectly accumulated. This error will be amplified in scenarios where toggle record packets are generated continuously, ultimately causing the absolute timestamp to shift.

[0109] In this way, by adding a pre-judgment step for non-flipped record packets in the current data packet, the timestamp wraparound event triggered by timer flipping is logically distinguished from that of ordinary data packets, avoiding erroneous accumulation of the flip counter. Even in large-scale model inference tasks with long-running operations and multiple timer flips, the accuracy of absolute timestamp reconstruction can be guaranteed.

[0110] In some embodiments, after reading the flip record data packet and debug data packet from external memory, at the start of parsing, the parsing tool first scans the data packet queue in external memory, identifying the 2-bit type identifier field in the packet header. When the type identifier field is identified as 2'b11, the data packet is determined to be a flip record data packet. The parsing tool extracts the flip count value from the first flip record data packet in the queue (i.e., the initial flip record generated at debug startup). The flip count value is used as a calibration value to initialize the parsing tool's current flip count value.

[0111] If the initial toggle value is ignored, in scenarios where the timer has already toggled multiple times, the absolute time calculated by the software will show an integer multiple of the timer period offset.

[0112] Thus, this application calibrates the initial values ​​of software-parsed variables by extracting the initial flip count value from the first flip record data packet, solving the problem of parsing benchmark offset caused by multiple flips of the timer before debugging starts. This ensures that even in test environments with long-term operation or repeated start-stop cycles, the absolute timestamp parsed by the software maintains global consistency and accuracy, further improving the robustness and reliability of debugging data analysis.

[0113] This application also provides a multi-core NPU debugging information acquisition and time synchronization system that implements the above method. This system is implemented using hardware circuitry to ensure high accuracy and low invasiveness during the debugging process. The system architecture includes multiple NPU cores, a global inter-core communication module, a global hardware clear signal line, a debugging acquisition unit, an arbitration module, and a write-to-direct-memory access module.

[0114] Specifically, each NPU core and the global core communication module integrates an independent debug acquisition unit. This unit contains an M-bit free-running timer and an N-bit toggle counter, providing a time base for local hardware events. Upon system power-up or in response to a debug start command from the host computer, the driver software pulls the global hardware reset signal line high via the configuration register. This global hardware reset signal line is a dedicated physical trace, with its fan-out terminal connected to the timer reset terminals of all debug acquisition units. After maintaining a valid level for at least one clock cycle, the signal line is pulled low, and all timers synchronously release their resets and begin incrementing on the same rising edge of the clock that detects the level transition, thus establishing a globally unified nanosecond-level time base.

[0115] At the event capture and encapsulation level, the execution units within each NPU core generate microinstruction execution tracking data when a task starts or completes, and the synchronization management module generates synchronization instruction tracking data when executing wait-type or update-type synchronization instructions. These hardware events are captured in real time and then packaged by the data packet encapsulation module according to a predefined unified format. Specifically, the header of all data packets includes a 2-bit Type Identifier Field (TYPE), which distinguishes data types: for example, a 2'b00 type identifier field represents a tracking data point from an execution unit or synchronization management module (distinguishing the specific source by the functional unit identifier); a 2'b01 type identifier field represents a cyclic redundancy check result; a 2'b10 type identifier field represents on-chip memory access; and a 2'b11 type identifier field represents a timer toggle record. This unified format design greatly simplifies the hardware assembly logic.

[0116] To address bandwidth contention issues from multiple data sources, the system employs a two-level arbitration architecture. The first-level arbitrator receives three types of data packets with the same priority: microinstructions, synchronization instructions, and cyclic redundancy check (CRC) results. It uses a round-robin algorithm to achieve fair arbitration, preventing a single data source from being starved. The second-level arbitrator compares data packets sequentially according to a fixed priority order, ensuring that critical time reference information is transmitted first. The fixed priority order, from highest to lowest, is: the priority of record flipping, the priority of scheduler markers, the priority of the first-level arbitration result, and the priority of on-chip memory access.

[0117] Ultimately, the data stream selected by arbitration enters the Write Direct Memory Access (CDMA) module. The CDMA module writes the data to external memory using AXI bus burst transmission according to pre-configured burst length parameters. To ensure data integrity, the CDMA module incorporates a sophisticated hardware monitoring mechanism: an independent overflow flag register with write-to-clear attribute is configured for each input channel, setting the overflow flag when the write buffer is full. A global bus error status register with write-to-clear attribute is also configured, latching error information when the AXI bus returns a DECERR or SLVERR error. Software can read these registers via the APB (Advanced Peripheral Bus) to accurately distinguish whether data loss is caused by internal congestion or an external bus failure. Furthermore, the CDMA module also incorporates an idle timeout mechanism; if no new data is received for 128 consecutive cycles, the remaining data is rounded up to the 512-bit AXI bus width before transmission, preventing data delays.

[0118] On the software parsing side, the offline tool reads data packets from external storage and extracts the first flip record data packet with type identifier field 2'b11 to calibrate the initial flip count value. Then, it iterates through all data packets in timestamp order, incrementing the current flip count value by 1 when a timestamp wraparound is detected (the current timestamp is less than the previous timestamp). Furthermore, by calculating the absolute timestamp, discrete local timestamps are mapped to a continuous global timeline, thereby enabling precise causal analysis of cross-core events.

Claims

1. A method for acquiring debugging information and synchronizing time in a multi-core NPU, characterized in that, The method is applied to a hardware architecture including multiple NPU cores and an inter-core communication module, wherein both the NPU cores and the inter-core communication module are configured with a debug acquisition unit; the method includes: In response to receiving a debug start command, the timers of each debug acquisition unit are synchronously reset via a global hardware clear signal line, so that each timer starts counting synchronously on the same clock edge; Monitor the count value of the timer, and when the count value jumps from the maximum value to zero, control the debugging acquisition unit to generate a flip record data packet including the current flip count value and the current timestamp, and write the flip record data packet to the external memory; Capture hardware events in each NPU core and the inter-core communication module, and encapsulate the hardware events into corresponding debug data packets according to a predefined format; Arbitration selection is performed on each of the debug data packets and the flip record data packets according to a preset fixed priority order, and the selected output data packets are written to the external memory through the direct memory access channel.

2. The synchronization method according to claim 1, characterized in that, The step of synchronously resetting the timers of each of the debugging acquisition units via a global hardware reset signal line includes: Set the global hardware clear signal line to an active level to reset the timers of each of the debugging acquisition units to zero. After maintaining the active level for at least one clock cycle, the global hardware reset signal line is set to an inactive level, and each of the timers synchronously begins to increment its count in response to the same clock edge when the global hardware reset signal line is set to an inactive level.

3. The synchronization method according to claim 1, characterized in that, Also includes: Each of the aforementioned debugging and acquisition units maintains its own toggle counter; In response to the debug start command, and after the synchronization reset is completed, an initial flip record data packet including an initial flip count value and an initial timestamp is generated, and the initial flip record data packet is written to the external memory; During the timer counting process, monitor the timer count value of any debugging acquisition unit. When the count value jumps from the maximum value to zero, control the debugging acquisition unit to increment its own toggle counter by 1. The incremented flip count value is used as the high-order extension value and encapsulated together with the currently captured timestamp into the flip record data packet.

4. The synchronization method according to claim 1, characterized in that, The debug data package includes at least one of the following: microinstruction execution tracking data, synchronous instruction tracing data, cyclic redundancy check result data, and on-chip memory access data. The preset fixed priority order is as follows: The priority of the flip record data packet is higher than the priority of the scheduler timestamp data packet; The scheduler timestamp data packet has a higher priority than the microinstruction execution data packet, the synchronization instruction tracking data packet, and the cyclic redundancy check result data packet. The priority of microinstruction execution dotted data packets, the priority of synchronization instruction tracking data packets, and the priority of cyclic redundancy check result data packets are higher than the priority of on-chip memory access data packets.

5. The synchronization method according to claim 4, characterized in that, The arbitration selection of each debug data packet and the flip record data packet according to a preset fixed priority order includes: The first-level arbitrator uses a polling method to arbitrate micro-instruction execution data packets, synchronization instruction tracking data packets, and cyclic redundancy check result data packets of the same priority, and outputs the first arbitration result. The second-level arbitrator, based on the fixed priority order, arbitrates the flip record data packet, the scheduler timestamp data packet, the first arbitration result, and the on-chip memory access data packet level by level, and outputs the final selection result.

6. The synchronization method according to claim 4, characterized in that, The header of the debug data packet includes a 2-bit type identifier field, which is used to distinguish debug data packets of different data types. The microinstruction execution data packet includes a functional unit identifier, a data point type identifier, a task identifier, and a timestamp corresponding to the microinstruction execution time. The synchronization instruction tracking data packet includes a functional unit identifier, a synchronization instruction field, and a timestamp corresponding to the execution time of the synchronization instruction. The cyclic redundancy check result data packet includes the functional unit identifier, the task identifier, and the check result; The on-chip memory access data packet includes the functional unit identifier, access address, read / write direction, and timestamp corresponding to the memory access time; The header of the flip record data packet includes the 2-bit type identifier field, the flip count value, and the timestamp corresponding to the flip time.

7. The synchronization method according to claim 1, characterized in that, The step of writing the selected output data packet to the external memory via a direct memory access channel includes: According to the pre-configured burst length parameters, the data selected by arbitration is written into the designated address space of the external memory in the AXI bus burst transmission mode; When no new arbitration selection data is received for several consecutive clock cycles, the idle timeout mechanism is triggered, and the data already buffered in the current buffer is rounded up to the bus width before a single transmission is initiated. Monitor the storage status of each data buffer, and when the data buffer corresponding to any debugging acquisition unit overflows, generate and store the corresponding buffer overflow status identifier; Monitor bus transmission status, and when a bus transmission error occurs, generate and store the corresponding bus error status identifier.

8. The synchronization method according to claim 6, characterized in that, The microinstruction execution data packet includes a segment start identifier and a segment end identifier. The segment start identifier is generated when the NPU core's task starts, and the segment end identifier is generated when the NPU core's task execution is completed. The synchronization instruction tracking data packet is generated when the synchronization management module executes a waiting or updating synchronization instruction.

9. The synchronization method according to claim 1, characterized in that, Also includes: Read the flip record data packet and the debug data packet from the external memory; Maintain the current flip count value and iterate through the read flip record data packets and the debug data packets in chronological order; When the timestamp of the current debug data packet is less than the timestamp of the previous parsed record, and the current debug data packet is not a flipped record data packet, it is determined that a timer flip has occurred, and the current flip count value is updated based on the flip count value carried in the flipped record data packet. Based on the current flip count value and the timestamp carried by the current debug data packet, calculate the absolute timestamp corresponding to the current debug data packet.

10. The synchronization method according to claim 9, characterized in that, After reading the flip record data packet and the debug data packet from the external memory, the method further includes: Identify the type identifier field in the flip record data packet to distinguish the flip record data packet from the debug data packet; Extract the initial flip count value from the first flip record data packet to calibrate the initial value of the current flip count value.

Images