Cross-clock-domain jtag system sampling control method and storage medium

Abstract

The application discloses a cross-clock-domain JTAG system sampling control method and a storage medium, relates to the technical field of CPU sampling control, and discloses a cross-clock-domain JTAG system sampling control method.The system comprises a main controller, a programmable logic device and a JTAG target device, the main controller is electrically connected with the programmable logic device, the programmable logic device is electrically connected with the JTAG target device, and the method comprises the following steps: acquiring a clock signal of the main controller; collecting detection data of the JTAG target device according to the clock signal and a preset sampling condition; analyzing the detection data and checking the detection data through a preset checking model to generate transaction data uploaded to the main controller; and thus, precise sampling control of the JTAG target device in a cross-clock-domain environment is realized. The method effectively solves the sampling error problem caused by different clock domains, and improves the accuracy and reliability of data collection.

Description

Technical Field

[0001] This application relates to the field of CPU sampling control technology, and in particular to a sampling control method and storage medium for a cross-clock domain JTAG system. Background Technology

[0002] In the field of embedded systems and chip-level debugging, the JTAG interface, as the core debugging mechanism of the IEEE 1149.1 standard, is widely used for register access, boundary scan testing, and fault diagnosis of target devices. However, when the host controller and the JTAG target device are running in an asynchronous clock domain, the TCK clock signal is inevitably affected by frequency drift and clock jitter, causing TDO data sampling point offset, leading to serious problems such as inaccurate sampling, confused transaction boundary identification, and loss of critical data packets. Traditional solutions generally adopt a synchronous FIFO structure with fixed parameters and a static sampling strategy. These methods lack flexibility in dynamic clock environments and cannot adaptively adjust according to real-time clock fluctuations, resulting in inefficient buffering mechanisms. At the same time, existing systems do not integrate real-time verification functions for transaction behavior, making it difficult to effectively detect protocol violations or abnormal response data, causing erroneous information to be mistakenly transmitted to the host controller. More importantly, after detecting a transmission anomaly, the system usually relies on coarse-grained recovery methods such as global reset, which not only forcibly interrupts the current debugging task but also significantly reduces the continuity and overall availability of the debugging link. Therefore, there is an urgent need to develop a cross-clock domain JTAG sampling control mechanism that can sense clock state changes in real time, dynamically optimize sampling and buffering strategies, and implement hierarchical anomaly handling based on structured transaction metadata, so as to improve the robustness, security and real-time response capability of the debugging process. Summary of the Invention

[0003] The main objective of this application is to provide a sampling control method and storage medium for a cross-clock domain JTAG system, aiming to solve the technical problems of improving the accuracy and reliability of cross-clock domain data sampling, enhancing system robustness, and reducing debugging task interruptions.

[0004] To achieve the above objectives, this application proposes a cross-clock domain JTAG system sampling control method. The system includes a main controller, a programmable logic device (PLD), and a JTAG target device. The main controller is electrically connected to the PLD, and the PLD is electrically connected to the JTAG target device. The method includes:

[0005] Obtain the clock signal of the main controller;

[0006] According to the clock signal and preset sampling conditions, the detection data of the JTAG target device is collected.

[0007] The detection data is parsed and verified using a preset verification model to generate transaction data, which is then uploaded to the main controller.

[0008] In one embodiment, the programmable logic device includes a clock monitoring and calculation module, and the step of acquiring the clock signal of the main controller is set as follows:

[0009] The clock monitoring and calculation module monitors and calculates the frequency drift rate and clock fluctuation rate of the main controller in real time.

[0010] In one embodiment, the programmable logic device further includes an asynchronous FIFO module and a TDO sampling module, and the step of acquiring the detection data of the JTAG target device according to the clock signal and preset conditions includes:

[0011] When the frequency drift rate exceeds the first threshold, the Gray code synchronization count of the asynchronous FIFO module is increased, and the near-full threshold of the asynchronous FIFO module is decreased.

[0012] And / or, when the clock fluctuation exceeds the second threshold, the TDO sampling module switches to high-speed sampling mode to collect the detection data.

[0013] In one embodiment, the programmable logic device includes a transaction verification module, and the step of parsing the detection data and verifying it through a preset verification model includes:

[0014] The programmable logic device samples the detection data returned by the JTAG target device;

[0015] The abnormal state of the detection data is determined by parsing and comparing the data based on the instruction code set or predefined constraints.

[0016] In one embodiment, the programmable logic device includes a TBM generation module, and the step of uploading the generated transaction data to the main controller includes:

[0017] The TBM generation module acquires the detection data and its abnormal status.

[0018] The detected data and the abnormal state are used to generate a data packet of transaction data according to preset rules, and then uploaded to the main controller.

[0019] In one embodiment, the preset rule is set so that the TBM generation module generates the transaction data based on a fixed bit sequence, the working transaction ID of the JTAG target device, the channel ID of the JTAG target device, the data length of the transaction data, the transaction type of the JTAG target device, the abnormal status flag, the transaction priority field, and the CRC check field.

[0020] In one embodiment, after the step of parsing the detection data and verifying it through a preset verification model to generate transaction data for uploading to the main controller, the method further includes:

[0021] The main controller performs matching and verification based on the received transaction data, and outputs a first transaction error signal when the CRC check field in the transaction data is abnormal, or outputs a second transaction error signal when the abnormal status flag in the transaction data is abnormal.

[0022] In one embodiment, after the step of parsing and verifying whether the transaction data is abnormal, and outputting a transaction abnormality signal to the programmable logic device when the transaction data is abnormal, the method further includes:

[0023] The programmable logic device discards the current transaction data and re-acquires the detection data of the JTAG target device based on the received first transaction anomaly signal;

