Cross-clock domain data interaction apparatus and method

Abstract

The application discloses a cross-clock-domain data interaction device and method, relates to the technical field of integrated circuits, and comprises a source clock circuit and a destination clock circuit. The source clock circuit is in a source clock domain, generates a sending request signal according to an input data valid signal, is synchronized to a destination clock domain, and controls data output according to a response signal. The destination clock circuit is in the destination clock domain, generates the response signal according to the synchronized sending request signal, is synchronized back to the source clock domain, and receives buffered data. Through the interaction of the request and response signals in the dual-module architecture, the application realizes cross-clock-domain data coordinated transmission, solves the data competition, misplacement or loss problem caused by metastability and data misplacement when signals are transmitted between asynchronous clock domains, and improves the data transmission reliability between asynchronous clock domains.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and in particular to a device and method for cross-clock domain data interaction. Background Technology

[0002] In Application-Specific Integrated Circuit (ASIC) design, different functional modules typically operate in asynchronous clock domains. When signals are transmitted between asynchronous clock domains, risks such as metastability and data misalignment arise, necessitating Clock Domain Crossing (CDC) design techniques to ensure reliable communication. Among related technologies, Dynamic Voltage Frequency Scaling (DVFS) and clock gating techniques increase the complexity of CDC, requiring adaptation to different clock domain states. DVFS dynamically changes the clock frequency and voltage, leading to frequent switching of operating states between different clock domains, potentially causing synchronization schemes to fail. Summary of the Invention

[0003] This application provides a cross-clock domain data interaction device and method to at least solve the problem of poor reliability of data transmission between asynchronous clock domains in related technologies.

[0004] This application provides a cross-clock domain data interaction device, including: A source clock circuit is used in the source clock domain to generate a transmit request signal in response to an input data valid signal, synchronize the transmit request signal to the destination clock domain, and control the output of input data in response to an acknowledgment signal from the destination clock domain. A destination clock circuit is configured to, within the destination clock domain, generate the response signal in response to the synchronized transmit request signal, synchronize the response signal to the source clock domain, and receive and buffer the input data from the source clock circuit. The source clock circuit and the destination clock circuit coordinate data transmission across clock domains through the interaction of the send request signal and the response signal.

[0005] This application also provides a cross-clock domain data interaction method and a cross-clock domain data interaction device according to the first aspect above or any corresponding embodiment thereof. The method includes: generating a transmission request signal through the source clock circuit and synchronizing it to the destination clock domain; generating a response signal through the destination clock circuit in response to the synchronized transmission request signal and synchronizing it to the source clock domain; controlling the output of input data to the destination clock circuit through the source clock circuit in response to the synchronized response signal; and receiving and buffering the input data through the destination clock circuit.

[0006] This application establishes a complete cross-clock domain handshake communication mechanism by constructing a dual-module hardware architecture comprising a source clock circuit and a destination clock circuit, and coordinating data transmission through the interaction of request and response signals between the two. This ensures that data output from the source is strictly controlled by the receiving state of the destination, while operations at the destination are reliably triggered by synchronized request signals, thus forming an ordered and controllable data flow between asynchronous clock domains. This effectively solves the technical problems of data contention, misalignment, or loss caused by the lack of a reliable and coordinated handshake and synchronization mechanism, improving the reliability of data transmission between asynchronous clock domains. Attached Figure Description

[0007] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 This is a hardware architecture diagram of a cross-clock domain data interaction device according to an embodiment of this application; Figure 2 This is a schematic diagram of the source clock domain state machine according to an embodiment of this application; Figure 3 This is a schematic diagram of the target clock domain state machine according to an embodiment of this application; Figure 4 This is a diagram of the overflow register structure according to an embodiment of this application; Figure 5 This is a flowchart of the cross-clock domain data interaction device according to an embodiment of this application; Figure 6 This is a flowchart of a cross-clock domain data interaction method according to an embodiment of this application; Figure 7 This is a structural diagram of the handshake protocol according to an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

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

