Asynchronous communication

Abstract

A method of transferring data from a first bus to a second bus across an asynchronous interface using an asynchronous bridge. The bridge comprises a bus slave module, connected to the first bus, comprising a forward-channel initiator in a first power and/or clock domain; and a bus master module, connected to the second bus, comprising a forward-channel terminator in a second power and/or clock domain. The forward-channel initiator and terminator are in communication to form a forward lockable mutex for arbitrating access to signals used to transfer data from the first domain to the second domain. If the mutex is locked, a forward data channel is used to transfer data between the domains. Otherwise if the mutex is unlocked, the forward channel initiator toggles a status request signal and the forward channel terminator toggles a status acknowledge signal in response, the mutex thereby becoming locked.

Claims

1. A method of transferring data from a first bus to a second bus across an asynchronous interface between said first and second buses, using an asynchronous bridge comprising: a bus slave module, connected to the first bus, comprising a forward-channel initiator in a first power and/or clock domain; and a bus master module, connected to the second bus, comprising a forward-channel terminator in a second power and/or clock domain; wherein the forward-channel initiator and the forward-channel terminator are in communication to form a forward lockable 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; the method comprising: if said lockable mutex is locked, using a forward data channel to transfer data between said first and second power and/or clock domains; if said lockable mutex is unlocked, said forward channel initiator toggling a status request signal and the forward channel terminator toggling a status acknowledge signal in response; the lockable mutex thereby becoming locked.

2. The method as claimed in claim 1, wherein 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 lockable 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.

3. The method as claimed in claim 2, further comprising: if said reverse lockable mutex is locked, using a reverse data channel to transfer data between said second and first power and/or clock domains; if said reverse lockable mutex is unlocked, said reverse channel initiator toggling a status request signal and the reverse channel terminator toggling a status acknowledge signal in response; the reverse lockable mutex thereby becoming locked.

4. The method as claimed in claim 1, further comprising: if either side of the asynchronous bridge is reset or loses power thereby giving rise to a desynchronisation of the lockable mutex and/or the reverse lockable mutex, detecting said desynchronisation by the initiator or terminator on the other side.

5. The method as claimed in claim 1, further comprising: if both sides of the asynchronous bridge are reset or lose power thereby giving rise to a desynchronisation, automatically performing a resynchronisation.

6. The method as claimed in claim 1, further comprising: if the lockable mutex and/or the reverse lockable mutex is/are locked, and a status request signal or a status acknowledge signal changes value, performing a resynchronisation.

7. The method as claimed in claim 5, wherein said resynchronisation comprises one of said channel initiators toggling a status request signal and the corresponding channel terminator toggling a status acknowledge signal in response; the lockable mutex and/or the reverse lockable mutex thereby becoming locked.

8. The method as claimed in claim 1, further comprising: if the lockable mutex and/or the reverse lockable mutex is/are locked, preventing a change in the status request and status acknowledge signals.

9. The method as claimed in claim 2 wherein, if the lockable mutex and/or the reverse lockable mutex is/are locked, using two additional signals to implement a handshake whereby each toggle of a data-request signal indicates a request for handshake and each toggle of data-acknowledge indicates the completion of the handshake.

10. The method as claimed in claim 1, further comprising: if, during a data transfer, the status request and/or status acknowledge signals change value, one of the slave module and the master module which has detected said change in value, changing all signals to corresponding reset values and the other of the slave module and the master module, when its reset completes before the other side can return to the reset value, waiting until all handshake signals across the boundary are their reset values again.

11. 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, said asynchronous bridge comprising: a bus slave module, connected to the first bus, comprising a forward-channel initiator in a first power and/or clock domain; and a bus master module, connected to the second bus, comprising a forward-channel terminator in a second power and/or clock domain; wherein the forward-channel initiator and the forward-channel terminator are in communication to form a forward lockable 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 asynchronous bridge is arranged such that: if said lockable mutex is locked, the asynchronous bridge uses a forward data channel to transfer data between said first and second power and/or clock domains; if said lockable mutex is unlocked, said forward channel initiator toggles a status request signal and the forward channel terminator toggles a status acknowledge signal in response; the lockable mutex thereby becoming locked.

