Single-particle transient communication protection device and method compatible with handshake bus

Abstract

The invention relates to a single event transient communication protection device and method compatible with a handshake bus, the device is arranged on a bus path between a master device and a slave device, and the device comprises a master device side interface for receiving a valid signal and an effective load signal from the master device; the data sampling unit is used for sampling the effective load signal; the transient error checking unit is used for detecting whether transient signal errors caused by single-particle transient exist or not; the slave device side interface is used for forwarding the valid signal and the effective load signal to the slave device; and the state control module is used for blocking handshake of the master device, resampling the effective load signal according to the check result of the transient error check unit, or controlling the forwarding of the slave device side interface, and reporting an error after the retry exceeds the limit. The device can realize real-time detection and hardware-level automatic fault tolerance for transient errors such as single event transient and the like on the premise of maintaining protocol compatibility and low hardware overhead.

Description

Technical Field

[0001] This invention belongs to the field of integrated circuit reliability engineering technology, specifically relating to a single-event transient communication protection device and method compatible with handshake-type buses. Background Technology

[0002] With the continuous advancement of integrated circuit manufacturing processes, the feature size of semiconductor devices is constantly shrinking, and the operating voltage is gradually decreasing. This makes the internal nodes of the chip increasingly sensitive to transient electrical disturbances. Under conditions such as space radiation, strong electromagnetic interference, or complex on-chip power supply noise, factors such as high-energy particle incidence may trigger single-event transients, causing unexpected voltage glitches or transient flips in circuit nodes. If such transient disturbances occur on critical data transmission paths of the system and are captured on the effective clock edge, they will form soft errors, potentially leading to calculation errors, control logic disorder, or system malfunction.

[0003] In complex on-chip systems, communication between processing units, memory subsystems, and input / output peripherals primarily relies on the on-chip interconnect bus. To ensure reliable and efficient data transmission, modern on-chip buses generally employ communication protocols based on a ready / valid handshake mechanism. This protocol uses a "Valid" signal to indicate valid data and a "Ready" signal to indicate readiness for reception. The handover is completed when both signals are valid simultaneously under clock synchronization. Such protocols are typically based on the assumption of reliable physical transmission links. Once the handshake is complete, it is assumed that the relevant address, control, and data information have been correctly received, and the process enters an irreversible subsequent processing phase.

[0004] However, this mechanism faces reliability challenges in practical applications: during the clock cycle of the handshake, the transmitted signal may be subject to transient interference such as single-event transients, leading to errors in the receiver's sampled values. Since the standard handshake mechanism itself lacks transaction-level error acknowledgment and automatic retransmission capabilities, such link-level errors will be directly propagated to the upper layers of the system, becoming a potential risk affecting system reliability.

[0005] Currently, common technical approaches to addressing this type of problem mainly include the following categories: Firstly, there is fault tolerance based on the software or operating system level. This type of solution typically recovers after an error occurs through abnormal interruption, system reset, or software retries. However, its processing relies on software scheduling, resulting in significant response latency and a long recovery path, making it difficult to meet the demands of applications with stringent real-time and availability requirements.

[0006] Secondly, hardware-level redundancy hardening techniques. For example, spatial redundancy can be used to duplicate multiple identical functional units and perform majority voting to mask errors; or temporal redundancy can be used to execute the same operation multiple times and compare the results. While these methods can improve reliability, they often introduce significant silicon area overhead, increased power consumption, and increased design complexity, making them difficult to widely apply in general-purpose on-chip interconnect systems that are sensitive to cost, energy efficiency, and integration.

[0007] Thirdly, error detection mechanisms based on information redundancy. For example, a check sequence is added to the transmitted data, which is then checked by the receiving end to determine the correctness of the data. This type of mechanism is mainly used for error detection, and after an error is detected, it usually still needs to rely on the upper-layer processing mechanism for recovery. It does not have the ability to achieve automatic and rapid error correction at the bus transaction level.

[0008] Fourth, extend or modify existing bus protocols, such as by introducing additional acknowledgment / retransmission signals or transaction rollback mechanisms. Such solutions may change the behavioral definition or timing conventions of standard interfaces, potentially facing compatibility challenges with the existing design ecosystem in practical applications, and increasing the complexity of system integration and verification.