[0024] Alternatively, the programmable logic device may suspend the current data transmission task based on the received second transaction exception signal.

[0025] In one embodiment, the step of the clock monitoring and calculation module monitoring and calculating the frequency drift rate and clock variability of the main controller in real time includes obtaining the clock variability of the main controller according to the following formula:

[0026]

[0027] Among them, T i T1 represents the number of local clock cycles corresponding to the i-th TCK cycle, T1 is the average number within the i-th consecutive TCK cycle, and N is the length of the sliding sampling window, with a default value of N=64.

[0028] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the cross-clock domain JTAG system sampling control method described above.

[0029] As can be seen from the above, the cross-clock domain JTAG system sampling control method and storage medium provided in this application effectively solve the problems of sampling inaccuracy and data transmission reliability under asynchronous clock domain by dynamically monitoring the main controller clock signal and adaptively adjusting the sampling strategy and buffering mechanism, combined with structured verification of transaction data and hierarchical anomaly handling. It has the technical effects of improving the accuracy and reliability of cross-clock domain data sampling, enhancing system robustness, and reducing debugging task interruptions. Attached Figure Description

[0030] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0031] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a flowchart illustrating an embodiment of the cross-clock domain JTAG system sampling control method of this application.

[0033] Figure 2 This is a flowchart illustrating Embodiment 2 of the sampling control method for a cross-clock domain JTAG system in this application.

[0034] Figure 3 This is a flowchart illustrating Embodiment 3 of the sampling control method for a cross-clock domain JTAG system provided in this application;

[0035] Figure 4 This is a flowchart illustrating Embodiment 4 of the cross-clock domain JTAG system sampling control method of this application;

[0036] Figure 5 This is a flowchart illustrating Embodiment 5 of the cross-clock domain JTAG system sampling control method of this application;

[0037] Figure 6 This is a flowchart illustrating Embodiment Six of the cross-clock domain JTAG system sampling control method of this application;

[0038] Figure 7 This is a schematic diagram of the hardware operating environment involved in the cross-clock domain JTAG system sampling control method in the embodiments of this application.

[0039] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0040] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0041] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0042] During embedded system and chip-level debugging, when the main controller and the JTAG target device are in asynchronous clock domains, the TCK signal is affected by frequency drift and clock jitter, causing sampling timing deviations in the TDO signal during cross-clock domain transmission. The essence of this problem lies in the metastability risk caused by clock domain differences, which leads to the failure of transaction boundary identification and the impairment of data integrity, thereby affecting the reliability of the debugging link and the continuity of transaction processing.

[0043] For example, in a debugging scenario using a programmable logic device as an intermediary layer, the main controller operates in a 40MHz clock domain, while the JTAG target device operates in a 33MHz clock domain. Due to the clock frequency difference and clock jitter, the edge alignment accuracy of the TCK signal decreases, causing a phase shift in the TDO data within the sampling window. In this situation, the static sampling strategy cannot dynamically adjust the sampling point position, leading to incorrect identification of transaction start and end flags, which in turn causes packet parsing errors or transaction interruptions. This phenomenon results in frequent data retransmission requests during debugging, significantly limiting the availability of the debugging link.

[0044] If the above issues are not addressed, the debugging system will be unable to effectively distinguish between protocol-compliant transactions and abnormal responses, and the blurred transaction boundaries will lead to a continuous accumulation of data loss risks. Upon receiving erroneous data, the main controller will be forced to trigger a global reset, causing unexpected interruptions to the debugging process and compromising the stability of debugging efficiency. Furthermore, the lack of a real-time verification mechanism will prevent potential protocol violations from being detected in a timely manner, weakening the system's security boundaries and ultimately affecting the integrity and recoverability of the entire debugging process.

[0045] This application proposes a sampling control method for a cross-clock domain JTAG system. The system includes a main controller 1, a programmable logic device 2, and a JTAG target device 3. The main controller 1 is electrically connected to the programmable logic device 2, and the programmable logic device 2 is electrically connected to the JTAG target device 3. The method includes:

[0046] Step S100: Obtain the clock signal of the main controller 1;

[0047] Step S200: Collect detection data from JTAG target device 3 according to the clock signal and preset sampling conditions;

[0048] Step S300: parse the detection data and verify it through a preset verification model to generate transaction data and upload it to the main controller 1.

[0049] In this embodiment, acquiring the clock signal of the main controller 1 refers to the process of capturing the signal from the clock output terminal of the main controller 1. This can be achieved by directly reading the clock signal using a level detection circuit, for example, by monitoring the rising edge change using a comparator; or by measuring the clock cycle using a digital counter, for example, by recording the number of pulses within a fixed time window. This is mainly to perceive the clock state in real time to support subsequent sampling decisions. Furthermore, the preset sampling conditions refer to pre-defined rules for controlling data acquisition. These can be implemented using a fixed sampling interval configuration, for example, setting a sampling operation to be performed every N clock cycles; or by using a statistical prediction model based on historical clock data, for example, applying a moving average algorithm to estimate the clock stability trend. This is mainly to ensure accurate capture of detection data during cross-clock domain transmission. The preset verification model refers to an algorithm used to verify the integrity of the detection data. This can be achieved using a cyclic redundancy check method, for example, calculating a CRC-32 check value; or by comparing data formats based on predefined protocol rules, for example, checking whether the data packet header field conforms to the IEEE 1149.1 standard specification. This is mainly to identify abnormal states during transmission and generate structured transaction data. Therefore, this application effectively isolates the clock domain difference between the main controller 1 and the JTAG target device 3 by constructing a programmable logic device 2 as an intermediary architecture, avoiding the metastability risk caused by direct cross-clock domain transmission; the real-time acquired clock signal binds the sampling behavior to the dynamic clock state, solving the problem of TDO sampling inaccuracy caused by clock drift and jitter that traditional fixed parameter schemes cannot adapt to; at the same time, the preset verification model realizes the clear definition of transaction boundaries and the hierarchical identification of abnormal states through real-time verification of the detection data, avoiding the impact of coarse-grained recovery measures on debugging efficiency, thereby improving the performance of cross-clock domain JTAG system in terms of data transmission reliability and real-time processing.

