DATA BUS COMMUNICATIONS

Abstract

A method of mediating a read transaction from a transaction source domain having a first bus width to a transaction target domain having a second bus width less than the first bus width. The method includes receiving first and second read transactions associated with a first and second transaction ID, separating each read transaction into a plurality of sub-transactions, which have the second bus width. The method further includes sending a sub-transaction of each plurality of sub-transactions to the transaction target domain and receiving first data associated with the first transaction ID and second data associated with the second transaction ID, storing the first data in a first storage element assigned to a first list, storing the second data in a second storage element assigned to a second list; and reading out data to the transaction source domain from the first list and the second list independently of each other.

Claims

1. An electronic device comprising a module configured to transfer data bus transactions from a transaction source domain having a first bus width to a transaction target domain having a second bus width less than the first bus width, the module being configured to carry out the steps of: receiving a first read transaction from the transaction source domain, associated with a first transaction ID and indicating a first address of the transaction target domain; separating the first read transaction into a first plurality of sub-transactions, wherein the first plurality of sub-transactions have the second bus width; sending the first plurality of sub-transactions to the transaction target domain; receiving a second read transaction from the transaction source domain, associated with a second transaction ID and indicating a second address of the transaction target domain; separating the second read transaction into a second plurality of sub-transactions, wherein the second plurality of sub-transactions have the second bus width; and sending the second plurality of sub-transactions to the transaction target domain; the module further comprising: a plurality of storage elements, comprising at least one data register, for storing data received from the transaction target domain; the module further configured to carry out the steps of: receiving first data associated with the first transaction ID, in response to sending a sub-transaction of the first plurality of sub-transactions to the transaction target domain; storing the first data in the data register of a first storage element and assigning the first storage element to a first list; and receiving second data associated with the second transaction ID, in response to sending a sub-transaction of the second plurality of sub-transactions to the transaction target domain; storing the second data in the data register of a second storage element, and assigning the second storage element to a second list; such that data can be read out to the transaction source domain from the first list and the second list independently of each other.

2. The electronic device as claimed in claim 1, wherein the first read transaction has a first transaction burst length and wherein the module is configured to carry out the step of: separating the first read transaction into the first plurality of sub-transactions, wherein the first plurality of sub-transactions each have a respective second transaction burst length less than the first transaction burst length.

3. The electronic device as claimed in claim 1, wherein the module is further configured to carry out the steps of: receiving further data associated with the first transaction ID, in response to sending a further sub-transaction of the first plurality of sub-transactions to the transaction target domain; checking whether the data register of the first storage element is completed; and if the data register of the first storage element is not completed, adding the further data to the data stored in the data register of the first storage element; and if the first storage element is completed, storing the further data in the data register of a third storage element and assigning the third storage element to the first list.

4. The electronic device as claimed in claim 1, wherein the module is further configured to carry out the steps of: checking whether each of the plurality of storage elements is currently storing data; and if all of the storage elements are currently storing data, then not sending a sub-transaction to the target domain until at least one storage element is no longer storing data.

5. The electronic device as claimed in claim 1, wherein the module is further configured to carry out the steps of: checking, upon receipt of a read transaction from the source domain, the total amount of storage space available across the plurality of storage elements; and if the total amount of storage space available is below a minimum threshold parameter, then not sending a sub-transaction to the target domain until data has been forwarded from the module to the target domain.

6. The electronic device as claimed in claim 1, wherein the module is further configured to carry out the steps of: checking, upon receipt of a read transaction from the source domain, the total amount of storage space available across the plurality of storage elements; and if the total amount of storage space available is below the maximum transaction burst length limit of the target domain, then limiting the size of the next sub-transaction to the total amount of storage space available.

7. The electronic device as claimed in claim 1, wherein the module defines a total number of lists to which the plurality of storage elements can be assigned, and wherein the module is further configured to carry out the steps of: checking, upon receipt of a further read transaction from the source domain, whether a list already corresponds to the transaction ID associated with the further read transaction; and if no list corresponds to the transaction ID, checking whether a number of lists in use is equal to the total number of lists; and if the total number of lists in use is equal to the total number of lists, then not sending sub-transactions, associated with the further read transaction, to the target domain until a list becomes available for use.