[0009] Therefore, in on-chip bus applications that adopt standard handshake mechanisms, how to achieve real-time detection and hardware-level automatic fault tolerance for transient errors such as single-event transients while maintaining protocol compatibility and low hardware overhead remains a technical problem that needs further exploration. Summary of the Invention

[0010] To address the aforementioned problems in the prior art, this invention provides a single-event transient communication protection device and method compatible with handshake-type buses. The technical problem to be solved by this invention is achieved through the following technical solution: This invention provides a single-event transient communication protection device and method compatible with handshake-type buses. The device is installed on the bus path between the master device and the slave device, and the device includes: The master device side interface is used to receive the valid signal and payload signal from the master device. A data sampling unit, connected to the main device side interface, is used to sample the payload signal; A transient error verification unit, connected to the data sampling unit, is used to detect whether there is a transient signal error caused by a single-particle transient. The device-side interface is used to forward the valid signal and the payload signal to the slave device. The status control module is connected to the master device side interface, the data sampling unit, the transient error verification unit, and the slave device side interface, respectively. It is used to control the master device side interface to block the master device handshake, and according to the verification result of the transient error verification unit, control the data sampling unit to resample the effective load signal, or control the forwarding of the slave device side interface, and report the error after the retry limit is exceeded.

[0011] Compared with the prior art, the beneficial effects of the present invention are as follows: To address the challenge of achieving real-time detection and hardware-level automatic fault tolerance for transient errors such as single-event transients (SETs) in on-chip bus applications employing standard handshake mechanisms, while maintaining protocol compatibility and low hardware overhead, this invention provides a SET protection device and method compatible with handshake-type buses. This device achieves real-time detection, automatic correction, and controlled reporting of SETs on on-chip bus links with minimal hardware overhead, without modifying bus protocol semantics, introducing additional acknowledgment / retransmission handshake signals, or requiring large-scale spatial or temporal redundancy structures. Simultaneously, it maintains full compatibility with traditional Valid / Ready handshake protocols, making it particularly suitable for cost- and power-sensitive but high-reliability on-chip interconnect systems in embedded, aerospace, and automotive fields. Specifically, the following core mechanisms effectively solve the aforementioned problems: (1) Bridged Interception and Controlled Hold: This device is inserted into the bus path in a bridged manner. After detecting that the master device's Valid signal is valid, it immediately blocks the handshake by controlling the return of the ready signal to the master device to be invalid. This action utilizes and ensures the inherent hold rules of the bus protocol, forcing the master device to continuously stabilize its address, control, and data payload signals before the handshake is completed, creating a controlled time window for subsequent operations.

[0012] (2) Error detection combining time-redundant sampling and information-redundant verification: During the handshake blocking period, the device performs an initial sampling of the stable payload signal. Verification is performed through a built-in transient error verification unit: when the payload contains a check code, a precise comparison based on information redundancy is performed, which can effectively detect various errors, including single-event transients, that cause the signal to stabilize at the error value; when there is no check code, time-redundant resampling is relied upon and the consistency of multiple sampling results is compared to detect random transient disturbances. By optionally introducing a check code, the detection capability for specific errors such as single-event transients is significantly enhanced.

[0013] (3) Hardware-level automatic error correction and controlled retries: If a transient error is detected, the device maintains the handshake blocking state and immediately controls the data sampling unit to resample and verify the same transaction signal. This process constitutes a pure hardware closed-loop retry mechanism without software intervention. The device manages the number of retries through an internal retry counter until the error is corrected or a preset threshold is reached.

[0014] (4) Circuit Breaker Isolation and Deterministic Reporting: When the number of retries exceeds the limit, the device determines it to be an unrecoverable error and immediately performs a circuit breaker operation: terminating the retries, isolating the erroneous transaction, and recording detailed information and generating an interrupt reporting system through the error reporting unit. This avoids bus deadlock and provides a deterministic error recovery path.

