Patent Description:
Modern electronic devices, for example radio transceiver devices arranged to carry out wireless communication such as Bluetooth® or Wi-Fi® communication, may have two or more different power and/or clock domains that may be required, at least sporadically, to communicate with each other.

A clock domain refers to circuitry that is driven by a particular clock signal while a power domain refers to circuitry that driven by the same supply voltage. For example, a central processor may run in a first clock domain at a relatively high frequency while one or more peripherals may run in a second clock domain at a relatively low frequency. Generally speaking, when different power and clock domains are not synchronised with each other, an asynchronous crossing of signals across power and/or clock domain boundaries is required to pass from one domain to another.

This is relevant for transferring data between two different buses, e.g. between two AHB buses where each bus is in a different clock and/or power domain, where AHB is an Advanced High Performance Bus (AHB) within the Arm® AMBA® (Advanced Microcontroller Bus Architecture) protocol, an open standard interconnect specification for the connection and management of functional blocks in a system-on-chip (SoC), i.e. for on-chip communication. An asynchronous AHB-AHB bridge may typically be used to facilitate the transfer of data from one AHB to the other, where the originating AHB is connected as a slave component to the bridge, (referred to herein as a 'slave') and the destination AHB has the same bridge connected as an AHB master component (referred to herein as a 'master').

It is known in systems which include different power and/or clock domains which are not synchronised to each other, and may be of different frequencies, to employ a "handshaking" procedure in which the clock domains negotiate parameters in order to establish that each side is in agreement as to the state of a specific data signal or signals crossing the boundary between the domains. This is necessary so that a signal can be transferred from one power and/or clock domain to another during a safe period for doing so (e.g. away from a transition in the clock signal used by the receiving clock domain).

One type of handshaking procedure, known in the art per se, is a two-phase or two-step handshaking procedure. In a two-phase handshaking procedure, the initiator begins by toggling the state of its request signal (i.e. flipping the signal either from low to high or from high to low, changing its previous state to the opposite state as appropriate). The receiver then acknowledges this request by toggling the state of its acknowledgement signal to complete the handshake. However, the Applicant has appreciated that this two-phase process is unsuitable for use when either side - i.e. the initiator or receiver - may reset (or even power off, such that isolation clamp values define the signal state observed by the other side) during the handshake as this reset can, in some circumstances, be seen as the completion of the handshake. For example, if the acknowledgement signal was previously high and the receiver resets, the acknowledgement signal may change to low due to the reset rather than as an actual acknowledgement of the initiator's request. The result of this would be that any data being transferred across a power and/or clock boundary would be lost as the receiving side is not actually capable of receiving any data. This issue of undesired state changes due to reset and/or losing power in a handshake is known as desynchronisation.

There exists also a four-phase handshaking procedure, known in the art per se, that attempt to overcome this drawback, for example making use of Gray coding to allow invalid transitions to be detected. However, known four-phase handshaking procedures are relatively slow as they begin and end each handshake in a defined 'idle' or 'start' phase, which requires four phase transitions to return to 'idle' or 'start'. As such, while a four phase handshake is more resilient against data loss due to desynchronisation, a four phase handshake takes twice as long as a two phase handshake, resulting in a severe throughput penalty.

It is an aim of the present invention to provide improved systems and methods for communication between two different power and/or clock domains.

<CIT> appears to disclose an interface between two buses in different clock domains. The interface includes a master buffer which is used for both master writes and slave reads. A control logic unit for each bus receives signals from a buffer manager which straddles the clock domains to gate latch pulses to the master buffer.

<CIT> discloses a multiple transaction advanced high performance bus AHB system comprising two AHB buses capable of simultaneous activity. The two buses are separated by and synchronised with an AHB-to-HTB bus bridge.

When viewed from a first aspect, the present invention provides a method of transferring data from a first bus to a second bus across an asynchronous interface between said first and second buses according to claim <NUM>.

This first 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 between said first and second buses according to claim <NUM>.

In a set of embodiments the bus slave module comprises a reverse-channel terminator and the bus master module comprises a reverse-channel initiator wherein the reverse-channel initiator and the reverse-channel terminator are in communication to form a reverse status mutex for arbitrating access to signals used to transfer data from the second power and/or clock domain to the first power and/or clock domain.