[0050] In a cross-clock domain JTAG system, the master controller 1, programmable logic device 2, and JTAG target device 3 form a signal transmission link via electrical connections. The master controller 1 establishes a first-level electrical connection with the programmable logic device 2, and the programmable logic device 2 establishes a second-level electrical connection with the JTAG target device 3. The system's workflow begins with the programmable logic device 2 acquiring the clock signal of the master controller 1 in real time. This step enables the system to continuously monitor the dynamic characteristics of the clock domain, providing a basis for subsequent adaptive decision-making.

[0051] Furthermore, the programmable logic device 2, based on the acquired clock signal, collects the detection data output by the JTAG target device 3 according to preset sampling conditions.

[0052] In this embodiment, the process dynamically binds sampling behavior to clock state, ensuring automatic optimization of the sampling window when clock frequency drift or jitter occurs, thereby avoiding TDO signal capture deviation caused by static sampling strategies. Consequently, the detection data is transmitted to the programmable logic device 2 for parsing and a verification process is executed through a preset verification model. This model compares and analyzes the data content based on instruction code sets or predefined constraint rules to identify potential abnormal states. Finally, the verification results and detection data are integrated into structured transaction data, which contains complete metadata fields. This transaction data is then uploaded to the main controller 1 via the programmable logic device 2, achieving closed-loop control of cross-clock domain data transmission.

[0053] In one specific implementation, the main controller 1 can be implemented using an ARM Cortex-M7 microcontroller, the programmable logic device 2 can be specifically configured as a Xilinx Kintex UltraScale FPGA chip, and the JTAG target device 3 can be an application-specific integrated circuit (ASIC) under test. In actual operation, the FPGA chip captures the TCK clock signal output by the microcontroller in real time through its input pins and dynamically adjusts the sampling phase based on the periodic characteristics of the signal. When a slight fluctuation in the clock signal frequency is detected, the FPGA's internal logic automatically shortens the sampling interval to improve the TDO data acquisition accuracy. Simultaneously, it uses preset verification rules to instantly compare the returned instruction code, generating a transaction data packet containing an abnormal status flag and uploading it to the microcontroller.

[0054] This technical solution effectively isolates the clock domain differences between the main controller 1 and the JTAG target device 3 through an intermediate architecture constructed using programmable logic device 2, fundamentally avoiding the metastability risk in cross-clock domain transmission. Specifically, the real-time clock signal acquisition mechanism enables the system to dynamically sense and adaptively adjust sampling conditions according to clock state changes, significantly reducing the probability of TDO sampling inaccuracies. Furthermore, the parsing and verification process based on a preset verification model enables immediate anomaly detection of the detected data, ensuring clear and identifiable transaction boundaries and avoiding the transaction ambiguity problem caused by missing data verification in traditional solutions. Thus, the structured transaction data generation mechanism not only reduces information loss during data transmission but also provides the main controller 1 with fine-grained anomaly handling criteria, ultimately improving the debugging robustness and data transmission reliability of the cross-clock domain JTAG system without relying on global reset operations.

[0055] In cross-clock domain JTAG system sampling control, the clock signal of the main controller 1 is acquired to support system operation. However, relying solely on the acquisition of the basic clock signal without quantitative analysis of the clock dynamic characteristics makes the system unable to perceive the frequency drift and fluctuation of the main controller 1 clock. Consequently, TDO sampling is susceptible to metastable interference when the clock is unstable, leading to data inaccuracy or blurred transaction boundaries, which weakens the adaptability and reliability of the debugging link.

[0056] In this regard, this application further proposes that the programmable logic device 2 includes a clock monitoring and calculation module 21, and the step of obtaining the clock signal of the main controller 1 is set as follows: the clock monitoring and calculation module 21 monitors and calculates the frequency drift rate and clock fluctuation rate of the main controller 1 in real time.

[0057] In practical applications, the clock monitoring and calculation module 21 refers to a dedicated functional unit integrated into the programmable logic device 2. It can be implemented using the counter logic within a field-programmable gate array (FPGA) or the clock monitoring circuit in an application-specific integrated circuit (ASIC). Its purpose is to capture the dynamic characteristics of the main controller 1's clock signal in real time without interfering with normal data transmission. The frequency drift rate can be understood as the long-term trend deviation of the main controller 1's clock frequency relative to its nominal value. It can be achieved by continuously monitoring multiple clock cycles and calculating the average frequency change rate, aiming to quantify the slow drift phenomenon of the clock frequency and provide a basis for long-term stability assessment of the system. Specifically, the clock volatility refers to the random jitter amplitude of the main controller 1's clock cycle in a short period. It can be achieved by using a sliding window statistical method to perform variance analysis on continuous clock cycles, aiming to capture the instantaneous instability characteristics of the clock signal and provide a real-time reference for precise control of sampling timing.

[0058] Specifically, the solution in this application deploys a clock monitoring and calculation module 21 in the programmable logic device 2, enabling this module to operate independently of the main controller 1 and the JTAG target device 3. This module receives the clock signal from the main controller 1 in real time and performs dynamic characteristic analysis. The module continuously calculates the frequency drift rate to reflect the long-term trend of clock frequency changes, and simultaneously calculates the clock volatility to characterize the short-term random jitter of the clock cycle, transforming the abstract clock instability problem into two quantifiable numerical indicators. These indicators serve as the basis for subsequent sampling control decisions, ensuring that the system can adjust the data acquisition strategy according to real-time changes in the clock state, thereby avoiding sampling errors caused by abnormal clock parameters.

