Asynchronous communication
By using state mutexes and signal marks in asynchronous bridges, data loss and throughput loss problems in communication between different power and clock domains are solved, and efficient data transmission and a robust synchronization mechanism are achieved.
Patent Information
- Application Number
- CN201980054316.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2018-06-29
- Filing Date
- 2019-06-26
- Publication Date
- 2024-12-20
- Estimated Expiration
- 2039-06-26
AI Technical Summary
In asynchronous communication between different power and clock domains, existing handshake programs have problems with data loss and throughput loss. Two-stage handshake is not suitable for reset situations, while the slower handshake of four-stage handshake leads to serious throughput loss.
An asynchronous bridge is designed, including state mutexes and signal marks, which ensures the synchronization of data transmission by locking the state mutex, and automatically resynchronizes when desynchronization is detected, and uses two-stage or four-stage handshakes to adapt. Different situations ensure the integrity and efficiency of data transmission.
Efficient data transmission between different power and clock domains is achieved, data loss and throughput loss problems are overcome, and more robust synchronization mechanisms and faster data transmission speeds are provided.
Smart Images
Figure CN112585592B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to asynchronous communication, and more particularly to asynchronous transmission of data across clock and / or power domain crossings in electronic devices. Background Art
[0002] Modern electronic devices, for example, are arranged to perform e.g. or A radio transceiver device for wireless communication may have two or more different power and / or clock domains that at least occasionally need to communicate with each other.
[0003] A clock domain refers to a circuit driven by a specific clock signal, while a power domain refers to a circuit driven by the same power supply voltage. For example, a central processing unit may run at a relatively high frequency in a first clock domain, while one or more peripheral devices may run at a relatively low frequency in a second clock domain. In general, when different power domains and clock domains are not synchronized with each other, asynchronous crossing of signals across power and / or clock domain boundaries is required to be passed from one domain to another.
[0004] This is relevant to transferring data between two different buses, such as between two AHB buses, where each bus is in a different clock and / or power domain, where AHB is Advanced High-Performance Bus (AHB) within the (Advanced Microcontroller Bus Architecture) protocol, the The protocol is an open standard interconnect specification for the connection and management of functional blocks in a System on Chip (SoC), i.e., for on-chip communications. An asynchronous AHB-AHB bridge may typically be used to facilitate data transfer from one AHB to another AHB, where the originating AHB is connected to the bridge as a slave component (referred to herein as a 'slave'), and the destination AHB is connected to the same bridge as an AHB master component (referred to herein as a 'master').
[0005] It is known that in systems that include different power and / or clock domains that are not synchronized with each other and may have different frequencies, a "handshake" process is employed in which the clock domains negotiate parameters to determine that each side is consistent with respect to the state of one or more specific data signals crossing the boundary between the domains. This is necessary so that signals can be transferred from one power and / or clock domain to another during a safe period for doing so (e.g., away from transitions in the clock signal used by the receiving clock domain).
[0006] A handshake procedure known per se in the art is a two-phase handshake procedure or a two-step handshake procedure. In a two-phase handshake procedure, the initiator starts by switching the state of its request signal (i.e., flipping the signal from low to high or from high to low, appropriately changing it from the previous state to the opposite state). The receiver then confirms this request by switching the state of its confirmation signal to complete the handshake. However, the applicant has recognized that this two-phase process is not suitable for use when either side (i.e., the initiator or the receiver) can be reset (or even powered off so that the isolation clamp value defines the signal state observed by the other side) during the handshake, because in some cases, the reset can be regarded as the completion of the handshake. For example, if the confirmation signal was previously high and the receiver is reset, the confirmation signal may change to low due to the reset, rather than as an actual confirmation of the initiator's request. As a result, any data transmitted across the power boundary and / or clock boundary will be lost because the receiving side cannot actually receive any data. The problem of undesirable state changes caused by reset and / or power failure in the handshake is called desynchronization.
[0007] There are also four-phase handshake procedures known per se in the art that attempt to overcome this drawback, for example by utilizing Gray coding to allow detection of invalid transitions. However, the known four-phase handshake procedures are relatively slow, since they start and end each handshake in a defined "idle" phase or "start" phase, which requires four phase transitions to return to "idle" or "start". Thus, although the four-phase handshake is more resilient to data loss due to desynchronization, the four-phase handshake takes twice as long as the two-phase handshake, which results in a severe throughput loss.
[0008] It is an object of the present invention to provide an improved system and method for communicating between two different power and / or clock domains. Summary of the invention
[0009] When viewed from a first aspect, the invention provides an asynchronous bridge arranged to transfer data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0010] A slave module connected to the first bus and comprising a state mutex initiator and a semaphore initiator; and
[0011] a main module connected to the second bus and comprising a state mutex terminator and a semaphore terminator;
[0012] wherein the state mutex initiator and the state mutex terminator are connected together to form a lockable state mutex;
[0013] wherein the slave module is arranged to determine whether the state mutex is locked, and wherein the state mutex is arranged to be unlocked when either the slave module or the master module is reset;
[0014] The asynchronous bridge is arranged such that:
[0015] If the state mutex is not locked when the slave module has data to send to the master module, the asynchronous bridge attempts to lock the state mutex;
[0016] If the status mutex is locked when the slave module has data to send to the master module, the semaphore initiator switches a data request flag and sends the data across the asynchronous interface to the master module; and
[0017] The beacon terminator switches a data confirmation flag after the master module receives the data from the slave module.
[0018] This first aspect of the invention extends to a method of operating an asynchronous bridge, the asynchronous bridge being arranged to transfer data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0019] A slave module connected to the first bus and comprising a state mutex initiator and a semaphore initiator; and
[0020] a main module connected to the second bus and comprising a state mutex terminator and a semaphore terminator;
[0021] wherein the state mutex initiator and the state mutex terminator are connected together to form a lockable state mutex;
[0022] wherein the slave module is arranged to determine whether the state mutex is locked, and wherein the state mutex is arranged to be unlocked when either the slave module or the master module is reset;
[0023] The method comprises:
[0024] If the state mutex is not locked when the slave module has data to send to the master module, attempt to lock the state mutex;
[0025] If the status mutex is locked when the slave module has data to send to the master module, operating the semaphore initiator to switch a data request flag and send the data across the asynchronous interface to the master module; and
[0026] The beacon terminator is operated to switch a data confirmation flag after the master module receives the data from the slave module.
[0027] When viewed from a second aspect, the present invention provides a handshake algorithm for implementing an asynchronous bridge, the asynchronous bridge being arranged to transfer data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0028] a bus slave module connected to the first bus and comprising a forward channel initiator and a reverse channel terminator; and
[0029] a bus master module connected to the second bus and comprising a forward channel terminator and a reverse channel initiator;
[0030] wherein the forward channel initiator and the forward channel terminator are communicated together to form a lockable mutex for arbitrating access to signals for transferring data between logic from the forward channel initiator power and / or clock domain to the forward channel terminator power and / or clock domain;
[0031] wherein the backchannel initiator and the backchannel terminator communicate together to form a lockable mutex for arbitrating access to signals for communicating data between logic from the backchannel initiator power and / or clock domain to the backchannel terminator power and / or clock domain;
[0032] wherein each initiator and terminator pair is connected to form a mutex or semaphore having a value of one for the data channel,
[0033] The asynchronous bridge is arranged such that:
[0034] If either side of the bridge is reset or powered down causing desynchronization of the mutex, the desynchronization is detected by the initiator or terminator on the other side;
[0035] If both sides of the bridge are reset (or powered down) causing desynchronization, automatic resynchronization occurs;
[0036] If both sides are synchronous, the forward data channel and the reverse data channel may be used to transfer data between power and / or clock domains, as required by the bus protocol implemented by this bridge;
[0037] if both sides of the bridge are reset, then upon first use of a channel, a two-phase handshake is used to signal an intention to use the bridge, wherein both the initiator and terminator start with a request for a state and an acknowledgement of a state according to a defined state comprising both signals being reset high or both signals being reset low, whereby the state between the two sides is locked after the initiator toggles its state request signal and the terminator in response toggles its state acknowledgement signal;
[0038] If both sides of an asynchronous data channel have a state lock, the state request signal and the state confirmation signal are not allowed to change anymore, so that once asserted, these signals are arranged to retain their values until either side desynchronizes;
[0039] If both sides of an asynchronous data channel have status lock, a toggle of status request or status acknowledge to reset value is considered a desynchronization by the other side;
[0040] If a state lock is obtained, a handshake is implemented using two additional signals, whereby each toggle of the data request signal indicates a request for a handshake, and each toggle of the data acknowledgement signal indicates completion of said handshake;
[0041] If during data transfer the status signal changes value and desynchronization is thereby detected, the detecting side is arranged to change all signals to reset values, and when the reset of the desynchronization side is completed before the other side is able to return to the reset value, the desynchronization side is arranged to wait until all handshake signals that crossed the boundary have changed to their reset values again.
[0042] When viewed from a third aspect, the present invention provides a method of transferring data from a first bus to a second bus across an asynchronous interface using an asynchronous bridge, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0043] a bus slave module connected to the first bus and comprising a forward channel initiator and a reverse channel terminator in a first power and / or clock domain; and
[0044] a bus master module connected to the second bus and comprising a forward channel terminator and a reverse channel initiator in a second power and / or clock domain;
[0045] wherein the forward channel initiator and the forward channel terminator communicate to form a forward lockable mutex for arbitrating access to a signal for transmitting data from the first power and / or clock domain to the second power and / or clock domain; and
[0046] wherein the reverse channel initiator and the reverse channel terminator communicate to form a reverse lockable mutex for arbitrating access to a signal for transmitting data from the second power and / or clock domain to the first power and / or clock domain;
[0047] The method comprises:
[0048] If either side of the asynchronous bridge is reset or powered off, thereby causing desynchronization of the mutex, the desynchronization is detected by the initiator or the terminator on the other side;
[0049] If both sides of the asynchronous bridge are reset or powered off, causing desynchronization, resynchronization is automatically performed;
[0050] If both sides of the asynchronous bridge are synchronous, transmitting data between the first and second power and / or clock domains using the forward data channel and the reverse data channel;
[0051] if both sides of the asynchronous bridge are reset, then when a channel is used for the first time, a two-phase handshake is used to signal the intention to use the asynchronous bridge, the asynchronous bridge comprising one of the initiator and the corresponding terminator, the initiator and the corresponding terminator respectively starting a request for a state and an acknowledgement of a state according to a defined state comprising both signals being reset high or both signals being reset low, whereby the state between the two sides is locked after the initiator switches its state request signal and the terminator switches its state acknowledgement signal in response;
[0052] If both sides of the asynchronous data channel have a status lock, then once asserted, the blocking status request signal and the status confirmation signal are changed;
[0053] If both sides of an asynchronous data channel have status lock, a switch of status request or status acknowledge to reset value is considered desynchronization;
[0054] If a state lock is obtained, a handshake is implemented using two additional signals, whereby each toggle of the data request signal indicates a request for a handshake, and each toggle of the data acknowledgement signal indicates completion of said handshake;
[0055] If during data transfer the status signal changes value and desynchronization is thereby detected, the detecting side changes all signals to the corresponding reset values, and when the reset of the desynchronization side is completed before the other side can return to the reset value, the desynchronization side waits until all handshake signals that crossed the boundary become their reset values again.
[0056] When viewed from a fourth aspect, the present invention provides a method of transferring data from a first bus to a second bus across an asynchronous interface using an asynchronous bridge, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0057] a bus slave module connected to the first bus and comprising a forward channel initiator in a first power and / or clock domain; and
[0058] a bus master module connected to the second bus and comprising a forward channel terminator in a second power and / or clock domain;
[0059] wherein the forward channel initiator and the forward channel terminator communicate to form a forward lockable mutex for arbitrating access to a signal for transmitting data from the first power and / or clock domain to the second power and / or clock domain;
[0060] The method comprises:
[0061] If the lockable mutex is locked, transferring data between the first and second power and / or clock domains using a forward data channel;
[0062] If the lockable mutex is not locked, the forward channel initiator toggles a state request signal and the forward channel terminator in response toggles a state confirmation signal; the lockable mutex is thereby locked.
[0063] This fourth aspect of the invention extends to an asynchronous bridge arranged to transfer data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0064] a bus slave module connected to the first bus and comprising a forward channel initiator in a first power and / or clock domain; and
[0065] a bus master module connected to the second bus and comprising a forward channel terminator in a second power and / or clock domain;
[0066] wherein the forward channel initiator and the forward channel terminator communicate to form a forward lockable mutex for arbitrating access to a signal for transmitting data from the first power and / or clock domain to the second power and / or clock domain;
[0067] The asynchronous bridge is arranged such that:
[0068] If the lockable mutex is locked, the asynchronous bridge uses a forward data channel to transfer data between the first and second power and / or clock domains;
[0069] If the lockable mutex is not locked, the forward channel initiator toggles a state request signal and the forward channel terminator in response toggles a state confirmation signal; the lockable mutex is thereby locked.
[0070] In one set of embodiments, the bus slave module includes a reverse channel terminator and the bus master module includes a reverse channel initiator
[0071] The reverse channel initiator and the reverse channel terminator are in communication to form a reverse lockable mutex for arbitrating access to a signal for transmitting data from the second power and / or clock domain to the first power and / or clock domain.
[0072] In the set of preceding embodiments, the method further comprises:
[0073] if the reverse lockable mutex is locked, transferring data between the second and first power and / or clock domains using a reverse data channel;
[0074] If the reverse lockable mutex is not locked, the reverse channel initiator toggles a state request signal and the reverse channel terminator in response toggles a state confirmation signal; the reverse lockable mutex is thereby locked.
[0075] In one set of embodiments, if either side of the asynchronous bridge is reset or powered down causing desynchronization of the lockable mutex and / or the reverse lockable mutex, the desynchronization is detected by the initiator or terminator of the other side;
[0076] In one set of embodiments, if both sides of the asynchronous bridge are reset or powered down, causing desynchronization, resynchronization is automatically performed.
[0077] In one set of embodiments, a resynchronization is performed if the lockable mutex and / or the reverse lockable mutex is locked and the status request signal or the status confirmation signal changes value.
[0078] In the set of aforementioned embodiments, the resynchronization comprises one of the channel initiator switching state request signal and the corresponding channel terminator responding with a switching state confirmation signal; the lockable mutex and / or the reverse lockable mutex being thereby locked.
[0079] In one set of embodiments, the state request and state confirmation signals are prevented from changing if the lockable mutex and / or the reverse lockable mutex is already locked.
[0080] In one set of embodiments, if the lockable mutex and / or the reverse lockable mutex is already locked, two additional signals are used to implement handshaking, whereby each toggle of the data request signal indicates a request for handshaking, and each toggle of the data acknowledgement signal indicates completion of the handshake.
[0081] In one set of embodiments, if the status request and / or status confirmation signal changes value during data transmission, the module in the slave module and the master module that has detected the change in value changes all signals to corresponding reset values, and when the reset of the other module in the slave module and the master module is completed before the other side can return to the reset value, the other module waits until all handshake signals across the boundary become their reset values again.
[0082] When viewed from a fifth aspect, the invention provides an asynchronous bridge arranged to transfer data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0083] A slave module connected to the first bus and comprising a state mutex initiator; and
[0084] a master module connected to the second bus and comprising a state mutex terminator;
[0085] wherein the state mutex initiator and the state mutex terminator are communicated together to form a lockable state mutex, wherein the slave module is arranged to determine whether the state mutex is locked, and wherein the state mutex is arranged to be unlocked when either the slave module or the master module is reset;
[0086] The asynchronous bridge is arranged such that:
[0087] If the state mutex is not locked when the slave module has data to send to the master module, the asynchronous bridge attempts to lock the state mutex;
[0088] If the status mutex is locked when the slave module has data to send to the master module, the slave module switches a data request signal and sends the data to the master module across the asynchronous interface; and
[0089] The master module switches a data confirmation signal after the master module receives the data from the slave module.
[0090] When viewed from a sixth aspect, the present invention provides an asynchronous bridge for transferring data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0091] a first module connected to the first bus, the first module comprising an initiator in a first power and / or clock domain; and
[0092] a second module, the second module being connected to the second bus, the second module comprising a terminator in a second power and / or clock domain;
[0093] wherein the initiator and the terminator communicate to form a lockable mutex for arbitrating access to a signal for transmitting data from the first power and / or clock domain to the second power and / or clock domain;
[0094] The asynchronous bridge is arranged such that:
[0095] the asynchronous bridge transferring data between the first and second power and / or clock domains if the lockable mutex is locked;
[0096] If the lockable mutex is not locked, one of the first and second modules switches a state request signal and the other of the first and second modules switches a state confirmation signal in response; the lockable mutex is thereby locked.
[0097] In a set of embodiments where one or both of the first and second modules are reset or powered down, the mutex becomes unlocked.
[0098] When viewed from a seventh aspect, the present invention provides an asynchronous bridge for transferring data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge comprising:
[0099] a first module, the first module being connected to the first bus, the first module being in a first power and / or clock domain;
[0100] a second module, the second module being connected to the second bus, the second module being in a second power and / or clock domain; and
[0101] a status indicator arranged to indicate whether the first and second modules are synchronized,
[0102] wherein if the status indicator indicates that the first and second modules are synchronous, the asynchronous bridge is arranged to transfer data between the first and second buses using a two-phase handshake procedure, and wherein if the status indicator indicates that the first and second modules are not synchronous, the asynchronous bridge is arranged to transfer data between the first and second buses using a four-phase handshake procedure.
[0103] According to an embodiment of the present invention, an improved electronic device and method of operating the same are provided, wherein an improved four-phase handshake is used to determine whether the slave module and the master module have been desynchronized before completing a data transfer across the asynchronous interface. Applicants have recognized that when no state synchronization is available (e.g., when one or both sides are not powered on and ready for use), such an arrangement may result in a handshake protocol with the same number of phases as a conventional four-phase handshake, i.e., two steps dedicated to performing a state handshake, and then two steps dedicated to performing a data transfer handshake, however, subsequent data transfers only require a two-phase data transfer handshake until one or both of the master and slave modules are reset (and the state "locked" is lost due to desynchronization).
[0104] At least in an embodiment, an initial four-phase handshake is performed for the first transition, and the described handshake is used to monitor that neither the slave module nor the master module is reset and causes desynchronization (because if one or both of these modules reset, the semaphore / mutex must be reset, i.e., lose its lock), which provides the robustness associated with certain known four-phase handshake procedures as described above. However, subsequent transitions can advantageously occur at the speeds typically associated with two-phase handshake procedures because the semaphore / mutex is used to ensure that the synchronization state established earlier in the initial four-phase handshake procedure is still authentic, thereby eliminating the need to check the synchronization state of each data transition.
[0105] As previously outlined, it will be understood by those skilled in the art that the term "desynchronization" and its derivatives as used herein means that the initiator module and the terminator module, which are normally asynchronous from the perspective of their clock domains, but communicate across an asynchronous interface using a handshake arrangement to implement a mutex, are "out of step" with each other, such as when the internal states of each module conflict with each other. Therefore, this misalignment of state is not simply a result of how the modules are clocked.
[0106] Since most bus protocols only provide the possibility for the slave to send data to the bus master in response to a request of the master, the reverse data channel of the bridge can be used only when the forward data channel is used to pass a request from a component with a bus master in one power and / or clock domain to a component with a bus master in another power and / or clock domain. In this way, the status part of the handshake can provide the same information for the forward mutex and the reverse mutex. In order to save time and logic, the reverse channel can therefore use the status lock of the forward channel when any desynchronization occurs simultaneously for both channels.
[0107] It will be appreciated by those skilled in the art that the described handshake may be viewed as a combination of a state handshake or state mutex and a data handshake or data mutex.
[0108] When existing two-phase handshakes and four-phase handshakes are applied across an asynchronous boundary, desynchronization due to reset or other reasons may result in data hazards when sampling data (across this asynchronous boundary) and race conditions due to data hazards on control signals (meta-stability between signals or asynchronous resets). Embodiments may seek to mitigate these problems by any one or more of: delaying detected phase changes of data mutexes by one cycle, holding data for enough cycles after capture to detect whether the captured data is valid (reduced throughput), or providing an early warning signal to the bridge component that the other side must reset soon and should ignore any changes from the data mutex to prevent data hazards from occurring (optimal performance).
[0109] In some configurations, any unexpected reset on the receiving side can be detected and recovered using only information from the "control channel", where one channel handled by a status mutex carries status information (both slave and master modules are ready to perform a transition), while a second channel handled by a semaphore or data mutex (e.g., a semaphore initiator and channel pair) provides transition-specific handshaking to protect data across asynchronous interfaces (i.e., power and / or clock boundaries).
[0110] Applicants have recognized that, unlike conventional two-phase handshake procedures known in the art, asynchronous bridges according to embodiments of the present invention can support multiple independent power domains and resets. Furthermore, because power and reset states can be determined locally by such bridges, there is advantageously no need for a global power and clock manager.
[0111] Those skilled in the art will appreciate that a mutex is typically an arrangement that provides mutually exclusive concurrent control (i.e., control that ensures the correct results of concurrent operations). In some embodiments, a state mutex includes a control request flag, a control confirmation flag, and a mutex lock flag, wherein the state mutex is arranged such that:
[0112] The state mutex initiator raises the control request flag only if the control confirmation flag is not raised;
[0113] The state mutex terminator raises the control confirmation flag in response to the control request flag being raised only when the mutex lock flag is not raised;
[0114] The state mutex is locked, and the state mutex initiator raises the mutex locked flag in response to the control confirmation flag being raised.
[0115] The state mutex can be thought of as an implementation part of the handshake that ensures both sides are ready to use.
[0116] The semaphores mentioned herein may have a value of 1 and may therefore be considered to be either mutexes or data mutexes. Therefore, references to semaphore initiators and semaphore terminators herein may be understood as references to mutex initiators and mutex terminators, or to data mutex initiators and data mutex terminators, respectively.
[0117] In one set of such embodiments, the master module is arranged to determine that a desynchronization event has occurred when the control request flag and the mutex locked flag are raised while the state mutex is not locked.
[0118] Thus, according to such embodiments, the slave module may be arranged to determine that a desynchronization event has not been detected by the master module, as indicated by the control acknowledge flag being raised, even if the slave module has not raised a control request flag since the last slave module reset.
[0119] It should be appreciated that the embodiments of the present invention described above provide data communication from a first bus to a second bus such that a semaphore / data mutex initiator of a slave module and a semaphore / data mutex terminator of a master module form a transition channel. In some embodiments, the slave module includes a return (reverse channel) data mutex / semaphore terminator and the master module includes a return data mutex / semaphore initiator, wherein the asynchronous bridge is further arranged such that:
[0120] If the state mutex is not locked when the master module has data to send to the slave module, the asynchronous bridge attempts to lock the state mutex;
[0121] If the status mutex is locked when the master module has data to send to the slave module, the semaphore / data mutex initiator switches back the data request flag and sends the data to the slave module across the asynchronous interface; and
[0122] The return semaphore / data mutex terminator switches a return data confirmation flag after the slave module receives the return data from the master module. The applicant has realized that providing the return semaphore / data mutex initiator to the slave module and providing the return semaphore / data mutex terminator to the master module provides a return channel across which the master module can send return data to the slave module.
[0123] In at least some embodiments, when the slave module has data to send to the master module, the slave module raises a valid flag, wherein the valid flag is cleared when the slave module is reset. Preferably, the valid flag is cleared when either the slave module or the master module is reset. In a set of potentially overlapping embodiments providing a return channel as described above, when the master module has data to send to the slave module, the master module raises another valid flag, wherein the another valid flag is cleared when the master module is reset. Preferably, the another valid flag is cleared when either the slave module or the master module is reset.
[0124] It will be appreciated by those skilled in the art that an asynchronous bridge operated in accordance with the claimed embodiments of the invention can overcome the problem of unplanned power outages (or resets) occurring that result in erroneous behavior in the master module and / or the slave module. However, the applicant has recognized that in some cases, power outages and resets can be known in advance, i.e., they are predetermined, although not always long in advance, i.e., such resets can be predetermined for a certain time or can be urgently predetermined in response to a specific event. In some embodiments, when the slave module has a power off event or a predetermined reset event, the slave module is arranged to send a warning signal directly to the master module, wherein the master module is arranged to abort any current data transition across the asynchronous interface upon receipt of the warning signal. In a set of potentially overlapping embodiments, when the master module has a power off event or a predetermined reset event, the master module is arranged to send a warning signal directly to the slave module, wherein the slave module is arranged to abort any current data transition across the asynchronous interface upon receipt of the warning signal. Therefore, according to such embodiments, the slave module and / or the master module can be warned before the other modules are about to be powered off, and any current transitions can be aborted to prevent errors. BRIEF DESCRIPTION OF THE DRAWINGS
[0125] Certain embodiments of the invention will now be described, by way of non-limiting examples only, with reference to the accompanying drawings, in which:
[0126] Figure 1 is a schematic diagram of an asynchronous bridge according to an embodiment of the present invention;
[0127] Figure 2 Is displayed by Figure 1 Flowchart of the handshake and transmission procedures performed by the asynchronous bridge in;
[0128] Figure 3 It is displayed in Figure 1 Timing diagram of the state mutex locking operation used in the asynchronous bridge;
[0129] Figure 4is to show what happens when a slave module resets before the master module has its clock Figure 1 The timing diagram of the desynchronization operation of the asynchronous bridge in;
[0130] Figure 5 Is to show when the slave module disconnects the state mutex lock Figure 1 The timing diagram of the operation of the asynchronous bridge in;
[0131] Figure 6 It shows when the main module disconnects the state mutex lock Figure 1 A timing diagram of the operation of the asynchronous bridge in; and
[0132] Figure 7 It is displayed in Figure 1 Timing diagram of the operation of the semaphore used in the asynchronous bridge.
[0133] Figure 1 is a schematic diagram of an asynchronous bridge 2 according to an embodiment of the present invention; the asynchronous bridge 2 includes a slave module 4 and a master module 6 separated by an asynchronous boundary 7. This asynchronous boundary 7 is the result of the slave module 4 and the master module 6 being located in different power domains and clock domains. Of course, it is understood that the slave module 4 and the master module 6 can be in different clock domains, but in the same power domain, or vice versa, however, in this exemplary embodiment, the modules 4 and 6 are in different clock and power domains.
[0134] The slave module 4 includes a state mutex initiator 8, an AHB receiver 10, a data mutex initiator 12, and a data mutex terminator 14. The AHB receiver 10 includes a finite state machine (FSM) 16, and two multi-trigger synchronizers 18, 20. The AHB receiver 10 is called a "receiver" because it receives data from the first bus 11.
[0135] The master module 6 includes: a state mutex terminator 22; an AHB transmitter 24; a data mutex terminator 26; and a data mutex initiator 28. The AHB transmitter 24 includes: a FSM 30; and two multi-trigger synchronizers 32, 34. The AHB transmitter 24 is called a transmitter because it sends data to the second bus 13.
[0136] The state mutex initiator 8 of the slave module 4 and the state mutex terminator 22 of the master module 6 together form a "state mutex", i.e. a mutex that monitors the state of the connection between the slave module 4 and the master module 6 across the asynchronous interface 7, which will be described in further detail below.
[0137] Similarly, the data mutex initiator 12 of the slave module 4 and the data mutex terminator 26 of the master module 6 together form a transfer channel between the slave module 4 and the master module 6, while the data mutex terminator 14 of the slave module 4 and the data mutex initiator 28 of the master module 6 together form a return channel between the slave module 4 and the master module 6.
[0138] Reference below Figure 2 Describing a procedure for transmitting data 43 from a first bus 11 to a second bus 13, the figure is a flowchart showing the handshake and transmission procedure performed by the asynchronous bridge 2 when the slave module 4 receives data via the first bus 11 that needs to be transmitted to the second bus 13 across the asynchronous interface 7 (i.e., on the clock domain and power domain boundaries).
[0139] The program is initialized at step 100, and the slave module 4 determines at step 102 whether the state mutex is currently locked. If the state mutex is not currently locked, the slave module determines whether the control confirmation flag 38 is raised. If the control confirmation flag 38 is not raised, the state mutex initiator 8 raises the control request flag 36 at step 106, which is detected by the state mutex terminator 22. However, if at step 104 the control confirmation flag 38 is raised, although the control request flag 36 has not been raised, this indicates that desynchronization 101 has occurred and the asynchronous bridge 2 waits until both the slave module 4 and the master module 6 detect the desynchronization 101 at step 103, then returns to step 102 and checks whether the state mutex is locked.
[0140] Assuming that desynchronization is not detected at step 104 and the control request flag is raised at step 106, the master module 6 determines at step 108 whether the lock flag 40 is raised. If the lock flag 40 is not currently raised, at step 110, the state mutex terminator 22 raises the control confirmation flag 38 in response to the control request flag 36 detected by the state mutex initiator 8. However, if the lock flag 40 is raised before the control confirmation flag 38 is raised at step 108, this indicates desynchronization 101. As described above, the asynchronous bridge 2 waits at step 103 until both the slave module 4 and the master module 6 detect desynchronization 101, and then returns to step 102 and checks whether the state mutex has been locked.
[0141] At step 112, the state mutex initiator 8 raises the mutex lock flag 40, and the mutex formed by the state mutex initiator 8 and the state mutex terminator 22 is locked. This request and confirmation procedure essentially forms a first two-phase handshake.
[0142] The program executed using the mutex ensures that the slave module 4 and the master module 6 are synchronized (ie, "coordinated") with each other, and monitors for desynchronization throughout the data transition, as described below.
[0143] If the mutex has been locked, the AHB receiver 10 can transmit the data received via the first bus 11 to the master module 6 across the asynchronous interface 7. In step 114, in order to signal that the data will be transmitted from the slave module 4 to the master module 6, the data mutex initiator 12 of the change channel (i.e., the data mutex initiator 12 of the slave module 4) switches the value of the data request flag 42. It should be understood that by switching the value of the data request flag 42, it means changing the value to the logical negation of its current value, i.e., if it is currently a digital '1', it is changed to a digital '0', and vice versa. The AHB receiver 10 then transmits the data 43 across the asynchronous interface 7 through the multi-flip-flop synchronizer 18, and raises the valid flag 45.
[0144] The data mutex terminator 26 of the changing channel (i.e., the data mutex terminator 26 of the master module 6) detects this change in the data request flag 42, and determines from the valid flag 45 that valid data 43 is present and ready to be transmitted to the second bus 13. The AHB transmitter 24 within the master module 6 receives the data 43 from the AHB receiver 10 (i.e., from the slave module 4) via the multi-trigger synchronizer 32. At step 118, the data mutex terminator 26 then switches the value of the data confirmation flag 44 to match the value of the data request flag 42, confirming the safe receipt of the data 43.
[0145] At step 120 it is determined whether more data is to be transferred across the asynchronous interface 7. If further data is to be transferred from the first bus 11 to the second bus 13, the program returns to step 102 and the process is repeated as described above. Otherwise, the program ends at step 122.
[0146] Although Figure 2 , but the AHB transmitter 24 within the master module 6 can similarly use the return channel to transmit data across the asynchronous interface 7 to the AHB receiver 10, i.e., using the data mutex initiator 28 of the master module 6 and the data mutex terminator 14 of the slave module 4. To signal that data is to be transmitted from the master module 6 to the slave module 4, the data mutex initiator 28 of the return channel switches the value of the data request flag 46. The AHB transmitter 24 then transmits the data 47 across the asynchronous interface 7 through the multi-trigger synchronizer 34 and raises the valid flag 49.
[0147] The data mutex terminator 14 of the return channel (i.e., the data mutex terminator 14 of the slave module 4) detects this change in the data request flag 46 and determines from the valid flag 49 that valid data 47 is present and ready to be transmitted to the first bus 11. The AHB receiver 10 within the slave module 4 receives the data 47 from the AHB transmitter 24 (i.e., from the master module 6) via the multi-trigger synchronizer 20. The data mutex terminator 14 then switches the value of the data confirmation flag 48 to match the value of the data request flag 46, confirming the safe receipt of the data 47.
[0148] Figure 3 It is displayed in Figure 1 1. A timing diagram of a state mutex locking operation used in an asynchronous bridge in FIG. 1. Initially, at time t0, the slave module 4 is held in reset by holding its asynchronous reset signal arst_slave at a logic high. At time t1, the asynchronous reset signal arst_slave of the slave module 4 is set to a logic low, allowing the slave module 4 to exit reset. Subsequently, at time t2, the slave module 4 begins the process of locking the state mutex by setting the internal signal getLock_slave to high, and also initiates the clock signal ck_slave, which clocks the components within the slave module 4 including the multi-flip-flop synchronizers 18, 20 for transmitting data from the first bus 11.
[0149] At time t3, the state mutex initiator 8 raises the control request flag 36, as previously described. In this case, no desynchronization occurs, and the state mutex terminator 22 determines that it should acknowledge the request. Before it does so, it initializes the clock signal ck_master used by the components of the master at t4. The master module 6 then determines that no desynchronization has occurred, and so can set the internal signal hasLock_master to a logic high at t5, indicating that the master module 6 considers the state mutex to be locked (pending for the slave module 4 to perform the same operation).
[0150] The state mutex terminator 22 then raises the control confirmation flag 38 at t6, which is detected by the state mutex initiator 8. The state mutex initiator 8 sets the internal signal hasLock_slave to logic high at t7, indicating that the slave module 4 considers the state mutex to be locked. The state mutex initiator 8 then sets the lock flag 40 to logic high at t8, indicating that the state mutex is locked.
[0151] Figure 4 is to show what happens when a slave module resets before the master module has its clock Figure 1When attempting to lock the state mutex, the state mutex initiator 8 will keep the lock flag 40 low and pull the control request flag 36 high only when the control confirmation flag 38 is low, as described above.
[0152] After the initial idle period 50, at time t9, the slave module 4 is reset by pulsing the asynchronous reset signal arst_slave of the slave module 4 to a logic high. The reset of the slave module 50 also pulls the control request flag 36 and the lock flag 40 to a logic low. Once the asynchronous reset signal arst_slave of the slave module 4 returns to a logic low, the slave module 4 is allowed to not reset, and the slave module enters a 'bootstrap' period 52 during which the slave module 4 attempts to begin locking the state mutex, as described above with reference to Figure 3 As described above, the internal signal getLock_slave is set high, and the clock signal ck_slave is initiated, as described above.
[0153] However, at time t 10 , when attempting to lock the status mutex, the control confirmation flag 38 is already high, indicating that the master module 6 has not detected the desynchronization. The slave module 4 then enters a wait cycle 54 until the master module 6 detects that the desynchronization has occurred (i.e., the master module 6 determines that the slave module 4 has been reset). The master module 6 at time t 11 The loss of lock of the state mutex is detected and its internal signal hasLock_master is set to logic low and another internal signal lostLock_master indicating that the state mutex has lost its lock is pulsed to logic high.
[0154] Once this is detected, at time t 12 , the state mutex enters a lock cycle 56, in which the state mutex initiator 8 and the terminator 22 undergo the above-mentioned locking procedure so that the state mutex is locked. Then, at time t 13 , the state mutex enters the locked state 58 until the lock is lost at a later time (not shown).
[0155] Figure 5 is to show that when slave module 4 disconnects the state mutex lock Figure 1 The timing diagram of the operation of the asynchronous bridge at time t 14 , the slave module 4 is reset by pulling the asynchronous reset signal arst_slave of the slave module 4 to logic high. When this happens, the state mutex control signals managed by the state mutex initiator 8, namely the control request flag 36 and the lock flag 40, are pulled to logic low. The master module 6 is at t 15The state mutex terminator 22 detects the loss of lock and sets its internal signal hasLock_master to logic low and pulses lostLock_master to logic high. Then, the state mutex terminator 22 is turned off at t 16 The control confirmation flag 38 is set to logic low.
[0156] Similarly, Figure 6 It shows that when the main module 6 disconnects the state mutex lock Figure 1 : Timing diagram of the operation of the asynchronous bridge.
[0157] At time t 17 , the master module 6 is reset by pulling the asynchronous reset signal arst_master of the master module 6 to logic high. When this happens, the state mutex control signal managed by the state mutex terminator 22, that is, the control confirmation flag 38, is pulled to logic low. The slave module 4 is at t 18 The lock loss is detected and the internal signal hasLock_slave is set to logic low and the signal lostLock_slave indicating that the mutex lock has been lost is pulsed to logic high. Then, the state mutex initiator 8 is turned on at t 19 The control request flag 36 and the lock flag 40 are set to logic low.
[0158] Figure 7 It is displayed in Figure 1 Timing diagram of the operation of the data mutex used in the asynchronous bridge in 20 , by setting the asynchronous reset signal arst_master of the master module 6 to logic low, the master module 6 is released from reset. 21 , the slave module 4 is also released from reset by setting the asynchronous reset signal arst_slave of the slave module 4 to logic low, and the data mutex initiator 12 pulses the signal newTrans(in) to logic high, indicating to the FSM 16 of the slave module 4 that a data transition event will occur. At this time t 21 , the data mutex initiator also starts transmitting data 43.
[0159] Once the data 43 has been established and stabilized, the data mutex initiator 12 sets the mutex at t 22 The value of the data request flag 42 is toggled, and the AHB receiver 10 then transmits the data 43 across the asynchronous interface 7 via the multi-flip flop synchronizer 18. For proper operation, the data 43 must remain stable until it is received by the master module 6.
[0160] After the data mutex terminator 26 synchronizes the switching of the data request flag 42, the data mutex terminator 26 is 23The signal newTrans(out) is pulsed to logic high, indicating to the FSM 30 of the master module 6 that a transition is occurring. After sampling the data 43, the FSM 30 of the master module 6 switches to logic high at t 24 Another signal acceptTrans(in) is set to logic high, indicating that the master module 6 has successfully accepted the transition. Then, the master module 6 25 The data confirmation flag 44 is switched to match the value of the data request flag 42 .
[0161] After detecting the switching of the data request flag 42, the slave module 4 starts at t 26 Another signal acceptTrans(out) is pulsed to logic high, indicating that the confirmation has been successfully accepted by the slave module 4, and at t 27 Arranging the wait signal to logic low ends the transition.
[0162] refer to Figure 7 The described process may then be repeated continuously until the state mutex loses its lock.
[0163] Therefore, it should be understood by those skilled in the art that embodiments of the present invention provide an improved electronic device including an oscillator circuit and an improved method for operating the electronic device, wherein a four-phase handshake is used for an initial transition in which a mutex is used to monitor the synchronization state of the bridge, but a two-phase transition is used for additional transitions as long as the mutex remains locked. Therefore, compared to a conventional two-phase handshake, an asynchronous bridge according to an embodiment of the present invention is more robust to desynchronization events while performing transitions faster than a conventional four-phase handshake. It should be understood by those skilled in the art that the above embodiments are merely exemplary and do not limit the scope of the present invention.
Claims
1. A method for transferring data from a first bus to a second bus across an asynchronous interface using an asynchronous bridge, wherein the asynchronous interface is between the first bus and the second bus, the asynchronous bridge comprising: a bus slave module connected to the first bus and comprising a forward channel initiator in a first power and / or clock domain; and a bus master module connected to the second bus and comprising a forward channel terminator in a second power and / or clock domain; wherein the forward channel initiator and the forward channel terminator communicate to form a forward lockable mutex for arbitrating access to a signal for transmitting data from the first power and / or clock domain to the second power and / or clock domain; The method comprises: If the lockable mutex is locked, transferring data between the first power and second power and / or clock domains using a forward data channel; If the lockable mutex is not locked, the forward channel initiator switches a state request signal and the forward channel terminator in response switches a state confirmation signal; The lockable mutex is thereby locked.
2. The method of claim 1, wherein the bus slave module comprises a reverse channel terminator and the bus master module comprises a reverse channel initiator; The reverse channel initiator and the reverse channel terminator are in communication to form a reverse lockable mutex for arbitrating access to a signal for transmitting data from the second power and / or clock domain to the first power and / or clock domain.
3. The method according to claim 2, further comprising: If the reverse lockable mutex is locked, transferring data between the second power and first power and / or clock domains using a reverse data channel; If the reverse lockable mutex is not locked, the reverse channel initiator switches a state request signal and the reverse channel terminator switches a state confirmation signal in response; The reverse lockable mutex is thereby locked.
4. The method according to claim 1, further comprising: If either side of the asynchronous bridge is reset or powered down causing desynchronization of the lockable mutex, the desynchronization is detected by the initiator or terminator on the other side.
5. The method according to claim 2 or 3, further comprising: If either side of the asynchronous bridge is reset or powered down causing desynchronization of the reverse lockable mutex, the desynchronization is detected by the initiator or terminator on the other side.
6. The method according to any one of claims 1 to 4, further comprising: If both sides of the asynchronous bridge are reset or powered down, causing desynchronization, resynchronization is automatically performed.
7. The method according to any one of claims 1 to 4, further comprising: If the lockable mutex is locked and the status request signal or the status confirmation signal changes value, resynchronization is performed.
8. The method according to claim 2 or 3, further comprising: If the reverse lockable mutex is locked and the status request signal or the status confirmation signal changes value, resynchronization is performed.
9. The method of claim 6, wherein the resynchronization comprises one of a switch state request signal from the channel initiator and a switch state confirmation signal from the corresponding channel terminator in response; the lockable mutex being thereby locked.
10. The method according to claim 2 or 3, further comprising: If both sides of the asynchronous bridge are reset or powered off, causing desynchronization, resynchronization is automatically performed. Wherein the resynchronization comprises one of a switch state request signal from the channel initiator and a switch state confirmation signal from the corresponding channel terminator in response; the reverse lockable mutex is thereby locked.
11. The method according to any one of claims 1 to 4, further comprising: If the lockable mutex is already locked, the status request and status confirmation signals are prevented from changing.
12. The method according to claim 2 or 3, further comprising: If the reverse lockable mutex is already locked, the status request and status confirmation signals are prevented from changing.
13. The method of any one of claims 1-4, if the lockable mutex is already locked, using two additional signals to implement a handshake, whereby each toggle of a data request signal indicates a request for a handshake, and each toggle of a data confirmation signal indicates completion of the handshake.
14. The method of claim 2 or 3, if the reverse lockable mutex is already locked, using two additional signals to implement handshaking, whereby each toggle of a data request signal indicates a request for handshaking, and each toggle of a data confirmation signal indicates completion of the handshake.
15. The method according to any one of claims 1 to 4, further comprising: If the status request and / or status confirmation signal changes value during data transmission, the module in the slave module and the master module that has detected the change in value changes all signals to corresponding reset values, and when the reset of the other module in the slave module and the master module is completed before the other side can return to the reset value, the other module waits until all handshake signals across the boundary become their reset values again.
16. An asynchronous bridge device, the asynchronous bridge device being arranged to transfer data from a first bus to a second bus across an asynchronous interface, the asynchronous interface being between the first bus and the second bus, the asynchronous bridge device comprising: a bus slave module connected to the first bus and comprising a forward channel initiator in a first power and / or clock domain; and a bus master module connected to the second bus and comprising a forward channel terminator in a second power and / or clock domain; wherein the forward channel initiator and the forward channel terminator communicate to form a forward lockable mutex for arbitrating access to a signal for transmitting data from the first power and / or clock domain to the second power and / or clock domain; The asynchronous bridge device is arranged such that: If the lockable mutex is locked, the asynchronous bridge device transmits data between the first power and second power and / or clock domains using a forward data channel; If the lockable mutex is not locked, the forward channel initiator switches a state request signal and the forward channel terminator in response switches a state confirmation signal; The lockable mutex is thereby locked.