In a set of the foregoing embodiments, the method further comprises:.

In a set of embodiments if either side of the asynchronous bridge is reset or loses power thereby giving rise to a desynchronisation of the reverse status mutex, detecting said desynchronisation by the reverse channel initiator or reverse channel terminator on the other side;.

In a set of embodiments if both sides of the asynchronous bridge are reset or lose power thereby giving rise to a desynchronisation, automatically performing a resynchronisation.

In a set of embodiments if the status mutex and/or the reverse status is/are locked, and the control request flag or the control acknowledgement flag changes value and/or the reverse control request flag or the reverse control acknowledgement flag changes value, performing a resynchronisation.

In a set of the foregoing embodiments said resynchronisation comprises said forward channel initiator toggling the control request flag or said reverse channel initiator toggling the reverse control request flag and the corresponding forward channel terminator toggling the control acknowledgement flag or the reverse channel terminator toggling the reverse control acknowledgment flag in response; the status mutex and/or the reverse status mutex thereby becoming locked.

In a set of embodiments if the status mutex and/or the reverse status is/are locked, a change in the control request and control acknowledgement flags and/or the reverse control request and reverse control acknowledgment flags is prevented.

In a set of embodiments if the status mutex and/or the reverse status mutex is/are locked, using two signals to implement a handshake whereby each toggle of a data-request signal indicates a request for the handshake and each toggle of a data-acknowledge signal indicates the completion of the handshake.

In a set of embodiments if, during a data transfer the control request flag and/or control acknowledgement flags change value, one of the bus slave module and the bus master module which has detected said change in value, changing all flags to corresponding reset values and the other of the bus slave module and the bus master module, when its reset completes before the other side can return to the reset value, waiting until all handshake flags across the boundary are their reset values again.

In accordance with embodiments of the invention, there is provided an improved electronic device and method of operating the same in which an improved four-phase handshake is used to determine whether the slave and master modules have been desynchronised before completing the transfer of data across the asynchronous interface. The Applicant has appreciated that such an arrangement may result in a handshake protocol with the same number of phases as a conventional four-phase handshake when no status synchronisation is available (e.g. when one or both sides are not powered up and ready for use) - namely two steps dedicated to performing a status handshake and then two steps dedicated to performing a data transfer handshake, but then only requires the two-phase data transfer handshake for subsequent data transfers until either or both of the master and slave modules reset (and the status 'lock' is lost due to desynchronisation).

In at least embodiments, an initial four-phase handshake is carried out for the first transaction, and the described handshake is used in order to monitor that neither the slave module nor the master module has reset and caused a desynchronisation (because if one or both of these modules resets, the semaphore/mutex has to reset i.e. loses its lock), which provides the robustness associated with some known four-phase handshake procedures as outlined above. However, subsequent transactions may advantageously occur at the speeds typically associated with two-phase handshake procedures, because the semaphore/ mutex is used to ensure that the synchronisation status established earlier in the initial four phase handshake procedure can still be trusted, removing the need to check the synchronisation status for every data transaction.

As outlined previously, those skilled in the art will appreciate that the term 'desynchronisation' and derivatives thereof as used herein mean that the initiator and terminator modules, which are typically asynchronous from the point of view of their clock domains but communicate across the asynchronous interface through use of handshake arrangements to implement a mutex, become 'out of step' with one another, for example where the internal states of each module conflict with one another. This misalignment of states is thus more than merely a consequence of how the modules are clocked.

As most bus protocols only provide the possibility for data to be sent by a bus slave to a bus master in response to a request by said master, the reverse data channel of the described bridge may only be used 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 bus slave in another. As such, the status part of the handshake as described may provide the same information for both the forward and reverse mutexes. In order to save time and logic, the reverse channel can therefore use the status lock of the forward channel, as any desynchronisation happens for both channels at the same time.

Those skilled in the art will appreciate that the described handshake may be seen as a composite of a status handshake or status mutex and a data handshake or data mutex.