[0059] As a preferred embodiment, the solution of this application is specifically implemented as follows: the clock monitoring and calculation module 21 can be specifically implemented as a finite state machine in the programmable logic device 2. The finite state machine measures the period length of the clock signal of the main controller 1 by counting the local clock cycle, and calculates the frequency drift rate and clock fluctuation rate using the digital signal processing circuit, and outputs the calculation results periodically for use by the sampling control logic.

[0060] Through the above scheme, this application can actively sense the dynamic characteristics of the main controller 1 clock, transform the clock instability problem into quantifiable frequency drift rate and clock fluctuation rate indicators, provide real-time decision basis for cross-clock domain data sampling, effectively reduce TDO sampling errors caused by clock drift and jitter, and improve the reliability and adaptability of the JTAG debugging link.

[0061] Furthermore, the step of the clock monitoring and calculation module 21 monitoring and calculating the frequency drift rate and clock fluctuation rate of the main controller 1 in real time includes obtaining the clock fluctuation rate of the main controller 1 according to the following formula:

[0062]

[0063] Among them, T i T1 represents the number of local clock cycles corresponding to the i-th TCK cycle, T1 is the average number within the i-th consecutive TCK cycle, and N is the length of the sliding sampling window, with a default value of N=64.

[0064] In practical applications, in some of the embodiments described above in this application, a clock monitoring and calculation module 21 is proposed to monitor and calculate the frequency drift rate and clock fluctuation rate of the main controller 1 in real time. However, in its implementation, the system fails to dynamically adjust the synchronization parameters and TDO sampling behavior of the asynchronous FIFO according to the monitoring results. As a result, when the clock frequency drift or fluctuation intensifies, the fixed parameter buffering strategy is prone to FIFO overflow or metastability risk, while the static sampling mode cannot adapt to signal jitter, causing TDO sampling inaccuracy and data loss, which seriously affects the reliability and stability of the cross-clock domain JTAG debugging link.

[0065] Specifically, within N consecutive TCK cycles, the width of each TCK cycle is quantized using the high-speed local clock inside the CPLD, resulting in a cycle sequence T1, T2, ..., TN, where T... i This represents the number of local clock cycles corresponding to the i-th TCK cycle.

[0066] As a preferred embodiment, the solution of this application is specifically implemented as follows: In the programmable logic device 2, the clock monitoring and calculation module 21 uses a shift register to construct a sliding window to store the Ti sequence, and the accumulator and divider units work together to calculate T1, where N is fixed at 64. This module is specifically implemented as a digital logic circuit inside the FPGA, including a local clock counter, an adder tree structure and a state control unit, used to complete Ti sampling, T1 update and volatility calculation in each TCK cycle, and output the quantization result to the system decision unit.

[0067] Through the above scheme, this application achieves accurate quantitative monitoring of the clock fluctuation of the main controller 1, effectively suppresses the misjudgment phenomenon caused by instantaneous noise interference, and ensures that the sampling strategy adjustment based on the fluctuation threshold can be triggered in a timely and accurate manner, thereby significantly improving the reliability and debugging efficiency of data transmission in the cross-clock domain JTAG system.

[0068] Furthermore, the step of the clock monitoring and calculation module 21 monitoring and calculating the frequency drift rate and clock fluctuation rate of the main controller 1 in real time includes obtaining the frequency drift rate of the main controller 1 according to the following formula:

[0069]

[0070] The actual frequency of the master clock is the actual output frequency value obtained by the clock monitoring and calculation module 21 from the real-time monitoring of the clock unit of the master controller 1, while the nominal frequency of the master clock is a standard frequency value that is preset and stored in the system. The frequency drift rate calculated by the above formula can intuitively reflect the degree of deviation of the clock frequency of the master controller 1, providing an important basis for subsequent clock fluctuation calculation and system sampling strategy adjustment.

[0071] In this regard, this application further proposes that the programmable logic device 2 also includes an asynchronous FIFO module 22 and a TDO sampling module 23, and the step of collecting the detection data of the JTAG target device 3 according to the clock signal and preset conditions includes:

[0072] Step S201: When the frequency drift rate exceeds the first threshold, increase the Gray code synchronization count of the asynchronous FIFO module 22 and decrease the near-full threshold of the asynchronous FIFO module 22.

[0073] In step S202, and / or, when the clock fluctuation exceeds the second threshold, the TDO sampling module 23 switches to high-speed sampling mode to collect the detection data.

[0074] In this embodiment, the frequency drift rate can be acquired using a period counter or a frequency measurement circuit. The first threshold refers to a preset upper limit value for the frequency drift rate, which can be dynamically set based on historical system operating data or empirical values, such as 5%. Its purpose is to trigger the adaptive adjustment mechanism of the buffer strategy. Increasing the Gray code synchronization count of the asynchronous FIFO module 22 means increasing the number of synchronization stages, which can be achieved by increasing the number of cascaded triggers. Its purpose is to extend the signal stability window and effectively suppress metastability propagation in cross-clock domain transmission. Decreasing the near-full threshold of the asynchronous FIFO module 22 means adjusting the FIFO's water level threshold, which can be achieved by dynamically configuring register values. Its purpose is to advance the trigger count. According to the read operation, data overflow caused by clock rate mismatch is avoided; clock volatility refers to the short-term jitter of the clock signal, which can be achieved by periodic jitter measurement or phase noise analysis technology, and its purpose is to quantify the short-term stability fluctuation of the clock; the second threshold is the preset upper limit of clock volatility, which can be set based on signal integrity requirements, and its purpose is to trigger the switching of sampling mode; the TDO sampling module 23 switching to high-speed sampling mode means increasing the sampling frequency, which can be achieved by using frequency multiplication clock or oversampling technology or switching from single-edge sampling mode to dual-edge sampling mode, and its purpose is to increase the number of signal capture points per unit time, so as to ensure that the TDO state can still be accurately identified when the signal jitter intensifies.