[0015] (5) Configurable bypass mode: The device provides a bypass control interface. When bypass is enabled, its protection logic is turned off and the signal path is straight through, thereby achieving zero-latency transmission in scenarios where high reliability is not required, providing users with the flexibility to dynamically balance reliability and performance. Attached Figure Description

[0016] Figure 1 This is a data flow diagram of the single-particle transient communication protection device provided in this embodiment of the invention on the bus path between the master device and the slave device; Figure 2 This is a data flow diagram in the state control module provided in this embodiment of the invention; Figure 3 This is a schematic flowchart of the single-particle transient communication protection device provided in an embodiment of the present invention; Figure 4 This is an example waveform diagram of a bridging device under normal conditions provided in an embodiment of the present invention; Figure 5 This is an example waveform diagram of the bridging device when a single-event transient error occurs, provided in an embodiment of the present invention. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0018] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0019] Although the invention has been described herein in conjunction with various embodiments, other variations of the disclosed embodiments will be understood and implemented by those skilled in the art in carrying out the claimed invention by reviewing the accompanying drawings, the disclosure, and the appended claims.

[0020] The present invention will now be described in detail with reference to the accompanying drawings, providing a single-event transient communication protection device and method compatible with handshake-type buses.

[0021] It should be noted that the protection mechanism proposed in this invention relies on a fundamental timing rule of the handshake bus protocol—the "hold rule." This rule requires that when the sending end (master device or host) drives its handshake valid signal (valid) to be valid, while the receiving end (slave device or this device) returns a handshake ready signal (ready) that is invalid, the sending end must keep all valid payload signals (including address, control, data, and optional checksum) corresponding to its current transaction stable and unchanged in the subsequent clock cycles until the handshake is completed (i.e., valid and ready are valid simultaneously). The core design of this invention fully utilizes and ensures this protocol characteristic, enabling multiple sampling and verification of the same set of valid payload signals kept stable by the master device within one or more clock cycles after actively blocking the handshake (controlling ready to be invalid), thereby achieving error detection and retry correction based on time redundancy.

[0022] Based on the above design concept, this invention provides a specific hardware implementation device. Figure 1 This is a data flow diagram of the single-event transient communication protection device provided in this embodiment of the invention on the bus path between the master device and the slave device. For example... Figure 1 As shown, the device is positioned on the bus path between the master and slave devices, and the device includes: The master device side interface is used to receive the valid signal and payload signal from the master device; The data sampling unit is connected to the main device side interface and is used to sample the payload signal; The transient error verification unit, connected to the data sampling unit, is used to detect whether there is a transient signal error caused by a single-particle transient. The device-side interface is used to forward valid and payload signals to slave devices. The status control module is connected to the master device side interface, the data sampling unit, the transient error verification unit, and the slave device side interface, respectively. It is used to control the master device side interface to block the master device handshake, and according to the verification result of the transient error verification unit, control the data sampling unit to resample the effective load signal, or control the forwarding of the slave device side interface, and report the error after the retry exceeds the limit.

[0023] It should be noted that, in Figure 1 In this system, the master device side interface is equivalent to the interconnect module, the data sampling unit is equivalent to the register, and the transient error checking unit is equivalent to the decoder. The register is used to sample and temporarily store the data signals and control signals from the master device side interface (interconnect module), and to achieve controlled maintenance and time-redundant resampling of transaction signals under the control of the status control module. The decoder is used to decode and verify the sampled data signals and corresponding check codes, and to generate corresponding error flag information.

[0024] It should be understood that traditional bus handshakes are direct two-way handshakes between the master and slave devices, while this solution transforms them into a three-way handshake involving the master, the bridge device, and the slave device. For the master device, the bridge device masquerades as a slave device; for the slave device, the bridge device masquerades as a master device. Furthermore, the bridge device only samples and verifies signals (address, data, control bits, etc.) from the master device. The purpose is to establish an active error detection and isolation point in the link before the bus signals reach the protected slave device. This allows for the interception, sampling, and verification of signals from the master device within the critical time window before the transaction handshake is completed, thereby achieving real-time error detection and isolation at the hardware level and preventing sampling errors caused by single-event transients from contaminating subsequent processing flows.