As with existing two and four phase handshakes when applied across asynchronous boundaries, a desynchronisation due to reset or otherwise can cause data hazards when sampling data (across this asynchronous boundary) as well as race conditions due to data hazards (meta-stability or asynchronous reset between signals) on the control signals. Embodiments may seek to mitigate these by any one of more of the following: delaying detected phase changes for the data mutex by one cycle, holding data after capture for enough cycles to detect whether captured data is valid (reducing throughput) or providing an early warning signal to the bridge component that the other side is bound to reset soon and any changes from the data mutex should be ignored to prevent a data hazard (best performance).

Any unexpected reset of the receiving side may, in some arrangements, be detected and recovered from using only information from the 'control channels', where one channel, handled by the status mutex, carries status information (that both the slave module and the master module are ready to carry out transactions) and the second channel, handled by the semaphore or data mutex (e.g. the semaphore initiator and terminator pair), provides a transaction-specific handshake to guard data crossing the asynchronous interface, i.e. a power and/or clock boundary.

The Applicant has appreciated that an asynchronous bridge in accordance with embodiments of the present invention may support multiple independent power domains and resets, unlike conventional two-phase handshake procedures known in the art per se. Furthermore, because the power and reset status may be determined locally by such a bridge, there may advantageously be no need for a global power and clock manager.

It will be appreciated by those skilled in the art that a mutex is typically an arrangement that provides for mutual exclusion concurrency control (i.e. control that ensures correct results for concurrent operations). The status mutex comprises a control request flag, a control acknowledgement flag, and a mutex lock flag, wherein the status mutex is arranged such that:.

The status mutex may be considered the implementation part of the described handshake which ensures both sides are ready for use.

The semaphore referred to herein may have a value of <NUM> and thus may be considered to be a mutex or a data mutex. References herein to a semaphore initiator and a semaphore terminator may therefore be understood accordingly as references to a mutex initiator and a mutex terminator respectively or to a data mutex initiator and a data mutex terminator.

In a set of such embodiments, the master module is arranged to determine that a desynchronisation event has occurred when the control request flag and the mutex lock flag are raised while the status mutex is not locked.

Thus, in accordance with such embodiments, the slave module may be arranged to determine that a desynchronisation event has not yet been detected by the master module, which is indicated by the control acknowledgement flag being raised even though the slave module has not raised the control request flag since the last reset of the slave module.

It will be appreciated that the embodiments of the present invention described hereinabove provide for communication of data from the first bus to the second bus, such that the semaphore/data mutex initiator of the slave module and the semaphore/data mutex terminator of the master module form a transaction channel. In some embodiments the slave module comprises a return (reverse-channel) data mutex/semaphore terminator and the master module comprises a return data mutex/semaphore initiator, wherein the asynchronous bridge is further arranged such that:.

In at least some embodiments, the slave module raises a valid flag when it has data to send to the master module, wherein the valid flag is cleared when the slave module is reset. Preferably, the valid flag is cleared when either of the slave module and the master module is reset. In a set of potentially overlapping embodiments wherein a return channel is provided as outlined above, the master module raises a further valid flag when it has data to send to the slave module, wherein the further valid flag is cleared when the master module is reset. Preferably, the further valid flag is cleared when either of the slave module and the master module is reset.

It will be appreciated by those skilled in the art that an asynchronous bridge operating in accordance with embodiments of the claimed invention may overcome issues with an unscheduled power off (or reset) occurring which causes erroneous behaviour in the master module and/or the slave module. However, the Applicant has appreciated that, in some situations, power offs and resets might be known about in advance, i.e. they are scheduled, albeit not always a long time in advance - i.e. such a reset may be scheduled for a certain time or may be scheduled imminently in response to a particular event. In some embodiments, the slave module is arranged to send a warning signal directly to the master module when the slave module has a power off event or reset event scheduled, wherein the master module is arranged to abort any current transaction of data across the asynchronous interface upon receiving said warning signal. In a set of potentially overlapping embodiments, the master module is arranged to send a warning signal directly to the slave module when the master module has a power off event or reset event scheduled, wherein the slave module is arranged to abort any current transaction of data across the asynchronous interface upon receiving said warning signal. Thus, in accordance with such embodiments, the slave module and/or the master module may be warned in advance of an upcoming power off of the other module and abort any current transactions which may prevent errors.