[0075] Specifically, the solution in this application monitors the clock signal of the main controller 1 in real time. When the frequency drift rate exceeds a first threshold, the Gray code synchronization count of the asynchronous FIFO module 22 is increased to extend the signal stabilization time margin, while the near-full threshold is reduced to reserve dynamic buffer space, thereby effectively addressing the risk of rate mismatch caused by long-term clock frequency drift. When the clock volatility rate exceeds a second threshold, the TDO sampling module 23 switches to high-speed sampling mode, increasing the number of sampling points to cover the high-frequency components of signal jitter, ensuring accurate capture of the signal state even when the effective TDO window narrows. This adaptive adjustment mechanism based on clock state allows the buffering strategy and sampling behavior to dynamically match changes in the clock environment, thereby maintaining the reliability of cross-clock domain data transmission.

[0076] In some of the embodiments described above in this application, a step is proposed to parse the detection data and verify it through a preset verification model. However, in its implementation, the verification mechanism lacks a specific implementation method. Relying solely on a general model cannot effectively identify command code violations or data constraint anomalies in the JTAG protocol, resulting in the inability to detect protocol violation responses in real time, which in turn leads to the risk of blurred transaction boundaries and data loss.

[0077] In this regard, this application further proposes a programmable logic device including a transaction verification module 24, and the steps of parsing the detection data and verifying it through a preset verification model include:

[0078] Step S301: Programmable logic device 2 samples the detection data returned by JTAG target device 3;

[0079] Step S302: Parse and compare the detection data according to the instruction code set or predefined constraints to determine the abnormal state of the detection data.

[0080] In this embodiment, the transaction verification module 24 refers to a dedicated logic unit used to perform structured verification of the detection data. It can be implemented using a finite state machine or lookup table structure, with the aim of shifting the verification process from a general model to precise identification driven by protocol semantics. The instruction code set can be understood as the opcode sequence defined by the IEEE 1149.1 standard, which can be implemented using a pre-stored instruction code database or a hard-coded logic table, with the aim of providing a benchmark reference for the protocol specification. In practical applications, predefined constraints are specifically the format rules specified by the JTAG protocol, such as packet length limits or field value ranges, with the aim of defining the boundary conditions of legal data. Specifically, parsing and comparison refers to the process of matching and verifying the sampled data with the instruction code set or predefined constraints, which can be implemented using a parallel comparator or sequence matching algorithm, with the aim of determining whether the data conforms to the protocol specification.

[0081] Specifically, the solution in this application uses a programmable logic device 2 to capture the detection data returned by the JTAG target device 3 in real time. Then, the transaction verification module 24 performs structured parsing on the data: first, it compares the instruction code with the standard instruction set to identify illegal opcodes, and at the same time verifies whether the data meets predefined constraints, such as data packet length or field format requirements, thus forming a dual verification mechanism. This mechanism ensures that abnormal states are determined in real time during data flow, avoiding the problem of ambiguous transaction boundaries caused by protocol violations. Its core lies in converting protocol semantics into executable parsing rules, so that the verification process is tightly coupled with the dynamic characteristics of the JTAG protocol.

[0082] As a specific implementation method, the solution of this application is implemented as follows: The transaction verification module 24 is implemented as a hardware state machine in the programmable logic device 2. After sampling the detection data, the state machine first checks whether the instruction code belongs to the set of valid opcodes of the IEEE 1149.1 standard, such as verifying the legality of the EXTEST instruction; at the same time, it checks whether the length of the data packet meets the minimum and maximum length constraints specified by the protocol. If the instruction code is found to be illegal or the length exceeds the limit, an abnormal status flag is immediately generated and transmitted to the subsequent processing unit.

[0083] Through the above scheme, this application can identify command code violations and data constraint anomalies in the JTAG protocol in real time, effectively avoiding the problems of blurred transaction boundaries and data loss caused by abnormal protocol response, and significantly improving the pertinence and real-time performance of data verification during cross-clock domain debugging.

[0084] In practical applications, some embodiments of this application propose a step of generating transaction data and uploading it to the main controller 1 to upload detection data and abnormal status. However, in this process, the transaction data lacks structured metadata, which cannot support the main controller 1 in distinguishing different types of abnormalities (such as CRC check errors or protocol violations). This results in the error recovery mechanism only being able to take coarse-grained measures such as global reset, which seriously affects debugging efficiency and link availability.

[0085] In this regard, this application further proposes the following steps for generating transaction data and uploading it to the main controller 1:

[0086] Step S303: The TBM generation module 25 acquires the detection data and abnormal status.

[0087] Step S304: Generate a data packet of transaction data for the detection data and abnormal status according to preset rules, and upload it to the main controller 1.

[0088] Specifically, the TBM generation module 25 is the core functional unit responsible for the structured encapsulation of transaction data. It can be implemented using a finite state machine or configurable logic blocks implemented with a hardware description language. Its purpose is to integrate the raw detection data and anomaly judgment information into a standardized data structure. Among them, acquiring detection data and anomaly status refers to receiving the real-time data stream and corresponding anomaly judgment results from the transaction verification module 24. This can be understood as synchronous data transmission through a data bus or register interface. Its purpose is to ensure that the transaction data contains complete context information. In practical applications, generating data packets of transaction data according to preset rules refers to organizing the input data into a data structure containing multi-dimensional metadata according to a predefined format specification. This can be implemented using a lookup table method, state machine drive, or parametric encoder. Its purpose is to provide the main controller 1 with a resolvable anomaly classification basis.