Description

BRIEF DESCRIPTION OF DRAWINGS

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

(2) FIG. 1 is a schematic diagram of an asynchronous bridge in accordance with an embodiment of the present invention;

(3) FIG. 2 is a flowchart showing the handshaking and transfer procedure carried out by the asynchronous bridge of FIG. 1;

(4) FIG. 3 is a timing diagram showing the status mutex locking operation used in the asynchronous bridge of FIG. 1;

(5) FIG. 4 is a timing diagram showing the desynchronisation operation of the asynchronous bridge of FIG. 1 when the slave module resets before the master module is provided with its clock;

(6) FIG. 5 is a timing diagram showing the operation of the asynchronous bridge of FIG. 1 when the slave module breaks the status mutex lock;

(7) FIG. 6 is a timing diagram showing the operation of the asynchronous bridge of FIG. 1 when the master module breaks the status mutex lock; and

(8) FIG. 7 is a timing diagram showing the operation of the semaphore used in the asynchronous bridge of FIG. 1.

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

(10) The slave module 4 comprises: a status mutex initiator 8; an AHB receiver 10; a data mutex initiator 12; and a data mutex terminator 14. The AHB receiver 10 comprises: a finite state machine (FSM) 16; and two multi-flip-flop synchronisers 18, 20. The AHB receiver 10 is known as a ‘receiver’, because it receives data from a first bus 11.

(11) The master module 6 comprises: a status mutex terminator 22; an AHB transmitter 24; a data mutex terminator 26; and a data mutex initiator 28. The AHB transmitter 24 comprises: an FSM 30; and two multi-flip-flop synchronisers 32, 34. The AHB transmitter 24 is known as a transmitter, because it transmits data to a second bus 13.

(12) The status mutex initiator 8 of the slave module 4 and the status mutex terminator 22 of the master module 6 together form a ‘status mutex’, i.e. a mutex that monitors the status of the connection between the slave module 4 and the master module 6 across the asynchronous interface 7 as will be described in further detail below.

(13) 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 transaction 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.

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

(15) The procedure is initialised at step 100, and the slave module 4 determines whether the status mutex is currently locked at step 102. If the status mutex is not currently locked, the slave module determines whether the control acknowledgement flag 38 is raised or not. If the control acknowledgement flag 38 is not raised, the status mutex initiator 8 raises a control request flag 36 at step 106, which is detected by the status mutex terminator 22. However, if at step 104 the control acknowledgement flag 38 is raised despite the control request flag 36 not yet being raised, this indicates a desynchronisation 101 has occurred and that the asynchronous bridge 2 waits at step 103 until the desynchronisation 101 has been detected by both the slave module 4 and the master module 6 before returning to step 102 and checking whether the status mutex is locked.

(16) Assuming no desynchronisation is detected at step 104 and that the control request flag was raised at step 106, the master module 6 determines, at step 108, whether the locked flag 40 is raised. If the locked flag 40 is not currently raised, the status mutex terminator 22 then raises a control acknowledgement flag 38 in response to the control request flag 36 at step 110, which is detected by the status mutex initiator 8. If, however, at step 108 the locked flag 40 is raised before the control acknowledgement flag 38 has been, this indicates a desynchronisation 101. As outlined above, the asynchronous bridge 2 waits at step 103 until the desynchronisation 101 has been detected by both the slave module 4 and the master module 6 before returning to step 102 and checking whether the status mutex is locked.

(17) At step 112, the status mutex initiator 8 raises a mutex locked flag 40 and the mutex formed by the status mutex initiator 8 and the status mutex terminator 22 is locked. This request-and-acknowledgement procedure essentially forms a first two-phase handshake.

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