Certain embodiments of the invention will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which:.

<FIG> is a schematic diagram of an asynchronous bridge <NUM> in accordance with an embodiment of the present invention. The asynchronous bridge <NUM> comprises a slave module <NUM> and a master module <NUM>, which are separated by an asynchronous boundary <NUM>. This asynchronous boundary <NUM> is a result of the slave module <NUM> and master module <NUM> being located within different power and clock domains. It will of course be appreciated that the slave module <NUM> and master module <NUM> could be in different clock domains but in the same power domain or vice versa, however in this exemplary embodiment, the modules <NUM>, <NUM> are in both different clock and power domains.

The slave module <NUM> comprises: a status mutex initiator <NUM>; an AHB receiver <NUM>; a data mutex initiator <NUM>; and a data mutex terminator <NUM>. The AHB receiver <NUM> comprises: a finite state machine (FSM) <NUM>; and two multi-flip-flop synchronisers <NUM>, <NUM>. The AHB receiver <NUM> is known as a 'receiver', because it receives data from a first bus <NUM>.

The master module <NUM> comprises: a status mutex terminator <NUM>; an AHB transmitter <NUM>; a data mutex terminator <NUM>; and a data mutex initiator <NUM>. The AHB transmitter <NUM> comprises: an FSM <NUM>; and two multi-flip-flop synchronisers <NUM>, <NUM>. The AHB transmitter <NUM> is known as a transmitter, because it transmits data to a second bus <NUM>.

The status mutex initiator <NUM> of the slave module <NUM> and the status mutex terminator <NUM> of the master module <NUM> together form a 'status mutex', i.e. a mutex that monitors the status of the connection between the slave module <NUM> and the master module <NUM> across the asynchronous interface <NUM> as will be described in further detail below.

Similarly, the data mutex initiator <NUM> of the slave module <NUM> and the data mutex terminator <NUM> of the master module <NUM> together form a transaction channel between the slave module <NUM> and the master module <NUM>, while the data mutex terminator <NUM> of the slave module <NUM> and the data mutex initiator <NUM> of the master module <NUM> together form a return channel between the slave module <NUM> and the master module <NUM>.

The procedure used to transfer data <NUM> from the first bus <NUM> to the second bus <NUM> is described below with reference to <FIG>, which is a flowchart showing the handshaking and transfer procedure carried out by the asynchronous bridge <NUM> when the slave module <NUM> receives data via the first bus <NUM> that needs to be transferred to the second bus <NUM> across the asynchronous interface <NUM> (i.e. over the clock- and power-domain boundary).

The procedure is initialised at step <NUM>, and the slave module <NUM> determines whether the status mutex is currently locked at step <NUM>. If the status mutex is not currently locked, the slave module determines whether the control acknowledgement flag <NUM> is raised or not. If the control acknowledgement flag <NUM> is not raised, the status mutex initiator <NUM> raises a control request flag <NUM> at step <NUM>, which is detected by the status mutex terminator <NUM>. However, if at step <NUM> the control acknowledgement flag <NUM> is raised despite the control request flag <NUM> not yet being raised, this indicates a desynchronisation <NUM> has occurred and that the asynchronous bridge <NUM> waits at step <NUM> until the desynchronisation <NUM> has been detected by both the slave module <NUM> and the master module <NUM> before returning to step <NUM> and checking whether the status mutex is locked.

Assuming no desynchronisation is detected at step <NUM> and that the control request flag was raised at step <NUM>, the master module <NUM> determines, at step <NUM>, whether the locked flag <NUM> is raised. If the locked flag <NUM> is not currently raised, the status mutex terminator <NUM> then raises a control acknowledgement flag <NUM> in response to the control request flag <NUM> at step <NUM>, which is detected by the status mutex initiator <NUM>. If, however, at step <NUM> the locked flag <NUM> is raised before the control acknowledgement flag <NUM> has been, this indicates a desynchronisation <NUM>. As outlined above, the asynchronous bridge <NUM> waits at step <NUM> until the desynchronisation <NUM> has been detected by both the slave module <NUM> and the master module <NUM> before returning to step <NUM> and checking whether the status mutex is locked.