[0025] Here, the master device side interface is directly connected to the standard bus signal lines, conforming to the electrical characteristics and timing requirements of the target bus protocol. The payload signals received by the master device side interface include: address signals, control signals, data signals, and checksums; among which, the checksum is stored in user-defined signals or sideband signals defined by the bus protocol and transmitted together with the address signals, control signals, and data signals.

[0026] It should be understood that control signals may include, but are not limited to: signals indicating read / write operations (such as HWRITE), transfer size signals (such as HSIZE), burst type signals (such as HBURST), protection attribute signals (such as HPROT), and byte enable signals (such as WSTRB). Furthermore, checksum generation may be based on address signals, data signals, and some or all of the control signals.

[0027] It should be noted that in the AXI protocol, the valid signal received by the master device's interface is specifically manifested as AWVALID (address valid) and WVALID (data valid). The valid payload signals include the address signal (AWVALID, 32-bit address), the control signal (WSTRB, 4-bit byte enable), and the data signal (WDATA, 32-bit data). Since the AXI protocol typically does not include an explicit checksum, it may be manifested in the following ways: (1) Reuse the high bits of WDATA: For example, use WDATA[31:28] as the parity bit; (2) Use AXI user signals: such as AWUSER or WUSER (user-defined fields allowed by the protocol); (3) Additional sideband signal: A dedicated check signal line added in addition to the standard AXI.

[0028] In the AHB-Lite protocol, the valid signal received by the master device side interface is specifically manifested as HTRANS[1:0]. The valid payload signals include address signals (HADDR), control signals (HWRITE), and data signals (HWDATA); and the checksum is transmitted through an additional signal line.

[0029] It should be noted that the checksum is optional in this invention, intended to overcome the inherent limitations of relying solely on time redundancy mechanisms. That is, the payload signal may consist only of: address signal, control signal, and data signal.

[0030] In the operating mode without a checksum, the device proposed in this invention relies on time redundancy comparison: by sampling the payload signal of the same transaction multiple times and comparing whether the results of each sampling are consistent. If the results of multiple samplings are inconsistent, it indicates that random, non-repetitive transient disturbances (such as certain types of power supply noise) may have occurred during the sampling process, thereby detecting an error.

[0031] However, this mechanism faces challenges when dealing with specific physical effects such as single-event transients (SETs). SETs, triggered by high-energy particle impacts, can cause affected circuit nodes to remain at a stable erroneous logic level for one or more clock cycles. In this scenario, multiple sampling operations may capture identical erroneous signal values, making it impossible to identify errors based on the consistency of sampling results, thus leading to missed detections. To significantly improve the detection capability of transient effects such as SETs that can lead to stable error modes, this invention optionally introduces information redundancy, i.e., adding a checksum to the payload signal. This checksum is generated by the transmitter based on the original address, control, and / or data signals using a specific algorithm (such as parity check, cyclic redundancy check, or error correction code). After sampling, the receiver (i.e., the protection device of this invention) recalculates the checksum information on the received original signal using the same algorithm and compares it with the received checksum.

[0032] Figure 2 This is a data flow diagram in the state control module provided in this embodiment of the invention. For example... Figure 2 As shown, the status control module is configured to perform the following operations: a) When the valid signal sent by the master device is detected to be valid through the master device side interface, the master device side interface is controlled to return a ready signal as invalid to the master device, so as to block the handshake process; b) The control data sampling unit performs the initial sampling of the effective load signal; c) Receive the verification result of the transient error checking unit for the first sample; d) If the verification result is that no transient signal error was detected, the control sends a valid signal and a payload signal to the slave device through the device-side interface to complete the handshake for this transaction; e) If the verification result indicates that a transient signal error has been detected, the handshake remains incomplete. If the valid signal is valid, the data sampling unit is controlled to resample the effective load signal and the process returns to step c) to verify the new sampling result.

[0033] Here, the status control module includes a retry counter; the status control module is also configured to: increment the value of the retry counter when there is a transient signal error; determine whether the incremented value of the retry counter is less than a preset threshold; if yes, execute step e); if no, determine that the retry limit has been exceeded and trigger an error report.