8. The electronic device as claimed in claim 1, wherein each storage element further comprises a linking register, for referencing another of the storage elements as being a subsequent storage element assigned to the same list.

9. The electronic device as claimed in claim 1, wherein the module additionally comprises an availability list, indicating a sub-set of the plurality of storage elements which are available for data storage.

10. The electronic device as claimed in claim 1, wherein the module is further configured to carry out the step of: forwarding the data from the data register of the storage element specified first in the first list and/or the second list to the source domain, once a sending condition is met, wherein the sending condition requires that the data register of the storage element is completed.

11. The electronic device as claimed in claim 1, wherein the module is further configured to carry out the steps of: when a storage element in the first list and a storage element in the second list are both available to send to the source domain, checking whether data associated with a transaction ID of the first list or the second list has already been sent to the source domain; and if data associated with the transaction ID of the first list has already been sent to the source domain, forwarding the storage element which is first in the first list; and if no data associated with the transaction ID of the first list or the transaction ID of the second list has been forwarded to the storage element, checking whether the first list or the second list contains a lower number of storage elements, and forwarding data from a data register of a storage element to the source domain from the list containing the lower number of storage elements.

12. A method of mediating a read transaction from a transaction source domain having a first bus width to a transaction target domain having a second bus width less than the first bus width, the method comprising: receiving a first read transaction from the transaction source domain, associated with a first transaction ID and indicating a first address of the transaction target domain; separating the first read transaction into a first plurality of sub-transactions, wherein the first plurality of sub-transactions have the second bus width; sending the first plurality of sub-transactions to the transaction target domain; receiving first data associated with the first transaction ID, in response to sending a sub-transaction of the first plurality of sub-transactions to the transaction target domain; storing the first data in the data register of a first storage element and assigning the first storage element to a first list; receiving a second read transaction from the transaction source domain, associated with a second transaction ID and indicating a second address of the transaction target domain; separating the second read transaction into a second plurality of sub-transactions, wherein the second plurality of sub-transactions have the second bus width; sending the second plurality of sub-transactions to the transaction target domain; receiving second data associated with the second transaction ID, in response to sending a sub-transaction of the second plurality of sub-transactions to the transaction target domain; storing the second data in a data register of a second storage element, and assigning the second storage element to a second list; and reading out data to the transaction source domain from the first list and the second list independently of each other.

13. The method as claimed in claim 12, wherein the first read transaction has a first transaction burst length and the method comprises separating the first read transaction into the first plurality of sub-transactions, wherein the first plurality of sub-transactions each have a respective second transaction burst length less than the first transaction burst length.

14. The method as claimed in claim 12, wherein the method further comprises: receiving further data associated with the first transaction ID, in response to sending a further sub-transaction of the first plurality of sub-transactions to the transaction target domain; checking whether the data register of the first storage element is completed; and if the data register of the first storage element is not completed, adding the further data to the data stored in the data register of the first storage element; and if the first storage element is completed, storing the further data in the data register of a third storage element and assigning the third storage element to the first list.

15. The method as claimed in claim 12, wherein the method further comprises checking whether each of the plurality of storage elements is currently storing data; and if all of the storage elements are currently storing data, then not sending a sub-transaction to the target domain until at least one storage element is no longer storing data.

16. The method as claimed in claim 12, wherein the method further comprises checking, upon receipt of a read transaction from the source domain, the total amount of storage space available across the plurality of storage elements; and if the total amount of storage space available is below a minimum threshold parameter, then not sending a sub-transaction to the target domain until data has been forwarded from the module to the target domain

17. The method as claimed in claim 12, wherein the method further comprises checking, upon receipt of a read transaction from the source domain, the total amount of storage space available across the plurality of storage elements; and if the total amount of storage space available is below the maximum transaction burst length limit of the target domain, then limiting the size of the next sub-transaction to the total amount of storage space available