[0010] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0011] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0012] In related technologies, cross-clock domain data interaction is prone to data contention, misalignment, or loss due to the lack of a reliable and coordinated handshake and synchronization mechanism. This application provides a cross-clock domain data interaction device that realizes coordinated cross-clock domain data transmission through the interaction of request and response signals in a dual-module architecture. It establishes an ordered data flow between asynchronous clock domains, solves the problems of data contention, misalignment, or loss, and improves transmission reliability.

[0013] Reference Figure 1 As shown in the embodiment of this application, a cross-clock domain data interaction device is provided, including a source clock circuit and a destination clock circuit. The source clock circuit, within its operating source clock domain, generates a transmission request signal in response to an input data validity signal, synchronizes the transmission request signal to the destination clock domain, and controls the output of input data in response to an acknowledgment signal from the destination clock domain. The destination clock circuit, within its operating destination clock domain, generates an acknowledgment signal in response to the synchronized transmission request signal, synchronizes the acknowledgment signal to the source clock domain, and receives and buffers input data from the source clock circuit. The source clock circuit and the destination clock circuit achieve cross-clock domain data transmission coordination through the interaction of the transmission request signal and the acknowledgment signal.

[0014] The aforementioned cross-clock domain data interaction device establishes a handshake-style interaction mechanism based on request and response signals between the source and destination clock circuits. This ensures that data output from the source is strictly controlled by the destination's receive-ready state, while operations at the destination are reliably triggered by synchronized request signals. This design constructs an ordered and controllable data flow channel between asynchronous clock domains, fundamentally solving the problems of data contention, misalignment, or loss caused by the lack of a reliable coordination mechanism in cross-time domain data interaction. It improves the reliability of data transmission between asynchronous clock domains and provides a reliable cross-clock domain data interface foundation for high-performance, low-power complex on-chip systems.

[0015] Specifically, the interaction between the source clock circuit and the destination clock circuit is configured to follow a four-phase handshake mechanism. Under this mechanism, to complete a full data transfer, both the request signal and the response signal need to undergo a complete level switching cycle from logical invalid (e.g., low level) to logical valid (e.g., high level) and then back to logical invalid.

[0016] Specifically, a transmission transaction begins when the source clock circuit sets the send request signal to valid. When the destination clock circuit detects this valid request and is able to receive data, it sets the acknowledgment signal to valid as a response. Subsequently, after receiving a valid acknowledgment, the source clock circuit outputs data and sets the send request signal to invalid. After detecting that the request is invalid, the destination clock circuit finally sets the acknowledgment signal to invalid, thus completing the entire handshake loop and returning to the idle state.

[0017] This mechanism ensures that each data transmission transaction has four distinct phases: start (request valid), confirmation (response valid), reset (request invalid), and end (response invalid). This design makes the state transition logic between the communicating parties clear and rigorous, completely avoiding race conditions and false triggers that may occur in simple level-triggered or two-phase handshake scenarios. Therefore, it provides extremely high operational reliability and robustness in complex asynchronous timing environments. Specifically, in combination Figure 1 The source clock circuit includes a source state machine, a sampling filter sub-circuit, and a first synchronization logic sub-circuit.

[0018] The source state machine serves as the control core, performing state transitions based on valid input data signals and response signals from the destination clock domain to generate a send request signal and control the data output of the sampling filter sub-circuit. The sampling filter sub-circuit, under the control of the source state machine, latches the input data and outputs the data upon receiving the response signal. A first synchronization logic sub-circuit is connected between the source state machine and the destination clock circuit, specifically used to synchronize the send request signal to the destination clock domain.

[0019] In this architecture, the source state machine acts as the control core, coordinating internal operations and external handshakes. The sampling and filtering sub-circuit ensures that data is stably latched and output at the correct time. The first synchronization logic sub-circuit specifically handles the synchronization of request signals, suppressing metastability propagation. The entire circuit design is clear and highly maintainable.