(19) Providing the mutex is locked, the AHB receiver 10 may transfer data received via the first bus 11 to the master module 6 across the asynchronous interface 7. In order to signal that data is to be transferred from the slave module 4 to the master module 6, the data mutex initiator 12 of the transaction channel (i.e. the data mutex initiator 12 of the slave module 4) toggles the value of a data request flag 42 at step 114. It will be appreciated that by toggling the value of the data request flag 42, this 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 transfers the data 43 across the asynchronous interface 7 through the multi-flip-flop synchroniser 18 and raises a valid flag 45.

(20) The data mutex terminator 26 of the transaction 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 transferred across 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-flip-flop synchroniser 32. The data mutex terminator 26 then toggles the value of a data acknowledgement flag 44 so as to match the value of the data request flag 42, acknowledging the safe receipt of the data 43 at step 118.

(21) It is determined at step 120 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 procedure returns to step 102 and the process is repeated as outlined above. Otherwise, the procedure ends at step 122.

(22) While not shown in FIG. 2, the AHB transmitter 24 within the master module 6 may similarly transfer data to the AHB receiver 10 across the asynchronous interface 7 using the return channel, i.e. using the data mutex initiator 28 of the master module 6 and the data mutex terminator 14 of the slave module 4. In order to signal that data is to be transferred from the master module 6 to the slave module 4, the data mutex initiator 28 of the return channel toggles the value of a data request flag 46. The AHB transmitter 24 then transfers the data 47 across the asynchronous interface 7 through the multi-flip-flop synchroniser 34 and raises a valid flag 49.

(23) 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 transferred across 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-flip-flop synchroniser 20. The data mutex terminator 14 then toggles the value of a data acknowledgement flag 48 so as to match the value of the data request flag 46, acknowledging the safe receipt of the data 47.

(24) FIG. 3 is a timing diagram showing the status mutex locking operation used in the asynchronous bridge of FIG. 1. Initially, at time to, the slave module 4 is held in reset by its asynchronous reset signal arst_slave being held at logic high. At time t.sub.1, the asynchronous reset signal arst_slave of the slave module 4 is set to logic low, allowing the slave module 4 out of reset. Subsequently, at time t.sub.2, the slave module 4 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 4, including the multi-flip-flop synchronisers 18, 20 that are used for transferring data from the first bus 11.

(25) At time t.sub.3, the status mutex initiator 8 raises a control request flag 36 as outlined previously above. In this case, no desynchronisation takes place and the status mutex terminator 22 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.sub.4. The master module 6 subsequently determines that no desynchronisation has taken place and so can set an internal signal hasLock_master to logic high at t.sub.5, indicating that the master module 6 considers the status mutex to be locked (pending the slave module 4 doing the same).

(26) The status mutex terminator 22 subsequently raises the control acknowledgement flag 38 at t.sub.6, which is detected by the status mutex initiator 8. The status mutex initiator 8 sets an internal signal hasLock_slave to logic high at t.sub.7, indicating that the slave module 4 considers the status mutex to be locked. The status mutex initiator 8 then sets the locked flag 40 to logic high at t.sub.8, indicating that the status mutex is locked.

(27) FIG. 4 is a timing diagram showing the desynchronisation operation of the asynchronous bridge of FIG. 1 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 8 will keep the locked flag 40 low and pull the control request flag 36 high, but only if the control acknowledgement flag 38 is low, as outlined previously.

(28) After an initial idle period 50, at time t.sub.9, the slave module 4 is reset by pulsing its asynchronous reset signal arst_slave to logic high. The reset of the slave module 50 also pulls the control request flag 36 and the locked flag 40 to logic low. Once the asynchronous reset signal arst_slave of the slave module 4 returns to logic low, the slave module 4 is allowed out of reset and the slave module enters a ‘bootstrapping’ period 52, during which time the slave module 4 attempts to start locking the status mutex as outlined above with reference to FIG. 3, setting the internal signal getLock_slave high and initiating the clock signal ck_slave as outlined above.