18. The method as claimed in claim 12, wherein the module defines a total number of lists to which the plurality of storage elements can be assigned, and the method further comprises checking, upon receipt of a further read transaction from the source domain, whether a list already corresponds to the transaction ID associated with the further read transaction; and if no list corresponds to the transaction ID, checking whether a number of lists in use is equal to the total number of lists; and if the total number of lists in use is equal to the total number of lists, then not sending sub-transactions, associated with the further read transaction, to the target domain until a list becomes available for use.

19. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to carry out a method of mediating a read transaction from a transaction source domain having a first bus width to a transaction target domain having a second bus width less than the first bus width, the method comprising: receiving a first read transaction from the transaction source domain, associated with a first transaction ID and indicating a first address of the transaction target domain; separating the first read transaction into a first plurality of sub-transactions, wherein the first plurality of sub-transactions have the second bus width; sending the first plurality of sub-transactions to the transaction target domain; receiving first data associated with the first transaction ID, in response to sending a sub-transaction of the first plurality of sub-transactions to the transaction target domain; storing the first data in the data register of a first storage element and assigning the first storage element to a first list; receiving a second read transaction from the transaction source domain, associated with a second transaction ID and indicating a second address of the transaction target domain; separating the second read transaction into a second plurality of sub-transactions, wherein the second plurality of sub-transactions have the second bus width; sending the second plurality of sub-transactions to the transaction target domain; receiving second data associated with the second transaction ID, in response to sending a sub-transaction of the second plurality of sub-transactions to the transaction target domain; storing the second data in a data register of a second storage element, and assigning the second storage element to a second list; and reading out data to the transaction source domain from the first list and the second list independently of each other.

20. A computer software product comprising instructions that, when executed by a processor, cause the processor to carry out a method of mediating a read transaction from a transaction source domain having a first bus width to a transaction target domain having a second bus width less than the first bus width, the method comprising: receiving a first read transaction from the transaction source domain, associated with a first transaction ID and indicating a first address of the transaction target domain; separating the first read transaction into a first plurality of sub-transactions, wherein the first plurality of sub-transactions have the second bus width; sending the first plurality of sub-transactions to the transaction target domain; receiving first data associated with the first transaction ID, in response to sending a sub-transaction of the first plurality of sub-transactions to the transaction target domain; storing the first data in the data register of a first storage element and assigning the first storage element to a first list; receiving a second read transaction from the transaction source domain, associated with a second transaction ID and indicating a second address of the transaction target domain; separating the second read transaction into a second plurality of sub-transactions, wherein the second plurality of sub-transactions have the second bus width; sending the second plurality of sub-transactions to the transaction target domain; receiving second data associated with the second transaction ID, in response to sending a sub-transaction of the second plurality of sub-transactions to the transaction target domain; storing the second data in a data register of a second storage element, and assigning the second storage element to a second list; and reading out data to the transaction source domain from the first list and the second list independently of each other.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0095] An embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0096] FIG. 1 is a schematic diagram showing a module according to an embodiment of the present invention;

[0097] FIG. 2 is a schematic diagram showing the registers of the sub-module of the module of FIG. 1, in a case where no data is stored in the storage elements;

[0098] FIG. 3 is a schematic diagram showing an alternative representation of the registers of FIG. 2;

[0099] FIG. 4 is a schematic diagram showing the registers of the sub-module of FIG. 2, where data is stored in a first element, which has been assigned to a first list;

[0100] FIG. 5 is a schematic diagram showing the registers of the sub-module of FIG. 4, where further data is stored in a second element, which has also been assigned to the first list;

[0101] FIG. 6 is a schematic diagram showing the registers of the sub-module of FIG. 5, where further data is stored in a third element, which has been assigned to a second list;

[0102] FIG. 7 is a schematic diagram showing the registers of the sub-module of FIG. 6, where further data is stored in a fourth element, which has also been assigned to the first list;

[0103] FIG. 8 is a schematic diagram showing the registers of the sub-module of FIG. 7, where data from the first element of the first list has been forwarded to the master;

[0104] FIG. 9 is a schematic diagram showing the registers of the sub-module of FIG. 8, where data from the first element of the second list has been forwarded to the master; and