[0020] More specifically, refer to Figure 2 As shown, in some embodiments of this application, the source state machine is configured as a four-state finite state machine that transitions between four states: Idle, Request, Acknowledge, and Deacknowledge.

[0021] It should be noted that the state transition logic of the source state machine strictly follows the four-phase handshake mechanism: when valid input data is detected in the idle state, it transitions to the request state and sets the request signal; in the request state, when a valid response signal from the destination clock domain is sampled, it transitions to the response state and controls data output; in the response state, when the sampled response signal is invalid, it transitions to the de-response state; finally, in the de-response state, it returns to the idle state.

[0022] This clear and deterministic state machine design eliminates ambiguity and uncertainty in the control logic, ensuring its determinism and robustness, and greatly reducing the design complexity and error risk of the control logic.

[0023] Optionally, as one specific implementation of the first synchronous logic sub-circuit, it includes a first synchronous chain composed of cascaded multi-stage flip-flops. Each flip-flop is driven by the clock of the destination clock domain, the output of the previous stage serves as the input of the next stage, and the request signal is sent and synchronized stage by stage through this chain, ultimately outputting a synchronized request signal to the destination clock domain. The design of the multi-stage flip-flop chain significantly reduces the probability of metastability propagating to subsequent logic, thus helping to reduce the probability of synchronization failure.

[0024] As an improved implementation of the first synchronization chain described above, the number of stages in the first synchronization chain is designed to be configurable. For example, the actual number of active trigger stages in the synchronization chain (such as 2, 3, or 4 stages) can be set via hardware configuration pins, fuse bits, or software programmable registers.

[0025] This configurability allows designers to dynamically adjust the synchronization depth based on the actual frequency ratio between the source and destination clock domains, the process angle, and the system's tolerance for error rates. When facing significant clock frequency differences or ultra-low voltage designs, the number of stages can be increased to improve reliability; conversely, in scenarios requiring extreme latency or low power consumption, the number of stages can be reduced to optimize performance.

[0026] Specifically, in combination Figure 1The destination clock circuit includes a destination state machine, a second synchronous logic sub-circuit, and an overflow register.

[0027] The destination state machine performs state transitions based on the synchronized send request signal and the downstream state signal from the overflow register to generate an acknowledgment signal. The second synchronization logic sub-circuit synchronizes the acknowledgment signal back to the source clock domain. The overflow register receives and buffers data from the source clock circuit and generates the downstream state signal based on its internal buffer state.

[0028] The destination state machine, acting as the control center, makes decisions and generates responses based on the synchronized request and downstream buffer state. The second synchronization logic sub-circuit is responsible for safely synchronizing the response signal back to the source clock domain, forming a complete bidirectional synchronization link. The overflow register is specifically used to receive and buffer data from the source end and generate feedback signals based on its own fill status. This architecture tightly integrates data reception, buffer management, flow control, and handshake protocol control, enabling the destination end not only to respond to handshakes but also to proactively manage its own data processing capabilities. This provides a hardware foundation for resolving data loss issues caused by downstream congestion and facilitates intelligent receiver operation.

[0029] More specifically, refer to Figure 3 As shown, in some embodiments of this application, the destination state machine is also configured as a four-state finite state machine, transitioning between four states: Idle (IDLE), waiting for a new request (W_NEW_REQ), waiting for downstream data (W_DATA), and waiting for the request to be released (W_REL). The destination state machine works in conjunction with the source state machine. In the idle state, when a valid transmit request signal after synchronization is sampled and the overflow register can receive data (downstream status signal is valid), the process transitions to the waiting for new request state and generates a valid response signal; then it transitions to the waiting for downstream data state, waiting for the overflow register to confirm data reception; when an invalid transmit request signal is sampled, the process transitions to the waiting for request release state; finally, it returns to the idle state. By introducing status signals from the overflow register, the decision of the destination state machine is linked to the actual buffer capacity, achieving a seamless integration of the handshake mechanism and the back-pressure mechanism. This ensures the reliability of data transmission from the control logic level and prevents data overwriting or loss due to receiver overload.