At step <NUM>, the status mutex initiator <NUM> raises a mutex locked flag <NUM> and the mutex formed by the status mutex initiator <NUM> and the status mutex terminator <NUM> is locked. This request-and-acknowledgement procedure essentially forms a first two-phase handshake.

The procedure carried out using the mutex assures that the slave module <NUM> and the master module <NUM> are synchronised to (i.e. 'in step' with) each other and monitors this for desynchronisation throughout data transactions, as outlined below.

Providing the mutex is locked, the AHB receiver <NUM> may transfer data received via the first bus <NUM> to the master module <NUM> across the asynchronous interface <NUM>. In order to signal that data is to be transferred from the slave module <NUM> to the master module <NUM>, the data mutex initiator <NUM> of the transaction channel (i.e. the data mutex initiator <NUM> of the slave module <NUM>) toggles the value of a data request flag <NUM> at step <NUM>. It will be appreciated that by toggling the value of the data request flag <NUM>, this means changing the value to the logical negation of its current value, i.e. if it is currently a digital '<NUM>', it is changed to a digital '<NUM>' and vice versa. The AHB receiver <NUM> then transfers the data <NUM> across the asynchronous interface <NUM> through the multi-flip-flop synchroniser <NUM> and raises a valid flag <NUM>.

The data mutex terminator <NUM> of the transaction channel (i.e. the data mutex terminator <NUM> of the master module <NUM>) detects this change in the data request flag <NUM> and determines from the valid flag <NUM> that valid data <NUM> is present and ready to be transferred across to the second bus <NUM>. The AHB transmitter <NUM> within the master module <NUM> receives the data <NUM> from the AHB receiver <NUM> (i.e. from the slave module <NUM>) via the multi-flip-flop synchroniser <NUM>. The data mutex terminator <NUM> then toggles the value of a data acknowledgement flag <NUM> so as to match the value of the data request flag <NUM>, acknowledging the safe receipt of the data <NUM> at step <NUM>.

It is determined at step <NUM> whether more data is to be transferred across the asynchronous interface <NUM>. If further data is to be transferred from the first bus <NUM> to the second bus <NUM>, the procedure returns to step <NUM> and the process is repeated as outlined above. Otherwise, the procedure ends at step <NUM>.

While not shown in <FIG>, the AHB transmitter <NUM> within the master module <NUM> may similarly transfer data to the AHB receiver <NUM> across the asynchronous interface <NUM> using the return channel, i.e. using the data mutex initiator <NUM> of the master module <NUM> and the data mutex terminator <NUM> of the slave module <NUM>. In order to signal that data is to be transferred from the master module <NUM> to the slave module <NUM>, the data mutex initiator <NUM> of the return channel toggles the value of a data request flag <NUM>. The AHB transmitter <NUM> then transfers the data <NUM> across the asynchronous interface <NUM> through the multi-flip-flop synchroniser <NUM> and raises a valid flag <NUM>.

The data mutex terminator <NUM> of the return channel (i.e. the data mutex terminator <NUM> of the slave module <NUM>) detects this change in the data request flag <NUM> and determines from the valid flag <NUM> that valid data <NUM> is present and ready to be transferred across to the first bus <NUM>. The AHB receiver <NUM> within the slave module <NUM> receives the data <NUM> from the AHB transmitter <NUM> (i.e. from the master module <NUM>) via the multi-flip-flop synchroniser <NUM>. The data mutex terminator <NUM> then toggles the value of a data acknowledgement flag <NUM> so as to match the value of the data request flag <NUM>, acknowledging the safe receipt of the data <NUM>.

<FIG> is a timing diagram showing the status mutex locking operation used in the asynchronous bridge of <FIG>. Initially, at time t<NUM>, the slave module <NUM> is held in reset by its asynchronous reset signal arst_slave being held at logic high. At time t<NUM>, the asynchronous reset signal arst_slave of the slave module <NUM> is set to logic low, allowing the slave module <NUM> out of reset. Subsequently, at time t<NUM>, the slave module <NUM> starts the process of locking the status mutex by setting an internal signal getLock_slave high, and also initiates a clock signal ck_slave which clocks components within the slave module <NUM>, including the multi-flip-flop synchronisers <NUM>, <NUM> that are used for transferring data from the first bus <NUM>.

