TRANSACTION MAPPING MODULE

Abstract

An electronic device comprises a module configured to transfer data bus transactions from a transaction source domain to a transaction target domain. A first interface receives the transaction from the source domain using a transaction source ID. A second interface sends the transaction to the target domain using a transaction target ID. A look-up table has a plurality of index values and stores the transaction source ID against one of the index values. Mapping logic determines whether the look-up table contains the transaction source ID stored against any of the index values. When the transaction source ID is already stored, the transaction target ID is set to that index value. Conversely, when the transaction source ID is not stored, an available index value is selected, the transaction source ID is stored against that available index value, and the transaction target ID is set to that available index value.

Claims

1. An electronic device comprising a module configured to transfer data bus transactions from a transaction source domain to a transaction target domain, the module comprising: a first interface configured to receive a transaction from the transaction source domain, said transaction having a transaction source ID associated therewith; a second interface configured to send the transaction to the transaction target domain, said transaction having a transaction target ID associated therewith; a look-up table having a plurality of index values, said look-up table being configured to store the transaction source ID against one of said plurality of index values; and a mapping logic configured such that when a transaction is received via the first interface, the mapping logic determines whether the look-up table contains the transaction source ID stored against any of the plurality of index values in said look-up table; said mapping logic being further configured such that: when the transaction source ID is already stored against an index value in the look-up table, the transaction target ID is set to the index value that said transaction source ID is stored against in the look-up table; and when the transaction source ID is not stored against any of the index values in the look-up table, an available index value is selected and the transaction source ID is stored against said available index value in the look-up table, and the transaction target ID is set to said available index value.

2. The electronic device of claim 1, wherein the data bus is an AXI bus or an AXI Lite bus.

3. The electronic device of claim 1, wherein the mapping logic is further configured such that when a transaction is received via the second interface, the mapping logic determines the transaction source ID stored in the look-up table against the index value equal to the transaction target ID, and sends the transaction to the transaction source domain using the determined transaction source ID.

4. The electronic device of claim 1, wherein the data bus transactions transferred by the first module comprise data bus read transactions.

5. The electronic device of claim 1, wherein the data bus transactions transferred by the first module comprise data bus write transactions.

6. The electronic device of claim 5, further comprising a second module configured to transfer data bus read transactions from the transaction source domain to the transaction target domain, the second module comprising: a third interface configured to receive a read transaction from the transaction source domain, said read transaction having a transaction source ID associated therewith; a fourth interface configured to send the read transaction to the transaction target domain, said read transaction having a transaction target ID associated therewith; a second look-up table having a plurality of index values, said second look-up table being configured to store the transaction source ID of the read transaction against one of said plurality of index values; and a second mapping logic configured such that when a read transaction is received via the third interface, the second mapping logic determines whether the second look-up table contains the transaction source ID of the read transaction stored against any of the plurality of index values in said second look-up table; said second mapping logic being further configured such that: when the transaction source ID of the read transaction is already stored against an index value in the second look-up table, the transaction target ID is set to the index value that said transaction source ID of the read transaction is stored against in the second look-up table; and when the transaction source ID of the read transaction is not stored against any of the index values in the second look-up table, an available index value is selected and the transaction source ID of the read transaction is stored against said available index value in the look-up table, and the transaction target ID is set to said available index value.

7. The electronic device of claim 1, wherein the look-up table further comprises a counter value for each index value, wherein: when a new transaction is received having a transaction source ID that is already stored against an index value in the look-up table, the counter value associated with said index value is incremented; and when a transaction is completed, the associated counter value is decremented.

8. A method of transferring data bus transactions from a transaction source domain to a transaction target domain, the method comprising: receiving a transaction from the transaction source domain, said transaction having a transaction source ID associated therewith; storing the transaction source ID against one of a plurality of index values in a look-up table; and when a transaction is received from the transaction source domain, determining whether the look-up table contains the transaction source ID stored against any of the plurality of index values in said look-up table; when the transaction source ID is already stored against an index value in the look-up table, setting a transaction target ID to the index value that said transaction source ID is stored against in the look-up table; and when the transaction source ID is not stored against any of the index values in the look-up table, selecting an available index value, storing the transaction source ID against said available index value in the look-up table, and setting the transaction target ID to said available index value; and sending the transaction to the transaction target domain using the transaction target ID.