[0030] As a specific implementation of the second synchronous logic sub-circuit, similar to the first synchronous logic sub-circuit, it also includes a second synchronous chain composed of multiple flip-flops with configurable number of levels, used to safely synchronize the acknowledgment signal back to the source clock domain.

[0031] As an improved implementation of the aforementioned second synchronization chain, the number of stages in the second synchronization chain is also configurable, and its specific structure is similar to that of the first synchronization chain, which will not be described in detail here. This setting ensures that the synchronization of the response signal from the destination clock domain to the source clock domain also possesses high reliability and design flexibility. The configurable synchronization depth allows the design to be independently optimized for the symmetry or asymmetry of the bidirectional clock domain relationship, ensuring the signal integrity of the entire handshake loop and further improving the robustness of the entire cross-clock domain interface under various clock frequency combinations and process voltage conditions.

[0032] Reference Figure 4 As shown, as one implementation of the overflow register in the aforementioned target clock circuit, the overflow register includes a first-level register and a second-level register, and supports two working modes: pass-through mode and buffer mode.

[0033] In pass-through mode, the control logic of the overflow register is bypassed, and the input data is directly and transparently transmitted to the output. At this time, the data transmission latency is extremely low, which is suitable for scenarios where the downstream processing capacity is absolutely sufficient or where latency is extremely sensitive.

[0034] In buffered mode, the overflow register functions as a two-level buffer, capable of temporarily storing data. Specifically, input data first attempts to be stored in the first-level register; if the first-level register is full and downstream is blocked, while the second-level register is empty, the data in the first-level register is moved to the second-level register for temporary storage, and the first-level register is released to receive new data.

[0035] The two-level structure of the first-level and second-level registers allows the overflow register to form a simple pipeline or queue in buffered mode. When the downstream processing module at the destination is temporarily unable to receive data, it provides a buffer space of at least data depth, temporarily absorbing the data stream from the source and preventing immediate backpressure upstream that could cause communication interruption. In pass-through mode, when the system confirms sufficient downstream processing capacity or no risk of blocking, the buffer logic can be bypassed, allowing data to pass through with almost no delay, significantly reducing data transmission latency and power consumption. This bypassable buffer design provides a flexible trade-off between performance and power consumption.

[0036] Furthermore, in buffered mode, the overflow register is configured with backpressure functionality: when both the first-level and second-level registers contain valid data, the overflow register automatically sets its internal state to "cannot receive new data," and this state is fed back to the destination state machine via a downstream status signal. Based on this, the destination state machine will no longer generate a valid acknowledgment signal, thereby causing the source to suspend transmission via the handshake protocol.

[0037] When both registers are full, the overflow register automatically enters a "cannot receive new data" state. This state is fed back to the destination state machine, i.e., the downstream status signal, which in turn causes the source to suspend sending new data through a handshake protocol. This effectively prevents data overflow and loss when the receiving end's processing speed cannot keep up with the sending speed, ensuring the integrity of data during cross-clock domain transmission and thus solving the problem of data loss or deadlock caused by data flow congestion.

[0038] As an improved implementation, the overflow register is also configured to respond to external clear instructions, such as a system reset signal or a specific control register write operation. When a clear instruction is received, the overflow register will forcibly clear all data cached in the first-level and second-level registers and reset its internal state.

[0039] This feature allows the system to proactively and forcibly clear the data temporarily stored in the buffer at specific times, such as during system reset, mode switching, error recovery, or power management state switching, enabling the interface to quickly return to a defined initial state. This enhances the controllability and reliability of the device, facilitates rapid recovery from abnormal states, avoids subsequent logic errors that may be caused by stale or invalid data residing in the buffer, and also facilitates dynamic shutdown and wake-up processes in low-power designs.