[0105] FIG. 10 is a flow diagram representing a method according to an embodiment of the present invention.

DETAILED DESCRIPTION

[0106] FIG. 1 is a block diagram illustrating an electronic device 1 comprising a module 2 in accordance with an embodiment of the present invention. The module 2 is arranged to ‘down-break’ read transactions on an AXI data bus which originate from a first transaction ‘source’ domain 4, i.e. a ‘master side’, to make them suitable for supply to a second transaction ‘target’ domain 6, i.e. a ‘slave side’. The bus width of the source domain 4 is greater than the bus width of the target domain 6.

[0107] The module 2 receives read transactions from a device (e.g. a master device) in the source domain 4, which contain a request on the read address (AR) channel. Converter logic 8 of the module 2 down-breaks the read transactions by reducing their width from the wider bus width of the source domain 4 to the narrower bus width of the target domain 6 and splitting each transaction into an appropriate number of smaller transactions for supply to the target domain 6. The read data on the read (R) channel is then re-combined by a portion of the module 2, referred to as the “Read FIFO” (First-In-First-Out) 10, the function of which is described in greater detail below.

[0108] The converter logic 8 determines from the burst length of transactions received via the source domain 4 side—together with prior knowledge of the respective bus widths of each domain 4, 6—how many transactions at the reduced width and burst length will be needed. The reduction in width and burst length may then be carried out simultaneously by the converter logic 8.

[0109] In addition to reducing the width and burst length of read transactions, before forwarding them to the target domain, the module 2 (optionally the converter logic 8) can allow different read transactions to bypass one another. Specifically, where the module 2 receives a first read transaction which needs to be broken into a plurality of sub-transactions, and then receives a second read transaction, which is shorter (i.e. has a lower burst length) than the first read transaction, it may allow the second transaction to bypass the first under certain circumstances. These specific circumstances are where the second transaction is short enough that it is not broken down by the converter logic 8, it is shorter than a bypass threshold parameter, and it is associated with a different transaction ID than the first read transaction.

[0110] The Read FIFO 10 re-combines the read data to make use of the width and burst length allowed by the source domain 4. The functioning of the Read FIFO 10 is described in greater detail with reference to FIGS. 2-9, which are schematic drawings representing various stages in the operation of the Read FIFO 10.

[0111] As seen in FIG. 2, the Read FIFO 10 comprises a plurality of storage elements 20a-20h, each including a respective data register 22a-h, and respective linking registers 24a-h. In the illustrated example, there are eight such storage elements 20a-20h. Although eight storage elements are illustrated for clarity, in practice more or fewer could be employed.

[0112] The Read FIFO 10 further includes three lists, a free list 26, an “A” list 28, and a “B” list 30, where “A” and “B” are just arbitrary labels which are selected to refer to these lists. As described below, each storage element 20a-20h can belong to only one of the lists at any given time. The free list 26 is defined by a Free Head register 27a, specifying the first available storage element, and a Free Tail register 27b, specifying the last available storage element, i.e. the array indices of these elements. The “A” list, is defined by an A Head register 29a, specifying the first storage element in the A list (i.e. the array index of the storage element at the start of the list), and a B Tail register 29b, specifying the last storage element in the A list (i.e. the array index of the storage element at the end of the list). The “B” list is defined by a B Head register 31a, specifying the first storage element in the B list 28 and a B Tail register 31b, specifying the last storage element in the B list. The Read FIFO 10 further includes an A Use register 32, and a B Use register, 34, indicating respectively whether the first and second lists are in use, and an A ID register 36 and a B ID register 38, indicating respectively the transaction IDs associated with the data stored in the A list and the B list.

[0113] The Read FIFO 10 therefore defines two usable “lists” or “channels”, which can be used to define two virtual First-In-First-Out channels, from which data can be read out independently and which are each dynamically resizable, in the manner described below. Although only two lists are illustrated for clarity, in practice more could be employed.