9. The method of claim 8, wherein the data bus is an AXI bus or an AXI Lite bus.

10. The method of claim 8, further comprising: when a transaction is received from the transaction target domain, determining the transaction source ID stored in the look-up table against the index value equal to the transaction target ID; and sending the transaction to the transaction source domain using the determined transaction source ID.

11. The method of claim 8, wherein the data bus transactions transferred by the first module comprise data bus read transactions.

12. The method of claim 8, wherein the data bus transactions transferred by the first module comprise data bus write transactions.

13. The method of claim 12, further comprising transferring data bus read transactions from the transaction source domain to the transaction target domain, the method further comprising: receiving a read transaction from the transaction source domain, said read transaction having a transaction source ID associated therewith; storing the transaction source ID of the read transaction against one of a plurality of index values in a second look-up table; and when a read transaction is received from the transaction source domain, determining whether the second look-up table contains the transaction source ID of the read transaction stored against any of the plurality of index values in said second look-up table; when the transaction source ID of the read transaction is already stored against an index value in the second look-up table, setting a transaction target ID to the index value that said transaction source ID of the read transaction is stored against in the second look-up table; and when the transaction source ID of the read transaction is not stored against any of the index values in the second look-up table, selecting an available index value, storing the transaction source ID of the read transaction against said available index value in the second look-up table, and setting the transaction target ID to said available index value; and sending the read transaction to the transaction target domain using the transaction target ID.

14. The method of claim 8, wherein the look-up table further comprises a counter value for each index value, the method further comprising: when a new transaction is received having a transaction source ID that is already stored against an index value in the look-up table, incrementing the counter value associated with said index value; and when a transaction is completed, decrementing the associated counter value.

15. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to carry out the method of claim 8.

Description

BRIEF DESCRIPTION OF DRAWINGS

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

[0063] FIG. 1 is a block diagram illustrating a module in accordance with an embodiment of the present invention;

[0064] FIG. 2 is a diagram illustrating the structure of the look-up table used by the module of FIG. 1;

[0065] FIG. 3 is a schematic diagram illustrating a process of updating the look-up table of FIG. 2; and

[0066] FIG. 4 is a block diagram showing an electronic device having separate modules for read and write transactions.

DETAILED DESCRIPTION

[0067] FIG. 1 is a block diagram illustrating an electronic device 100 comprising a module 102 in accordance with an embodiment of the present invention. The module 102 is arranged to translate transaction IDs on an AXI bus between a first transaction ID domain (referred to interchangeably as ‘domain A’) 104 and a second transaction ID domain (referred to interchangeably as ‘domain B’) 106.

[0068] The module 102 includes a mapping logic 108 and a look-up table (LUT) 110, which are outlined in further detail below. It will be appreciated that while FIG. 1 shows a particular arrangement, this is for illustrative purposes and for ease of reference, and the embodiments of the present invention may have different physical and/or logical configurations. For example, the look-up table 110 need not necessarily be a component within the mapping logic 108. The mapping logic 108 may be carried out by a single processor (or other processing means), or its function may be distributed across a number of different components.

[0069] The module is configured to receive an AXI transaction request T.sub.a from domain A 104, which in this example is the AXI transaction source domain. This transaction request T.sub.a is received via a first interface 112 of the module 102. The transaction request T.sub.a will, in general, have a transaction ID, denoted ‘ID.sub.a’, where ID.sub.a has an associated transaction ID width dependent on the width specified by domain A 104.

[0070] The mapping logic 108 uses the LUT 110 to translate transaction IDs between the two domains, i.e. from a transaction ID.sub.a in domain A 104 to a transaction ID.sub.b in domain B 106, and vice versa. The structure of this LUT 110 can be seen in FIG. 2.