[0089] Specifically, the solution of this application receives detection data and abnormal status information in real time through the TBM generation module 25, and merges the two according to preset rules to generate a transaction data packet containing structured metadata. This enables the main controller 1 to distinguish error types based on the abnormal status flags in the data packet and trigger targeted recovery strategies, thereby avoiding the global reset operation caused by missing metadata in traditional solutions.

[0090] As a specific embodiment, the solution of this application is implemented as follows: The TBM generation module 25 can be specifically implemented as a dedicated hardware module in the programmable logic device 2. This module receives the detection data stream and abnormal status flag bit from the transaction verification module 24 through the AXI bus interface, uses state machine controlled data encapsulation logic to organize the input data into a complete data packet containing transaction ID, channel ID and abnormal flag according to the preset field order, and uploads it to the main controller 1 through the high-speed serial interface.

[0091] Through the above scheme, the main controller 1 can accurately identify the specific type of transaction exception, implement fine-grained error recovery strategies, significantly reduce unnecessary global reset operations, and improve the availability and real-time response capability of the JTAG debugging link.

[0092] Specifically, in the aforementioned scheme of this application, a preset rule is proposed to generate transaction data. However, in this process, the preset rule does not specifically specify the structure of the transaction data, resulting in the transaction data lacking the necessary metadata fields, which cannot support the main controller 1 to perform accurate verification and hierarchical processing based on exception type, thereby affecting the robustness and efficiency of the debugging system.

[0093] In response, this application further proposes a preset rule setting based on the fixed bit sequence of the TBM generation module 25, the working transaction ID of the JTAG target device 3, the channel ID of the JTAG target device 3, the data length of the transaction data, the transaction type of the JTAG target device 3, the abnormal status flag, the transaction priority field, and the CRC check field.

[0094] The fixed bit sequence of the TBM generation module 25 refers to a fixed synchronization mode used to identify the starting boundary of transaction data packets. This can be implemented using a predefined binary sequence such as 0xAA55 or 0x55AA, ensuring that the main controller 1 quickly identifies the starting position of the data packet and avoids boundary ambiguity during parsing. The working transaction ID of the JTAG target device 3 is a sequence number that uniquely identifies each debug transaction context. This can be implemented using an incrementing 32-bit integer counter value, ensuring that the main controller 1 accurately matches the transaction sequence and prevents state confusion in multi-transaction scenarios. The channel ID of the JTAG target device 3 is an identifier that distinguishes different target devices or communication links. This can be implemented using a 4-bit encoding scheme, supporting communication flow isolation in multi-device parallel debugging environments and improving system resource management efficiency. The data length of the transaction data refers to the number of bytes in the payload portion, which can be implemented using a 16-bit unsigned integer field, explicitly defining... Define data boundaries to avoid truncation or overflow errors during transmission; the transaction type of JTAG target device 3 refers to the classification code of the operation nature, which can be implemented using enumerated values ​​such as 0x01 for register access and 0x02 for boundary scan operation, aiming to guide the main controller 1 to adopt targeted processing logic and improve protocol compliance; the abnormal status flag refers to the binary flag bit indicating the result of the detection data verification, which can be implemented using a single-bit field, aiming to enable the main controller 1 to directly obtain the abnormal type information and trigger the hierarchical response mechanism without additional parsing; the transaction priority field refers to the level identifier representing the urgency of transaction processing, which can be implemented using a 3-bit priority encoding scheme, aiming to support dynamic scheduling strategies and ensure that critical debugging tasks are executed first; the CRC check field refers to the check code used to verify data integrity, which can be implemented using a 16-bit checksum generated by the CRC-16 algorithm, aiming to provide end-to-end error detection capability and reduce invalid retransmissions.

[0095] Specifically, the solution in this application constructs a structured transaction data framework through preset rules. A fixed bit sequence serves as the packet header for rapid synchronization; a working transaction ID establishes a unique identifier for each transaction; a channel ID distinguishes communication flows between multiple devices; data length defines the effective data range; transaction type guides the selection of operational logic; an abnormal status flag transmits verification results; a transaction priority field optimizes task scheduling order; and a CRC check field ensures data integrity. These fields work together to give transaction data self-descriptive characteristics, allowing the main controller 1 to efficiently parse it based on complete metadata: first, the fixed bit sequence locates the start of the data packet; then, the working transaction ID is used to match the context state; the channel ID is combined to distinguish the target device; the payload is extracted based on the data length; the corresponding operation is executed according to the transaction type; the abnormal status flag determines whether abnormal handling is triggered; and the CRC check verifies transmission reliability, ultimately achieving accurate verification and tiered abnormal response.

[0096] In one specific implementation, the TBM generation module 25 is implemented as a logic unit within the programmable logic device 2. When generating transaction data, this logic unit first inserts a fixed bit sequence 0xAA55 as a packet header identifier, followed by a 32-bit working transaction ID (taken from the current value of the transaction counter), a 4-bit channel ID (e.g., 0x0 corresponds to JTAG target device 3A), a 16-bit data length (indicating the number of subsequent valid data bytes), an 8-bit transaction type (0x01 indicates a register read operation), a 1-bit exception status flag (0 indicates a normal state), a 3-bit transaction priority (0x3 indicates high priority), and finally, a 16-bit CRC-16 checksum. After receiving the data packet, the main controller 1 quickly locates the packet start position using the fixed bit sequence, matches the debugging context according to the working transaction ID, verifies the integrity of the CRC check field, and determines whether to execute the hierarchical exception handling process based on the exception status flag.