[0114] In the configuration shown in FIG. 2, no data is stored in any of the storage elements 20a-20h of the Read FIFO 10, and therefore all the storage elements are in the free list, with all the data registers 22a-h empty. The values in the linking registers 24a-24h are set so that the linking register of each storage element points to the storage element with the following index in the array, i.e. element 20a points to element 20b, element 20b points to element 20c and so on. When an element is said to point to another element then the value of the linking register of the first element is set to the index of the second. The free list 26 wraps around at the element 22h with the highest index so that its linking register 24h points back at the element 20a. The Use registers 32, 34 indicate that both the lists A and B are not in use, and their respective Head registers, 29a, 31a and Tail registers 29b, 31b, both point to element 20a.

[0115] FIG. 3 shows an alternative representation of the Read FIFO 10 of FIG. 2. The three lists and their associated registers are all represented in the same manner. The difference here is that the registers of each storage element are not shown, rather each storage element 20a-20h is represented as a circle, and the contents of the linking registers of each of these storage elements is represented as an arrow, linking to the storage element 20a-20h to which the linking register points.

[0116] As stated above, in the configuration shown in FIGS. 2 and 3, no data is stored in any of the storage elements 20a-20h of the Read FIFO 10. Data is only received at the Read FIFO 10 following the issuing of a sub-transaction to the target domain 6 by the module 2, or the issuing of a transaction, where no down-sizing is required.

[0117] The Read FIFO 10 can affect the issuing of these transactions or sub-transactions. Specifically, before issuing a new read transaction to the target domain 6, i.e. a transaction associated with a new transaction ID, the module 2 can check how many read transactions are outstanding, i.e. awaiting the return of data from the slave of the target domain 6. In this example there are two available “channels” A and B, and therefore if there are two transaction IDs for which data is still required from the target domain 6 (i.e. both channels are in use) then the module 2 will not send a further read transaction to the target domain 6 until one of the read transactions is no longer outstanding, i.e. all of the data associated with that transaction ID has been received by the Read FIFO 10 and forwarded to the source domain 4.

[0118] In addition to checking that one of the lists is available to accommodate a new transaction, the module 2 will also check that there are enough storage elements 20a-20h available, i.e. containing no data, to store the data requested by a new transaction, before that transaction is sent. Where there is an insufficient number of available storage elements 20a-20h, the module 2 is prevented from sending new addresses to the target domain 6 until data already stored in the Read FIFO 10 has been forwarded to the source domain 4, freeing up storage elements in the Read FIFO 10.

[0119] Where it is determined that a transaction (or series of sub-transactions) is to be sent to the target domain 6, the properties of said transaction can also depend on properties of the Read FIFO 10. Specifically, as well as being limited by the maximum transaction burst length limit of the target domain, the size of the sub-transaction is also limited by the amount of space available in the FIFO. The module 2 calculates the total amount of data storage, across all the storage elements which are in the free list 26. Where the sub-transaction is associated with a transaction ID for an existing list (i.e. it is not the first sub-transaction for that transaction ID) the module 2 will include any part-full storage elements for that list (which are not completed, i.e. are usable) in that calculation. If the amount of data storage which is available is lower than the maximum transaction burst length limit, then the amount of read data which is requested in a given sub-transaction will be limited to the total amount of data storage available in the FIFO. Furthermore, if this amount is below a minimum threshold parameter, then the module 2 will wait until more space becomes available when data has been forwarded to the source domain 4 before sending another sub-transaction to the target domain 6, i.e. so that more than a minimum amount of data is always being requested in each sub-transaction.

[0120] When checking how much data can be requested for a given sub-transaction, the module 2 must take into account that some data may “use” an entire data register, so that the register in question is completed even where the received data does not fill up all of a register's capacity, for example where the received data is “narrow” or “unaligned”, as described below.

[0121] FIG. 4 shows the state of the Read FIFO 10 after receiving data with a transaction ID 5. The process for receiving this data, and storing it in a storage element, is described herein below. Here the storage element 20a has been used to store data received from the target domain 6, in response to a sub-transaction sent by the module 6.