At time t<NUM>, the status mutex initiator <NUM> raises a control request flag <NUM> as outlined previously above. In this case, no desynchronisation takes place and the status mutex terminator <NUM> determines that it should acknowledge the request. Before it does so, a clock signal ck_master used by components of the master is initialised at t<NUM>. The master module <NUM> subsequently determines that no desynchronisation has taken place and so can set an internal signal hasLock_master to logic high at t<NUM>, indicating that the master module <NUM> considers the status mutex to be locked (pending the slave module <NUM> doing the same).

The status mutex terminator <NUM> subsequently raises the control acknowledgement flag <NUM> at t<NUM>, which is detected by the status mutex initiator <NUM>. The status mutex initiator <NUM> sets an internal signal hasLock_slave to logic high at t<NUM>, indicating that the slave module <NUM> considers the status mutex to be locked. The status mutex initiator <NUM> then sets the locked flag <NUM> to logic high at t<NUM>, indicating that the status mutex is locked.

<FIG> is a timing diagram showing the desynchronisation operation of the asynchronous bridge of <FIG> when the slave module resets before the master module is provided with its clock. When attempting to lock the status mutex, the status mutex initiator <NUM> will keep the locked flag <NUM> low and pull the control request flag <NUM> high, but only if the control acknowledgement flag <NUM> is low, as outlined previously.

After an initial idle period <NUM>, at time t<NUM>, the slave module <NUM> is reset by pulsing its asynchronous reset signal arst_slave to logic high. The reset of the slave module <NUM> also pulls the control request flag <NUM> and the locked flag <NUM> to logic low. Once the asynchronous reset signal arst_slave of the slave module <NUM> returns to logic low, the slave module <NUM> is allowed out of reset and the slave module enters a 'bootstrapping' period <NUM>, during which time the slave module <NUM> attempts to start locking the status mutex as outlined above with reference to <FIG>, setting the internal signal getLock_slave high and initiating the clock signal ck_slave as outlined above.

However, at time t<NUM>, the control acknowledgement flag <NUM> is already high when attempting to lock the status mutex, this indicates that the master module <NUM> has not yet detected the desynchronisation. The slave module <NUM> then enters a wait period <NUM> until the master module <NUM> detects that the desynchronisation has occurred (i.e. the master module <NUM> determines that the slave module <NUM> has been reset). The master module <NUM> detects the loss of the lock of the status mutex at time t<NUM>, and sets its internal signal hasLock_master to logic low and pulses a further internal signal lostLock_master, that indicates the status mutex having lost its lock, to logic high.

Once this has been detected, the status mutex enters a locking period <NUM> at time t<NUM> in which the status mutex initiator <NUM> and terminator <NUM> undergo the locking procedure outlined above such that the status mutex is locked. The status mutex then enters a locked state <NUM> at time t<NUM> thereafter until the lock is lost at a later time (not shown).

<FIG> is a timing diagram showing the operation of the asynchronous bridge of <FIG> when the slave module <NUM> breaks the status mutex lock. At time t<NUM>, the slave module <NUM> is reset by pulling its asynchronous reset signal arst_slave to logic high. When this occurs, the status mutex control signals managed by the status mutex initiator <NUM>, i.e. the control request flag <NUM> and the locked flag <NUM> are pulled to logic low. The master module <NUM> detects the loss of the lock at t<NUM> and sets its internal signal hasLock_master to logic low and pulses lostLock_master to logic high. The status mutex terminator <NUM> then sets the control acknowledgement flag <NUM> to logic low at t<NUM>.

Similarly, <FIG> is a timing diagram showing the operation of the asynchronous bridge of <FIG> when the master module <NUM> breaks the status mutex lock.

At time t<NUM>, the master module <NUM> is reset by pulling its asynchronous reset signal arst_master to logic high. When this occurs, the status mutex control signal managed by the status mutex terminator <NUM>, i.e. the control acknowledgement flag <NUM> is pulled to logic low. The slave module <NUM> detects the loss of the lock at t<NUM> and sets an internal signal hasLock_slave to logic low and pulses a signal lostLock_slave indicating that the mutex lock has been lost to logic high. The status mutex initiator <NUM> then sets the control request flag <NUM> and the locked flag <NUM> to logic low at t<NUM>.