[0034] It should be understood that the preset threshold is stored in the configuration register within the status control module and can be dynamically configured by the system software or firmware before or during operation, thereby allowing the retry strategy to be adjusted according to the criticality of different tasks or the error rate of the current environment.

[0035] Correspondingly, the device also includes an error reporting unit connected to the status control module; the status control module is further configured to trigger the error reporting unit to record error information and generate an interrupt signal when it is determined that the retry limit has been exceeded.

[0036] For example, the error message may include at least: the transaction address where the error occurred, the error data value, the error type identifier, the number of retries, and a timestamp. This information can be used by system software for error diagnosis, system health management, or to trigger higher-level fault tolerance mechanisms.

[0037] Here, the transient error checking unit performs the following steps: acquiring the effective load signal; calculating the check information using at least one of the address signal, control signal, and data signal; comparing the check code with the check information; if the comparison result is inconsistent, it is determined that there is a transient signal error.

[0038] For example, Figure 3 This is a schematic flowchart of the single-event transient communication protection device provided in an embodiment of the present invention. Figure 3 As shown, the following example of a simple on-chip bus write transaction illustrates the working principle of a single-event transient communication protection device: Suppose the master device (such as the CPU) needs to write data 0x1234 to address 0x1000. The master device drives the address signal to 0x1000 and the data signal to 0x1234 on the bus, and sets the valid signal on the master device side to be valid, thus initiating a write transaction.

[0039] (1) Normal workflow: The protection device detects a valid valid signal from the master device's interface and immediately controls the interface to return an invalid ready signal to the master device, thus blocking the handshake. Simultaneously, the device's internal data sampling unit performs its first sampling of address 0x1000 and data 0x1234 on the current bus. The transient error checking unit verifies the sampling results. Assuming no interference, the verification passes. The status control module then controls the slave device's interface to generate and send an outvalid signal to the slave device, while forwarding the address and data, ultimately completing the handshake and ending the transaction normally.

[0040] in, Figure 4 This is an example waveform diagram of a bridging device under normal conditions provided in an embodiment of the present invention. For example... Figure 4As shown, when the master device's valid signal goes high, the device's ready signal does not immediately respond by going high, but instead remains low for a period. This clearly indicates that the device actively blocks the master device's initial handshake, creating a time window for sampling and verification; during the period when the ready signal remains low, the address and data signals remain stable. This time period corresponds to the device's internal sampling, calculation, and verification operation cycle. Only after the aforementioned verification window ends is the device's out valid signal set to valid. This proves that out valid is a release signal generated autonomously by the device after confirming the data is correct, rather than a direct forwarding of the master device's valid signal.

[0041] (2) Workflow when a single-event transient error occurs: At the moment of initial sampling, the data signal is momentarily disturbed from 0x1234 to 0x1235 due to a single-event transient. The verification unit detects this error through checksum comparison (or time redundancy comparison). The status control module keeps the ready signal invalid, continues to block the master device handshake, and simultaneously controls the data sampling unit to resample. Since the master device will keep the signal stable before the handshake is completed, the second sampling is likely to capture the correct 0x1234. If the verification passes, the slave device side interface is controlled to send an out valid signal and forward the data to continue the transaction. If, due to continuous interference or other reasons, the data obtained from continuous resampling (e.g., reaching the preset 3 times) is all the wrong value 0x1235, the status control module determines that the retry limit has been exceeded. At this time, the module will terminate the retry, trigger the error reporting unit to record the error address, data, and retry count, and generate a system interrupt for reporting. At the same time, the current transaction will be terminated, and the error response signal specified by the protocol will be returned to the master device through the master device side interface, or the transaction will be redirected to a dedicated error handling slave device through the slave device side interface to prevent bus deadlock.

[0042] in, Figure 5 This is an example waveform diagram of the bridging device when a single-event transient error occurs, provided in an embodiment of the present invention. Figure 5 As shown, with Figure 4 Similarly, the initial ready signal is pulled low. The difference is that upon entering the verification window, due to verification failure, the ready signal remains low, and the out valid signal also remains low. During the period when both ready and out valid remain invalid, the address and data signals remain stable for multiple clock cycles. This clearly corresponds to the device resampling and verifying (retrying) the stable signal multiple times within the same transaction cycle. After a certain retry cycle, if the sampled data passes the verification, the waveform change will jump to the state shown in the previous clock cycle. Figure 4 Subsequent similar states: out valid becomes high, followed by out ready and ready becoming high in turn, and the transaction is completed.