[0040] Reference Figure 5 As shown, in conjunction with the above embodiments, the workflow of the cross-clock domain data interaction device of this application includes the following stages: Input data: Receives input data from upstream; Data sampling: Sampling the input data; State machine transition: After sampling, the state machine transitions. The state machines in the two internal clock domain modules start to transition, handshake, and transmit data. Data synchronization: During the handshake process, the input signals and data are synchronized at multiple levels to eliminate metastability; Handshake protocol complete: State machine transition complete, handshake complete, data transmitted to destination clock domain; Data enters the overflow register; Data output: Lower-level logic interacts with the overflow register module to output data to the lower-level module.

[0041] According to an embodiment of this application, a cross-clock domain data interaction method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0042] Figure 6 This is a flowchart of a cross-clock domain data interaction method according to an embodiment of this application, referred to... Figure 6 As shown, the process includes the following steps: Step S201: Generate a send request signal through the source clock circuit and synchronize it to the destination clock domain.

[0043] In step S202, the destination clock circuit generates a response signal in response to the synchronized transmit request signal and synchronizes it to the source clock domain.

[0044] In step S203, the source clock circuit, in response to the synchronized response signal, controls the input data to be output to the destination clock circuit.

[0045] Step S204: Receive and buffer the input data through the destination clock circuit.

[0046] This application achieves reliable coordination of cross-clock domain data transmission through a strict handshake protocol and bidirectional signal synchronization. It should be noted that in steps S201 to S204 above, the processes of generating the send request signal and generating the response signal follow the timing sequence of the four-phase handshake mechanism. (Refer to...) Figure 7 As shown, a data transmission transaction begins when the source clock circuit, after confirming the data readiness, sends a transmit request signal to the destination clock circuit. Upon detecting a valid transmit request signal, the destination clock circuit performs an internal state check (request detection). If its internal buffer is ready, it performs a data latch operation, storing the data in the buffer unit, and then replies with a transmit acknowledgment signal to the source clock circuit. After detecting a valid transmit acknowledgment signal, the source clock circuit completes the core stage of this data transmission and then initiates a protocol reset process: the source clock circuit invalidates the transmit request signal (i.e., issues a clear request). Upon detecting the clear request, the destination clock circuit invalidates the transmit acknowledgment signal (i.e., issues a clear acknowledgment). At this point, both the transmit request and transmit acknowledgment signals have completed a full level switching cycle from invalid to valid and then from valid to invalid, and both circuit states return to idle, marking the end of a complete data interaction process based on a four-phase handshake. This mechanism, through a strict request, acknowledgment, and clear sequence, ensures that every data transmission action is acknowledged by the other party, even in asynchronous clock domains, thereby achieving highly reliable coordination and control.

[0047] Optionally, in some embodiments of this application, step S204 specifically includes: Step a1: When the overflow register in the destination clock circuit is working in buffer mode, if the first-level register is not full, the data is stored in the first-level register. Step a2: When the first-level register is full, the second-level register is empty, and data output is blocked, the data in the first-level register is temporarily transferred to the second-level register.

[0048] The cross-clock domain data interaction method provided in this application can be applied to any cross-clock domain data interaction device provided in this application, and has all the beneficial effects that the corresponding functional modules of the cross-clock domain data interaction device can achieve. The further functional effects of each of the above steps are the same as those in the corresponding embodiments above, and will not be repeated here.

[0049] Embodiments of this application also provide an electronic device, with reference to Figure 8 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application.

[0050] The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0051] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0052] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the cross-clock domain data interaction method of embodiments of this application.

[0053] Figure 8 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0054] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the cross-clock domain data interaction method shown in the above embodiments is implemented.

[0055] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0056] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0057] The present application provides a detailed description of a cross-clock domain data interaction device and method. Specific examples have been used to illustrate the principles and implementation methods of the present application. The descriptions of these embodiments are only intended to aid in understanding the method and core ideas of the present application. It should be noted that those skilled in the art can make various improvements and modifications to the present application without departing from its principles, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A cross-clock domain data interaction device, characterized in that, include: The source clock circuit is configured to generate a transmit request signal in response to an input data valid signal within the source clock domain, synchronize the transmit request signal to the destination clock domain, and control the output of input data in response to an acknowledgment signal from the destination clock domain. The destination clock circuit is configured to generate the response signal in response to the synchronized transmit request signal within the destination clock domain, synchronize the response signal to the source clock domain, and receive and buffer the input data from the source clock circuit. The source clock circuit and the destination clock circuit coordinate data transmission across clock domains through the interaction of the send request signal and the response signal.