[0122] Each storage element 20a-20h is a register array entry which holds one beat's worth of data, i.e. an amount of data which can be sent to the source domain 4 in a single data transfer, albeit each single data transfer may require multiple clock cycles. This data can be considered as three separate values (which may each comprise multiple bits), a “Data” value, containing the data content, a “Last” value, indicating whether or not this is the last data associated with a given transaction ID, and a “Status value”.

[0123] The “Status value” can indicate four different conditions: [0124] a) The slave device of the target domain 6 is unable to do the requested operation [0125] b) The address of the sub-transaction is not valid [0126] c) The transaction is okay [0127] d) The exclusive transaction is okay

[0128] Where an “exclusive transaction” (or exclusive access transaction) is a known type of transaction which is available in an AXI bus arrangement, as described in this particular example.

[0129] First the Read FIFO 10 checks, for the received data, whether a list 28, 30 is already in use which is associated with the same transaction ID, i.e. if a virtual FIFO for the ID already exists. If a list already exists which is associated with the same transaction ID, then the Read FIFO 10 checks whether the “Data” value already stored in the data register of the storage element at the tail of this list is completed, i.e. whether due to the data already stored in the data register it is no longer suitable to store further data, i.e. its data storage capability is “completed” at that time.

[0130] A data register may be completed because enough data has been received from the target domain 6 and stored in that data register to fill the capacity of the data register. In certain circumstances, the data register of a storage element may also be considered “completed” even where all of the data storage space in the data register is not occupied. For example, where the received data is “narrow”, meaning that the width of the transaction is narrower than the width of the data in the source domain, i.e. that the size field of the transaction is smaller than log 2 of the byte-width of the source domain data. This results in a transaction from the source domain which has an invalid part (i.e. strobe values 0), which, when broken down, might give one or more sub-transactions which are entirely invalid, and such sub-transactions may be filtered. This may also be the case where the data is “unaligned” i.e. where the address of the transaction is unaligned in a way so that the valid data starts more than the second bus width (of a target domain) into the transaction. Again this may result in some of the invalid bytes on the source domain side being filtered from being forwarded to the target domain 6. In these cases only a part of the data received by the Read FIFO 10 from the target domain will be valid when it is forwarded back to the source domain 4, i.e. the master. In this case the storage element storing such received data is considered completed when the valid data has been received from the target domain 6.

[0131] Once a data register is completed, the contents of the storage element is ready to be forwarded in one beat to the source domain. It typically takes several beats of received data from the target domain to fill up a storage element.

[0132] If the Tail element of the associated list has not been filled up yet (and is not completed for some other reason), then the received data is added into this element. “Adding” the received data to an existing storage element means that the received “Data value” is appended to the “Data value” which is already stored in the data register. It further means that the “Last” value may be changed, if the received data is from the last sub-transaction for that transaction ID, and the “Status” value is recalculated depending on the “Status” value of the newly received data.

[0133] Of the conditions described above, the a) condition is the highest order condition, down to the d) condition which is the lowest order condition. Where new data is added to an existing storage element, the status information for that storage element is recalculated, so that the overall “Status” value for the storage element is the highest order condition associated with any of the data in that storage element i.e. if any of the sub-transactions returns an a) condition, the condition for that storage element over all will be a), and vice versa the condition associated with all data in a storage element must be d) for the status value for the of the storage element to be d).

[0134] If a list 28, 30 is not already associated with the transaction ID of the received data, or if the storage element at the end of the list already associated with the transaction ID is completed, then the received data will be stored in a new storage element, specifically the storage element which is at the head of the free list 26, i.e. the first available storage element, which in the example of FIG. 3 is storage element 20a.

[0135] Adding the data to the storage element 20a takes place by a similar process to that described above. The received “Data value” is copied to the data register of the storage element 20a, and so is the “Status” value—no recalculation is required since this is the first status value received by the storage element 20a. If the received data is from the last sub-transaction associated with that transaction ID then the “Last” field is also set.

[0136] If a list 28, 30 associated with the transaction ID of the received data does not already exist, then a currently unused list 28, 30 is allocated for it—which in the example of FIG. 3 could be either list A 28 or list B 30. In this example List A 28 is used. Thus, the A Use register bit 32 is set to 1 and the A ID register 36 is set to the ID of the received data, in this example Transaction ID=5. These changes are shown in FIG. 4.