[0043] It should be understood that the handshake mechanism followed by the valid and ready signals here conforms to the definition of the AXI or TileLink bus protocol.

[0044] It should be noted that since the example mainly focuses on write transactions, the workflow of the device is similar to that of write transactions when handling read transactions. The verification objects are the read data returned from the device and the corresponding checksum. After the status control module samples and verifies the valid signal returned from the device and the valid payload of the read data, it controls the main device side interface to send a valid valid signal to the main device to forward the read data, thereby also achieving single-event transient protection for the read data path.

[0045] Here, the device proposed in this invention also includes a dynamic bypass switch and a bypass control interface; the state control module is further configured to: receive a bypass enable signal through the bypass control interface, and when the bypass enable signal is valid, control the dynamic bypass switch to shut down the data sampling unit and the transient error checking unit, and directly connect the master device side interface and the slave device side interface to enable direct signal transmission between the master device and the slave device.

[0046] It should be understood that after receiving the bypass enable signal, the status control module will only control the dynamic bypass switch to perform a mode switching operation when the device is in an idle state or when the current transaction has been submitted or terminated. That is, the functions of the data sampling unit and the transient error checking unit will be turned off, and the master device side interface and the slave device side interface will be directly connected.

[0047] For example, the device supports a configurable bypass operating mode to adapt to different scenarios with varying emphasis on reliability or performance. In this mode, when the system determines that the current operating environment or task does not require high reliability or has extremely high requirements for transmission latency, a valid bypass enable signal can be sent to the bypass control interface via external control logic. Upon receiving this enable signal (typically effective when the device is idle), the state control module will switch the execution mode: shutting down the power supply or clock of the data sampling unit and transient error checking unit, and electrically connecting the master device side interface and the slave device side interface directly. Afterward, the device's functionality is completely bypassed. Valid signals, payload signals (address, data, control signals) from the master device, and ready signals returned from the slave device will pass directly without any buffering, sampling, or verification delay, as if the protection device did not exist. At this time, bus transmission reverts to the native performance of the standard handshake protocol, but no longer possesses the capability for detecting and correcting single-event transients.

[0048] Corresponding to the aforementioned single-event transient communication protection device, this invention also provides a single-event transient communication protection method compatible with handshake-type buses. This method is applied to the single-event transient communication protection device, and its core lies in utilizing the "hold-alive rule" of the bus protocol to achieve link-level transient error detection, correction, and controlled recovery at the hardware level. The method includes: When a valid signal from the master device is detected, an invalid ready signal is returned to the master device to block the handshake. During the handshake blocking period, the payload signal from the master device is sampled; The sampled payload signal is verified to detect whether there is an instantaneous signal error caused by a single-event transient. It should be understood that the verification is specifically based on the comparison of the check code, or, in the absence of a check code, on the comparison of time-redundant sampling (as detailed in the aforementioned device section). If not, send a valid signal to the slave device and forward the payload signal to complete the handshake; If so, maintain the handshake blocking state and, provided the effective load signal is stable, resample and verify the effective load signal; When the number of resampling attempts reaches a preset threshold, it is determined to be an unrecoverable error, the current transaction is terminated, and the error is reported.

[0049] In addition, the method includes an optional bypass mode management step: receiving a bypass enable signal when the single-event transient communication protection device is idle or when the current transaction has been submitted or terminated; and directly connecting the signals of the master device and the slave device when the bypass enable signal is valid.

[0050] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A single-event transient communication protection device compatible with handshake-type buses, characterized in that, The device is located on the bus path between the master device and the slave device, and the device includes: The master device side interface is used to receive the valid signal and payload signal from the master device. A data sampling unit, connected to the main device side interface, is used to sample the payload signal; A transient error verification unit, connected to the data sampling unit, is used to detect whether there is a transient signal error caused by a single-particle transient. The device-side interface is used to forward the valid signal and the payload signal to the slave device. The status control module is connected to the master device side interface, the data sampling unit, the transient error verification unit, and the slave device side interface, respectively. It is used to control the master device side interface to block the master device handshake, and according to the verification result of the transient error verification unit, control the data sampling unit to resample the effective load signal, or control the forwarding of the slave device side interface, and report the error after the retry limit is exceeded.