(29) However, at time t.sub.10, the control acknowledgement flag 38 is already high when attempting to lock the status mutex, this indicates that the master module 6 has not yet detected the desynchronisation. The slave module 4 then enters a wait period 54 until the master module 6 detects that the desynchronisation has occurred (i.e. the master module 6 determines that the slave module 4 has been reset). The master module 6 detects the loss of the lock of the status mutex at time t.sub.11, 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.

(30) Once this has been detected, the status mutex enters a locking period 56 at time t.sub.12 in which the status mutex initiator 8 and terminator 22 undergo the locking procedure outlined above such that the status mutex is locked. The status mutex then enters a locked state 58 at time t.sub.13 thereafter until the lock is lost at a later time (not shown).

(31) FIG. 5 is a timing diagram showing the operation of the asynchronous bridge of FIG. 1 when the slave module 4 breaks the status mutex lock. At time t.sub.14, the slave module 4 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 8, i.e. the control request flag 36 and the locked flag 40 are pulled to logic low. The master module 6 detects the loss of the lock at t.sub.15 and sets its internal signal hasLock_master to logic low and pulses lostLock_master to logic high. The status mutex terminator 22 then sets the control acknowledgement flag 38 to logic low at t.sub.16.

(32) Similarly, FIG. 6 is a timing diagram showing the operation of the asynchronous bridge of FIG. 1 when the master module 6 breaks the status mutex lock.

(33) At time t.sub.17, the master module 6 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 22, i.e. the control acknowledgement flag 38 is pulled to logic low. The slave module 4 detects the loss of the lock at t.sub.18 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 8 then sets the control request flag 36 and the locked flag 40 to logic low at t.sub.19.

(34) FIG. 7 is a timing diagram showing the operation of the data mutex used in the asynchronous bridge of FIG. 1. At time t.sub.20, the master module 6 is released from reset by setting its asynchronous reset signal arst_master to logic low. At time t.sub.21, the slave module 4 is also released from reset by setting its asynchronous reset signal arst_slave to logic low, and the data mutex initiator 12 pulses a signal newTrans(in) to logic high, which indicates to the FSM 16 of the slave module 4 that a data transaction event is to occur. The data mutex initiator also begins transferring the data 43 at this time t.sub.21.

(35) Once the data 43 has been set up and is stable, the data mutex initiator 12 toggles the value of the data request flag 42 at t.sub.22 and the AHB receiver 10 then transfers the data 43 across the asynchronous interface 7 through the multi-flip-flop synchroniser 18. For correct operation, the data 43 must remain stable until it is received by the master module 6.

(36) After the data mutex terminator 26 has synchronised the toggling of the data request flag 42, the data mutex terminator 26 pulses a signal newTrans(out) to logic high at t.sub.23, which indicates to the FSM 30 of the master module 6 that a transaction is occurring. After sampling the data 43, the FSM 30 of the master module 6 sets a further signal acceptTrans(in) to logic high at t.sub.24, which indicates that the transaction has been successfully accepted by the master module 6. The master module 6 then toggles the data acknowledgement flag 44 to match the value of the data request flag 42 at t.sub.25.

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

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

(39) Thus it will be appreciated 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 same in which a four-phase handshake is used for an initial transaction in which a mutex is used to monitor the synchronisation status of the bridge, but that two-phase transactions are used for further transactions so long as the mutex remains locked. An asynchronous bridge in accordance with embodiments of the present invention may therefore be more robust against desynchronisation events than a conventional two-phase handshake while carrying out transactions faster than a conventional four-phase handshake. It will be appreciated by those skilled in the art that the embodiments described above are merely exemplary and are not limiting on the scope of the invention.