[0137] In either case, whether or not a list was already in use for the transaction ID, since storage element 20a has now been used to store data, it is added to the list corresponding to the transaction ID of the data, and therefore correspondingly removed from the free list 26. By this it is meant that the storage element 20a is removed from the head of the free list 26, so that the Free Head register 27a now refers, or “points”, to element 20b, whilst the Tail register 29b of the A list refers to the storage element 20a, which was incidentally the case already in the configuration of FIG. 3.

[0138] FIG. 5 shows the Read FIFO 10 of FIG. 4, in which additional data has now been received having the same transaction ID (ID=5). Storage element 20b has now been used to store the additional read data, using the process described above. It is seen from the arrow that the A Tail register 29b now points to storage element 20b, which is now the last element in the A list 28, whist the Head register 27a of the free list 26 (also referred to as an availability list) points to storage element 20c. The linking register 24a of storage element 20a does not need to be updated to point to storage element 20a, since it already pointed to that storage element as seen in FIG. 3. The free list 26 now holds the elements 20c-20d-20e-20f-20g-20h while the A list 28 holds the elements 20a and 20b. The B list 30 list is still empty.

[0139] FIG. 6 shows the Read FIFO 10 of FIG. 5, where data associated with a new transaction ID, transaction ID=8, has been received, and stored in storage element 20c.

[0140] As a result of this storing, the B Use register 34 has been updated to show that the B list 30 is now in use, and the B ID register 38 has also been updated to contain the transaction ID=8, associated with the data now stored in the B list 30. The B Head register 31a, and B Tail register 31b, both point to the newly added storage element 20c, which has been removed from the free list 26, Head register 27a which now points to storage element 20d, the first available storage element. Thus the free list 26 now holds the elements 20d-20e-20f-20g-20h. The A list 28 holds the storage elements 20a and 20b the B list 30 list now holds the element 20c.

[0141] FIG. 7 shows the Read FIFO 10 of FIG. 6, where additional data associated with the transaction ID=5 (i.e. Channel A) has been received and added to the A list 28. In order to store this additional data a new storage element 20d has been added to the A list. In order to do this the A Tail register 29b has been changed, to point to the storage element 20d, indicating that it is the last element in the A list, and the linking register 24b of the preceding storage element 20b of the A list 28 has been updated to point to the storage element 20d, as indicated by the arrow connecting storage elements 20b and 20d in FIG. 7. Correspondingly, the Free Head register 27a of the free list 26 has been updated to point to the first available storage element 20e, i.e. the first storage element which is not in use storing data. The free list 26 after this holds the elements 20e-20f-20g-20h, the A list 28 holds the elements 20a-20b-20d and the B list 30 holds the element 20c.

[0142] Simultaneously with, and/or interspersed with, receiving data from the target domain 6, the Read FIFO 10 can also send the received data from each storage element to the source domain 4. The result of this process is illustrated in FIG. 8, in which the data stored in element 20a, of List A 28 has now been forwarded to the source domain 4.

[0143] A storage element 20a-20h of the Read FIFO 10 is said to be ready to send when enough data has been received from the target domain 6 so that one beat of data can be forwarded to the source domain 4.

[0144] When sending data from a storage element 20a-20h to the target domain, the contents of the storage element at the head of the particular list associated with the chosen ID (e.g. the storage element indicated by the A Head register 29a or the B Head register 31a) is forwarded to the master in one beat. The storage element from which data has been sent to the source domain 6 is then moved to the free list 26. If the list after this becomes empty, then the Use register 32, 34 and the ID register 36, 38 for the list are set to 0, so that the list 28, 30 is once again indicated as being available for use.