<FIG> is a timing diagram showing the operation of the data mutex used in the asynchronous bridge of <FIG>. At time t<NUM>, the master module <NUM> is released from reset by setting its asynchronous reset signal arst_master to logic low. At time t<NUM>, the slave module <NUM> is also released from reset by setting its asynchronous reset signal arst_slave to logic low, and the data mutex initiator <NUM> pulses a signal newTrans(in) to logic high, which indicates to the FSM <NUM> of the slave module <NUM> that a data transaction event is to occur. The data mutex initiator also begins transferring the data <NUM> at this time t<NUM>.

Once the data <NUM> has been set up and is stable, the data mutex initiator <NUM> toggles the value of the data request flag <NUM> at t<NUM> and the AHB receiver <NUM> then transfers the data <NUM> across the asynchronous interface <NUM> through the multi-flip-flop synchroniser <NUM>. For correct operation, the data <NUM> must remain stable until it is received by the master module <NUM>.

After the data mutex terminator <NUM> has synchronised the toggling of the data request flag <NUM>, the data mutex terminator <NUM> pulses a signal newTrans(out) to logic high at t<NUM>, which indicates to the FSM <NUM> of the master module <NUM> that a transaction is occurring. After sampling the data <NUM>, the FSM <NUM> of the master module <NUM> sets a further signal acceptTrans(in) to logic high at t<NUM>, which indicates that the transaction has been successfully accepted by the master module <NUM>. The master module <NUM> then toggles the data acknowledgement flag <NUM> to match the value of the data request flag <NUM> at t<NUM>.

After detecting the toggling of the data request flag <NUM>, at t<NUM> the slave module <NUM> pulses a further signal acceptTrans(out) to logic high, which indicates that the acknowledgement has been successfully accepted by the slave module <NUM>, and sets the waiting signal to logic low at t<NUM>, concluding the transaction.

The process described with reference to <FIG> may then be repeated continually until such a time that the status mutex loses its lock.

Claim 1:
A method of transferring data from a first bus (<NUM>) to a second bus (<NUM>) across an asynchronous interface (<NUM>) between said first and second buses (<NUM>, <NUM>), using an asynchronous bridge (<NUM>) comprising:
a bus slave module (<NUM>), connected to the first bus (<NUM>), comprising a forward-channel initiator (<NUM>) in a first power and/or clock domain; and
a bus master module (<NUM>), connected to the second bus (<NUM>), comprising a forward-channel terminator (<NUM>) in a second power and/or clock domain; wherein the forward-channel initiator (<NUM>) and the forward-channel terminator (<NUM>) are in communication to form a status mutex for arbitrating access to signals used to transfer data from the first power and/or clock domain to the second power and/or clock domain, wherein the status mutex comprises a control request flag (<NUM>), a control acknowledgement flag (<NUM>), and a mutex lock flag (<NUM>), and wherein the status mutex is arranged such that:
the forward-channel initiator (<NUM>) raises the control request flag (<NUM>) only when the control acknowledgement flag (<NUM>) is not raised;
the forward-channel terminator (<NUM>) raises the control acknowledgement flag (<NUM>) in response to the control request flag (<NUM>) being raised only when the mutex lock flag (<NUM>) is not raised;
the status mutex is locked and the forward-channel initiator (<NUM>) raises the mutex lock flag (<NUM>) in response to the control acknowledgement flag being raised;
the method comprising:
if the status mutex is locked (<NUM>), using a forward data channel (<NUM>) to transfer data between said first and second power and/or clock domains;
if the status mutex is unlocked (<NUM>), said forward channel initiator (<NUM>) toggling the control request flag (<NUM>) and the forward channel terminator (<NUM>) toggling the control acknowledgement flag (<NUM>) in response; the status mutex thereby becoming locked;
wherein if either side of the asynchronous bridge (<NUM>) is reset or loses power thereby giving rise to a desynchronisation of the status mutex, detecting said desynchronisation by the forward-channel initiator (<NUM>) or the forward-channel terminator (<NUM>) on the other side.