[0097] Through the above technical solutions, the transaction data has a complete metadata support system, enabling the main controller 1 to achieve accurate matching and verification based on transaction ID and hierarchical exception handling mechanism based on abnormal status flags, thereby effectively improving the robustness and operating efficiency of the debugging system.

[0098] Specifically, in some of the embodiments described above in this application, transaction data containing a CRC check field and an abnormal status flag is proposed to be uploaded to the main controller 1. However, in its implementation, the main controller 1 lacks a real-time verification mechanism for the transaction data and cannot distinguish between CRC abnormalities caused by transmission errors and status flag abnormalities caused by abnormal responses from the target device. This results in the system only being able to take coarse-grained recovery measures such as global reset when an error occurs, which affects debugging efficiency and link availability.

[0099] In this regard, this application further proposes that after the step of parsing the detection data and verifying it through a preset verification model to generate transaction data and uploading it to the main controller 1, the following additional steps are included:

[0100] In step S400, the main controller 1 performs matching verification based on the received transaction data, so as to output a first transaction abnormality signal when the CRC check field in the transaction data is abnormal, or output a second transaction abnormality signal when the abnormal status flag in the transaction data is abnormal.

[0101] In practical applications, matching verification refers to the process by which the main controller 1 performs integrity verification on transaction data. It can be implemented using a cyclic redundancy check algorithm or a checksum calculation mechanism. Its purpose is to actively detect whether transaction data is distorted during cross-clock domain transmission. The first transaction anomaly signal can be a specific level signal or a data packet marker used to identify anomalies in the CRC check field. Its purpose is to distinguish random errors caused by clock jitter or metastability in the transmission link. The second transaction anomaly signal can be a signal form that is different from the first transaction anomaly signal. It is used to identify the presence of an anomaly status flag. Its purpose is to identify protocol violations or functional abnormalities in the response of the JTAG target device 3.

[0102] Specifically, the solution in this application initiates a matching and verification process immediately after the transaction data is uploaded by the main controller 1. First, it parses the CRC check field in the transaction data to verify data integrity. If the verification fails, a first transaction exception signal is output to indicate a transport layer fault. Simultaneously, it parses the exception status flag in the transaction data to determine the validity of the device response. If the flag is valid, a second transaction exception signal is output to indicate an application layer fault. This dual verification mechanism allows the main controller 1 to independently trigger corresponding recovery strategies based on the error type, avoiding the global reset operation caused by error source confusion in traditional solutions. This ensures that the debugging link only re-acquires data when a transmission error occurs, and only pauses the current task when a device malfunctions, maintaining overall system availability.

[0103] As a specific implementation method, the solution of this application is implemented as follows: The main controller 1 can be implemented using an ARM Cortex-M7 microcontroller, whose built-in hardware acceleration unit performs matching verification; when the CRC check field in the transaction data fails to verify, the main controller 1 outputs a high level as the first transaction exception signal through a dedicated interrupt line; when the exception status flag in the transaction data is set, the main controller 1 outputs a low level as the second transaction exception signal through the same interrupt line, so that the programmable logic device 2 can perform targeted recovery actions based on the signal level difference.

[0104] Through the above technical solution, the system can accurately separate transmission errors from device response anomalies, thereby triggering a data retransmission mechanism when the CRC check field is abnormal, and only pausing the current data transmission task when the abnormal status flag is valid, avoiding interruption of the entire debugging link, and significantly improving the continuity and operational efficiency of the cross-clock domain JTAG debugging process.

[0105] In some of the embodiments described above in this application, the main controller 1 performs matching and verification based on transaction data and outputs transaction exception signals to identify the error type. However, in its implementation, the programmable logic device does not take differentiated recovery measures for different types of exception signals, resulting in overly coarse error handling. It may continue to process erroneous data or perform unnecessary global resets, thereby reducing the real-time performance and availability of the debugging link.

[0106] In response, this application further proposes, after the step of parsing and verifying whether the transaction data is abnormal, and outputting a transaction abnormality signal to the programmable logic device when the transaction data is abnormal, the following steps are also included:

[0107] In step S501, the programmable logic device discards the current transaction data and re-acquires the detection data of the JTAG target device 3 based on the received first transaction exception signal.

[0108] In step S502, the programmable logic device may suspend the current data transmission task based on the received second transaction exception signal.

[0109] The first transaction anomaly signal is a signal that indicates an anomaly in the CRC check field of the transaction data. It can be implemented using a dedicated error indicator bit or an independent signal line, with the aim of quickly locating instantaneous errors during transmission. The second transaction anomaly signal can be understood as a signal that indicates an abnormal state in the transaction data. It can be implemented using a specific status register bit or a protocol-defined exception code, with the aim of identifying deeper problems such as protocol violations or device malfunctions. Discarding the current transaction data and re-acquiring it specifically refers to clearing erroneous data and triggering a new data acquisition process. It can be implemented by clearing the data buffer and resetting the sampling logic, with the aim of preventing the propagation of erroneous data and restoring data integrity. Suspending the current data transmission task can be understood as temporarily suspending the data transmission process. It can be implemented by suspending the task scheduler or setting the transmission enable signal low, with the aim of preventing error propagation and allowing the system to perform diagnostics.

[0110] Specifically, the solution in this application verifies transaction data through the main controller 1. When an anomaly is detected in the CRC check field, a first transaction anomaly signal is output; when an anomaly status flag is detected, a second transaction anomaly signal is output. The programmable logic device (PLD) selectively performs data retransmission or task suspension based on the type of the received signal. For the first transaction anomaly signal, the PLD discards the current erroneous data and immediately reacquires the detection data from the JTAG target device 3, thereby quickly restoring data transmission in the event of a momentary error. For the second transaction anomaly signal, the PLD suspends the current data transmission task to prevent error propagation caused by continued transmission under protocol violations or device malfunctions, while also providing a diagnostic window for the system. This response mechanism based on anomaly type differentiation ensures the accuracy and efficiency of error handling.