[0145] In this example, the first storage element 20a of the A list 28 is ready to send to the source domain 4. To do so the contents of the data register 22a of the storage element at the head of the A list, as indicated by the A Head register 29a, i.e. storage element 20a, are sent, in a single beat, to the source domain 6, leaving the storage element 20a once again empty. The storage element 20a is therefore moved to the tail of the free list 26, as indicated by the Free Tail register 27b, i.e. the Free Tail register 27b is updated to point to the storage element 20a. The new head of the A list is now element 20b, as pointed to by the A Head register 29a. The free list 26 now holds the elements 20e-20f-20g-20h-20a, the A list 28 holds the elements 20b-20d and the B list 30 holds the element 20c.

[0146] The storage element 20c of the B list 30 may also be forwarded to the source domain 4, the result of which is illustrated in FIG. 9. The Free Tail register 27b is therefore changed again to point to the storage element 20c, which is newly added to the free list 26. The free list 26 after this holds the elements 20e-20f-20g-20h-20a-20c. The A list 28 holds the elements 20b-20d and the B list 30 is empty and no longer in use. The B Head register 31a does not need to be updated to point to the next storage element in the B list 30, since storage element 20c was the last (and also only) storage element in the B list 30, and therefore the B list 30 is no longer in use. The B Head register 31a and the B Tail register 31b can therefore be left unchanged until the B list 30 is used for a new transaction ID. The B Use register 34 and the B ID register 38 are both set to 0 to reflect that the B list 30 is no longer in use.

[0147] When forwarding the contents of the head elements 20a, 20c, to the source domain 4, the module 2 sometimes has to arbitrate i.e. decide, which list to forward a data packet from first. In this particular example, where data from some elements of one of the lists has already been sent to the source domain 4, the module 2 will decide to continue to send data from the data registers of elements in this list. For example, from the configuration of FIG. 8, if the module 2 had to select between sending storage element 20b (of list A) and storage element 20c (of list B), it would send (the data contents of) storage element 20b, since it belongs to list A, and the data from the register of the storage element 20a, which previously belonged to list A, has already been sent to the source domain 4, i.e. data from that transaction ID has already been forwarded to the source domain 4. This arbitration may be done by the Read FIFO 10, or may be done by another part of the module 2.

[0148] If data is stored in the read FIFO 10 which is associated with two different transactions IDs, but data associated with either has not yet been sent to the source domain 4, e.g. as illustrated in FIG. 7, and the module 2 needs to arbitrate which data to send, it will send data from the first element of the shorter list, i.e. the list containing the lower number of storage elements, in this case storage element 20c (since the B list 30 only contains this one storage element, whereas the A list 28 contains three storage elements).

[0149] The steps of the method 100 described above are also seen in the flow diagram of FIG. 10. In a first step 102, a read transaction is received from the transaction source domain, and is separated out into a plurality of sub-transactions. In a next step 104, a first one of this plurality of sub-transactions is sent to the transaction target domain 6.

[0150] Next, at step 106, first data associated with the first transaction ID is received by the Read FIFO 10, in response to sending a sub-transaction of the first plurality of sub-transactions to the transaction target domain. Then, at step 108, this first data is stored in the data register of a first storage element, and the first storage element assigned to the first list, as described above.

[0151] This process is then repeated for a second transaction, associated with a second transaction ID, to store data associated with this second transaction ID in a separate list of the Read FIFO 10, so as to be independently accessible, as described above.

[0152] Specifically, the method further includes at step 110, receiving a second read transaction from the transaction source domain, associated with a second transaction ID, and separating this transaction out into a plurality of sub-transactions. In a next step 112, a first one of this plurality of sub-transactions (i.e. overall a second sub-transaction) is sent to the transaction target domain 6.

[0153] Next, at step 114, second data associated with the second transaction ID is received by the Read FIFO 10, in response to sending a sub-transaction of the second plurality of sub-transactions to the transaction target domain. Then, at step 116, this second data is stored in the data register of a second storage element, and the second storage element assigned to the second list, as described above.

[0154] Although not illustrated, this method may also include any or all of the additional method steps described above with reference to FIGS. 1-9.

[0155] It will be appreciated by those skilled in the art that the invention has been illustrated by describing one or more specific embodiments thereof, but is not limited to these embodiments; many variations and modifications are possible, within the scope of the accompanying claims.