2. The cross-clock domain data interaction device according to claim 1, characterized in that, The source clock circuit and the destination clock circuit are configured to interact via a four-phase handshake mechanism. To complete one data transmission, both the send request signal and the response signal need to undergo a complete level switching cycle from invalid to valid and then from valid to invalid.

3. The cross-clock domain data interaction device according to claim 1 or 2, characterized in that, The source clock circuit includes: A source state machine is used to perform state transitions based on the valid input data signal and the response signal to generate the send request signal and control the output of the input data; A sampling filter sub-circuit is used to latch the input data under the control of the source state machine and output the input data after receiving the response signal; The first synchronous logic sub-circuit is used to synchronize the send request signal to the destination clock domain.

4. The cross-clock domain data interaction device according to claim 3, characterized in that, The source state machine is configured to transition between an idle state, a request state, a response state, and a de-response state.

5. The cross-clock domain data interaction device according to claim 3, characterized in that, The first synchronous logic sub-circuit includes a first synchronous chain composed of multiple flip-flops, and the number of stages of the first synchronous chain is configurable.

6. The cross-clock domain data interaction device according to claim 1, characterized in that, The target clock circuit includes: A destination state machine is used to perform state transitions based on the synchronized send request signal and a downstream state signal to generate the response signal; The second synchronization logic sub-circuit is used to synchronize the response signal to the source clock domain; An overflow register is used to receive and buffer the input data from the sampling filter sub-circuit, and generate the downstream status signal based on its buffer state.

7. The cross-clock domain data interaction device according to claim 6, characterized in that, The target state machine is configured as follows: It transitions between idle state, waiting for new request state, waiting for downstream data state, and waiting for request release state.

8. The cross-clock domain data interaction device according to claim 6, characterized in that, The second synchronous logic sub-circuit includes a second synchronous chain composed of multiple flip-flops, the number of stages of the second synchronous chain being configurable.

9. The cross-clock domain data interaction device according to claim 6, characterized in that, The overflow register includes a first-level register and a second-level register, and the overflow register is configured as follows: In pass-through mode, the overflow register transparently transmits data; In buffered mode, the overflow register buffers data through the first-level register and the second-level register.

10. The cross-clock domain data interaction device according to claim 9, characterized in that, The overflow register is configured as follows: In the buffered mode, when both the first-level register and the second-level register contain valid data, the system is in a state where new data cannot be received.

11. The cross-clock domain data interaction device according to claim 9 or 10, characterized in that, The overflow register is also configured as follows: In response to the clear instruction, clear the data cached in the first-level register and the second-level register.

12. A method for cross-clock domain data interaction, characterized in that, Applied to a cross-clock domain data interaction device as described in any one of claims 1 to 11, the method comprises: The source clock circuit generates a transmission request signal and synchronizes it to the destination clock domain. The destination clock circuit generates a response signal in response to the synchronized transmit request signal and synchronizes it to the source clock domain. The source clock circuit, in response to the synchronized response signal, controls the output of input data to the destination clock circuit. The input data is received and buffered through the target clock circuit.

13. The cross-clock domain data interaction device according to claim 12, characterized in that, The process of generating the request signal and the response signal follows the timing of the four-phase handshake mechanism.

14. The cross-clock domain data interaction device according to claim 12, characterized in that, The process of receiving and buffering the input data through the destination clock circuit includes: When the overflow register in the target clock circuit is in buffer mode, data is stored in the first-level register if the first-level register is not full. When the first-level register is full, the second-level register is empty, and data output is blocked, the data in the first-level register is transferred to the second-level register for temporary storage.

Images