[0111] As a specific implementation method, the solution of this application is implemented as follows: In the scenario where the programmable logic device is implemented using FPGA, when the first transaction exception signal is received, the data buffer is triggered to be cleared and the TDO sampling module 23 is started to re-acquire the detection data of the JTAG target device 3; when the second transaction exception signal is received, the pause bit of the task control register is set to temporarily stop the current data transmission task until the exception state is resolved.

[0112] Through the above scheme, this application achieves differentiated processing for different transaction exception types, avoiding the inefficiency of global reset in traditional schemes, and significantly improving the debugging reliability and link stability of cross-clock domain JTAG systems. Specifically, the fast retransmission mechanism for CRC check field anomalies effectively improves the real-time performance of data transmission; the pause mechanism for abnormal status flags ensures the availability of the debugging link and prevents error propagation.

[0113] Specifically, in some of the embodiments described above in this application, a clock monitoring and calculation module 21 is proposed to monitor and calculate the clock fluctuation rate of the main controller 1 in real time. However, in its implementation, the calculation of clock fluctuation rate lacks accurate mathematical model support, which makes the monitoring results susceptible to instantaneous noise interference and unable to quantify the actual clock jitter level. Consequently, the adjustment of the sampling strategy based on the fluctuation rate threshold (such as switching the high-speed sampling mode) may be falsely triggered or delayed in response, affecting the reliability and debugging efficiency of cross-clock domain data transmission.

[0114] In practical applications, some embodiments of this application propose a step of generating transaction data and uploading it to the main controller 1 to upload detection data and abnormal status. However, in this process, the transaction data lacks structured metadata, which cannot support the main controller 1 in distinguishing different types of abnormalities (such as CRC check errors or protocol violations). This results in the error recovery mechanism only being able to take coarse-grained measures such as global reset, which seriously affects debugging efficiency and link availability.

[0115] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the cross-clock domain JTAG system sampling control method in the above embodiments.

[0116] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0117] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0118] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0119] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

Claims

1. A sampling control method for a cross-clock domain JTAG system, characterized in that, The system includes a main controller, a programmable logic device (PLD), and a JTAG target device. The main controller is electrically connected to the PLD, and the PLD is electrically connected to the JTAG target device. The method includes: Obtain the clock signal of the main controller; According to the clock signal and preset sampling conditions, the detection data of the JTAG target device is collected. The detection data is parsed and verified using a preset verification model to generate transaction data, which is then uploaded to the main controller. The programmable logic device includes a clock monitoring and calculation module, and the step of acquiring the clock signal of the main controller is set as follows: The clock monitoring and calculation module monitors and calculates the frequency drift rate and clock fluctuation rate of the main controller in real time. The programmable logic device further includes an asynchronous FIFO module and a TDO sampling module. The step of acquiring the detection data of the JTAG target device according to the clock signal and preset sampling conditions includes: When the frequency drift rate exceeds the first threshold, the Gray code synchronization count of the asynchronous FIFO module is increased, and the near-full threshold of the asynchronous FIFO module is decreased. And / or, when the clock fluctuation exceeds the second threshold, the TDO sampling module switches to high-speed sampling mode to collect the detection data.

2. The sampling control method for a cross-clock domain JTAG system as described in claim 1, characterized in that, The programmable logic device includes a transaction verification module, and the step of parsing the detection data and verifying it through a preset verification model includes: The programmable logic device samples the detection data returned by the JTAG target device; The abnormal state data of the detection data is determined by parsing and comparing the data based on the instruction code set or predefined constraints.

3. The sampling control method for a cross-clock domain JTAG system as described in claim 2, characterized in that, The programmable logic device includes a TBM generation module, and the step of uploading the generated transaction data to the main controller includes: The TBM generation module acquires the detection data and its abnormal state data; The detected data and the abnormal state are used to generate a data packet of transaction data according to preset rules, and then uploaded to the main controller.

4. The sampling control method for a cross-clock domain JTAG system as described in claim 3, characterized in that, The preset rule is set so that the TBM generation module generates the transaction data based on a fixed bit sequence, the working transaction ID of the JTAG target device, the channel ID of the JTAG target device, the data length of the transaction data, the transaction type of the JTAG target device, the abnormal status flag, the transaction priority field, and the CRC check field.

5. The sampling control method for a cross-clock domain JTAG system as described in claim 1, characterized in that, After the step of parsing the detection data and verifying it through a preset verification model to generate transaction data and upload it to the main controller, the method further includes: The main controller performs matching and verification based on the received transaction data, and outputs a first transaction error signal or a second transaction error signal to the programmable logic device when the transaction data is abnormal.

6. The sampling control method for a cross-clock domain JTAG system as described in claim 5, characterized in that, The step of the main controller performing matching and verification based on the received transaction data, and outputting a first transaction error signal or a second transaction error signal to the programmable logic device when the transaction data is abnormal, further includes: The programmable logic device discards the current transaction data and re-acquires the detection data of the JTAG target device based on the received first transaction anomaly signal; Alternatively, the programmable logic device may suspend the current data transmission task based on the second transaction exception signal.

7. The sampling control method for a cross-clock domain JTAG system as described in claim 1, characterized in that, The clock monitoring and calculation module monitors and calculates the frequency drift rate and clock variability of the main controller in real time, including obtaining the clock variability of the main controller according to the following formula: Among them, T i T1 represents the number of local clock cycles corresponding to the i-th TCK cycle, T1 is the average number within the i-th consecutive TCK cycle, and N is the length of the sliding sampling window, with a default value of N=64.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the cross-clock domain JTAG system sampling control method as described in any one of claims 1 to 7.

Images