2. The single-event transient communication protection device compatible with handshake-type bus according to claim 1, characterized in that, The status control module is configured to perform the following operations: a) When the valid signal sent by the master device is detected to be valid through the master device side interface, the master device side interface is controlled to return a ready signal as invalid to the master device, so as to block the handshake process; b) Control the data sampling unit to perform the first sampling of the payload signal; c) Receive the verification result of the transient error verification unit for the first sample; d) If the verification result indicates that no instantaneous signal error was detected, control the slave device side interface to send the valid signal and the payload signal to the slave device to complete the handshake of this transaction; e) If the verification result indicates that the instantaneous signal is incorrect, the handshake remains incomplete. If the valid signal is valid, the data sampling unit is controlled to resample the effective load signal, and the process returns to step c) to verify the new sampling result.

3. The single-event transient communication protection device compatible with handshake-type bus according to claim 2, characterized in that, The status control module includes a retry counter; the status control module is also configured to: When the instantaneous signal error exists, the value of the retry counter is incremented; Determine whether the incremented value of the retry counter is less than a preset threshold; If so, proceed to step e); If not, it is determined that the retry limit has been exceeded, and an error report is triggered.

4. The single-event transient communication protection device compatible with handshake-type bus according to claim 3, characterized in that, It also includes an error reporting unit, which is connected to the status control module; the status control module is further configured to: When the retry limit is exceeded, the error reporting unit is triggered to record the error information and generate an interrupt signal.

5. The single-event transient communication protection device compatible with handshake-type bus according to claim 1, characterized in that, It also includes a dynamic bypass switch and a bypass control interface; the status control module is further configured to: The bypass control interface receives a bypass enable signal, and when the bypass enable signal is valid, it controls the dynamic bypass switch to shut down the data sampling unit and the transient error checking unit, and directly connects the master device side interface and the slave device side interface, so that the signal between the master device and the slave device can be directly transmitted.

6. The single-event transient communication protection device compatible with handshake-type bus according to claim 1, characterized in that, The payload signal includes: an address signal, a control signal, a data signal, and a checksum; the transient error checking unit is used to perform the following steps: Obtain the effective load signal; Verification information is calculated using at least one of the address signal, the control signal, and the data signal; Compare the verification code with the verification information; If the comparison results are inconsistent, it is determined that there is an error in the instantaneous signal.

7. The single-event transient communication protection device compatible with handshake-type bus according to claim 6, characterized in that, The checksum is stored in a user-defined signal or sideband signal defined by the bus protocol and transmitted together with the address signal, the control signal and the data signal.

8. The single-event transient communication protection device compatible with handshake-type bus according to claim 2, characterized in that, The handshake mechanism followed by the valid signal and the ready signal conforms to the definition of the AXI or TileLink bus protocol.

9. A single-event transient communication protection method compatible with handshake-type buses, characterized in that, The method is applied to the single-event transient communication protection device according to any one of claims 1 to 8; the method includes: When a valid signal is detected from the master device, an invalid ready signal is returned to the master device to block the handshake. During the handshake blocking period, the payload signal from the master device is sampled; The sampled payload signal is verified to detect whether there are any instantaneous signal errors caused by single-event transients; If not, send the valid signal to the slave device and forward the payload signal to complete the handshake; If so, maintain the handshake blocking state, and resample and verify the effective load signal provided that the effective load signal is stable; When the number of resampling attempts reaches a preset threshold, it is determined to be an unrecoverable error, the current transaction is terminated, and the error is reported.

10. The single-event transient communication protection method compatible with handshake-type buses according to claim 9, characterized in that, Also includes: When the single-event transient communication protection device is in an idle state, or when the current transaction has been submitted or terminated, a bypass enable signal is received. When the bypass enable signal is valid, the signals of the master device and the slave device are directly connected.

Images