[0071] The LUT 110 has a number of columns: an index, the source domain transaction ID.sub.a, and a counter value, which are outlined in turn below.

[0072] The ‘Index’ column provides an identifier for each row in the LUT 110. In this particular example, the index values range from 0 to 15, i.e. they can be represented as a four-bit binary number ranging from 0b0000 (decimal ‘0’) to 0b1111 (decimal ‘15’). As outlined in further detail below, these correspond to the transaction ID.sub.b supplied with the transaction request to the second transaction domain B 106, which in this example is configured to use a four-bit transaction ID width. The number of index values available limits the concurrency of the system, i.e. how many unique transactions can be handled simultaneously. Those skilled in the art may make a suitable determination as to how much concurrency is required, and size the LUT 110 accordingly.

[0073] The ‘ID.sub.a’ column stores a source transaction domain ID.sub.a against one of these index values. In this case, the source domain A 104 may assign transaction ID values b between 0 and 31, i.e. they can be represented as a five-bit binary number ranging from 0b00000 (decimal ‘0’) to 0b11111 (decimal ‘31’). It will of course be appreciated that different transaction ID widths for each of the domains may be used, and either domain A 104 or domain B 106 may have a wider transaction ID width than the other (or they may be the same, albeit with a reduced benefit from the transaction ID width conversion afforded by the present invention).

[0074] The ‘Counter’ column stores the total number of pending transactions having a given ID.sub.a. A value of ‘0’ in this column indicates that there are no active transactions having that ID.sub.a and thus that row (i.e. that index) may be overwritten, but it hasn't been cleared from memory. It will be appreciated that certain logic may, alternatively, act to remove entries from the LUT 110 when their associated counter value reaches zero.

[0075] It should also be noted that the counter being ‘0’ to indicate a ‘free’ row is a choice, and alternative approaches may be taken. For example, the LUT 110 could instead include a dedicated ‘active’ or ‘in use’ field which can be set and inspected (where this field would be set high when the counter is non-zero in this case) rather than looking at the counter value. Alternatively, the counter value could be left at one when setting active/used to low such that the rest of the row in the LUT 110 is not updated at all and the active field is toggled to mark that index of the LUT 110 as free or not.

[0076] It can be seen in the ‘snapshot’ of FIG. 2 that the first eleven of the index values have been used at some point, where index values 0, 1, 2, 4, 6, 7, 8, and 10 all have active transactions associated with them (i.e. they have non-zero counter values for a given ID.sub.a). Index values 3, 5, and 9 have been used for transactions previously, but now have a counter value of zero and are now available for re-use. Counter values 11, 12, 13, 14, and 15 have not yet been used, indicated by the ‘-’ in the respective cells of the table.

[0077] As illustrated in FIG. 3, when a transaction request T.sub.a is received, the mapping logic 108 checks the LUT 110 to see whether there are already any active transactions having that same source domain transaction ID.sub.a in the LUT 110, i.e. an index value against which that same ID.sub.a is stored, where the counter value is greater than zero. If there is a match, the counter value associated with that index value is incremented (counter++), corresponding to the new number of pending transaction(s) for that ID.sub.a value. The index value associated with the match is then used as the target domain ID.sub.b when the transaction is supplied to domain B 106 as T.sub.b via a second interface 114.

[0078] By way of an example with reference to FIG. 2, a new transaction request T.sub.a with ID.sub.a=19 would find a match in index value 6, and so the counter would be updated from 7 to 8, and the transaction would then be supplied to domain B 106 as T.sub.b having ID.sub.b=6 (i.e. the index value).

[0079] If, on the other hand, a transaction request T.sub.a is received having an ID.sub.a that isn't currently active, i.e. for which there is no match in the LUT 110, the mapping logic 108 selects an available index and stores the ID.sub.a against it, setting the counter value for that index to one (counter=1). That index value is then used as ID.sub.b when the AXI transaction is passed to domain B 106 as T.sub.b.

[0080] Referring again to FIG. 2, a new transaction request T.sub.a is received with ID.sub.a=8, which is not currently stored in the LUT 110. The mapping logic 108 may select an available index value (i.e. one having a counter value of zero ‘0’ or empty ‘-’) and store the ID.sub.a of T.sub.a against it. For example, index value 3 may be used, overwriting the old entry of ID.sub.a=1; or index value 11 could be used for the first time. The counter value associated with the selected index value is incremented, and the index value is then used as ID.sub.b for T.sub.b.

[0081] When a transaction response Tr.sub.b is received from domain B 106, the mapping logic 108 carries out a reverse translation by checking the index value equal to the ID.sub.b associated with the response Tr.sub.b in the LUT 110, and the transaction response is passed to domain A as Tr.sub.a using the ID.sub.a stored against that index value (i.e. the index value equal to ID.sub.b).

[0082] When a transaction is resolved, i.e. when it completes, the LUT 110 is updated to decrement the counter value for the associated index (counter--). For example, if the transaction having ID.sub.a=5 completes before any new transaction request having that same ID.sub.a value is received, the counter value for index value 4 is decremented from ‘1’ to ‘0’, thus rendering index value 4 available for use.

[0083] FIG. 4 is a block diagram showing an electronic device having separate modules for read and write transactions. As can be seen in FIG. 4, the various AXI channels AW, W, B, AR, R are appended with an ‘M’ for the master-side of the channel, and with an ‘S’ for the slave-side of the channel.

[0084] It will be appreciated that the transaction requests T.sub.a, T.sub.b and responses Tr.sub.a, Tr.sub.b outlined above may correspond to read transactions, e.g. where a master device in domain A 104 wishes to read something from the memory of a slave device in domain B 106. In such a scenario, the transaction request T.sub.a, T.sub.b may be for a read operation of a particular memory location using the ‘Read Address’ (AR) channel of the AXI bus; and the response Tr.sub.a, Tr.sub.b may be the associated data from that memory location on the ‘Read’ (R) channel of the AXI bus.

[0085] Alternatively, the transaction requests T.sub.a, T.sub.b and responses Tr.sub.a, Tr.sub.b outlined above may correspond to write transactions, e.g. where a master device in domain A 104 wishes to write something to the memory of a slave device in domain B 106. In such a scenario, the transaction request T.sub.a, T.sub.b may be for a write operation of a particular memory location using the ‘Write Address’ (AW) channel of the AXI bus. Those skilled in the art will appreciate that the actual data to be written is generally supplied separately over the ‘Write Data’ (W) channel of the AXI bus. The response Tr.sub.a, Tr.sub.b may be an acknowledgement of the write operation on the ‘Write Response’ (B) channel of the AXI bus. It will be appreciated that the forward and reverse channels may differ, depending on the particular bus protocol in use, e.g. if using the AXI3 protocol, the W channel also carries the transaction IDs.

[0086] For ease of illustration, the table update logic 116 which handles updates to the LUT 110; the table status logic 118 which checks the entries in the LUT 110; and the transaction hold logic 120 which handles transaction holds, are shown separately to the mapping logic 108. Each of these functions may be carried out by separate logic modules, or one or more of these functions may be carried out within a combined module. For example, all of these functions map be carried out within the mapping logic 108.

[0087] Thus it will be appreciated that embodiments of the present invention provide an improved arrangement in which a ‘mapper’ module translates transaction IDs between different domains, allowing for different transaction ID widths to be used between these domains. This arrangement may avoid the need to ‘grow’ a transaction ID at each interconnect level to keep track of where they come from, instead allocating one of a set of internal references (the index value) to a particular source transaction ID, and using that for all corresponding transactions having that same ID until it is no longer active. This arrangement may allow for complex loops to be handled more easily, and on an ad hoc basis, i.e. without needing to map out all master-slave paths in advance, by trading off against the maximum transaction concurrency of the system.

[0088] While specific embodiments of the present invention have been described in detail, it will be appreciated by those skilled in the art that the embodiments described in detail are not limiting on the scope of the claimed invention.