System bus transaction queue reallocation
View Patent ↗A bus architecture is disclosed that provides for transaction queue reallocation on the modules communicating using the bus. A module can implement a transaction request queue by virtue of digital electronic circuitry, e.g., hardware or software or a combination of both. Some bus clogging issues that affect conventional systems can be circumvented by combining an out of order system bus protocol that uses a transaction request replay mechanism. Modules can evict less urgent transactions from transaction request queues to make room to insert more urgent transactions. Master modules can dynamically update a quality of service (QoS) value for a transaction while the transaction is still pending.
1. A system comprising:
a system bus; and
a plurality of modules coupled to the system bus and configured to communicate with each other using the system bus, including:
a master module implementing a master transaction request queue; and
a slave module implementing a slave transaction request queue, wherein the slave module is configured to perform slave module operations comprising:
receiving a first transaction request from the master module;
determining that the slave transaction request queue is full;
in response to determining that the slave transaction request queue is full, determining, based on at least a first pending transaction in the slave transaction request queue, not to evict the first pending transaction from the slave transaction request queue and not to insert the first transaction request into the slave transaction request queue;
in response to determining not to evict the first pending transaction, postponing the first transaction request by storing a first record for the first transaction request for later replay of the first transaction request;
receiving a second transaction request from the master module; and
in response to determining that the slave transaction request queue is full, determining to evict a second pending transaction from the slave transaction request queue and to insert the second transaction request into the slave transaction request queue.
2. The system of claim 1 , wherein determining not to evict the first pending transaction comprises determining that a quality of service value for the first pending transaction is greater than a quality of service value for the first transaction request.
3. The system of claim 1 , the slave module operations further comprising:
in response to evicting the second pending transaction, postponing the second pending transaction by storing a second record for the second pending transaction for later replay of the second pending transaction.
4. The system of claim 1 , wherein determining to evict the second pending transaction comprises determining that a quality of service value for the second transaction request is greater than a quality of service value for the second pending transaction.
5. The system of claim 1 , wherein the master module is configured to perform master module operations comprising:
sending the second transaction request over the system bus to the slave module with a first quality of service value, thereby causing the slave module to store the second transaction request in the slave transaction queue with the first quality of service value; and
sending a second quality of service value for the second transaction request, thereby causing the slave module to update the first quality of service value in the slave transaction queue with the second quality of service value.
6. The system of claim 1 , wherein the master module is configured to initiate one or more replays of the first transaction request until the first transaction request is completed, each replay of the first transaction request beginning from a data transfer beat where the first transaction request was left off, and wherein the master module is configured to update a quality of service value for the first transaction request on at least one of the one or more replays of the first transaction request.
7. The system of claim 1 , wherein the slave module operations further comprise:
calling back, for each record of a postponed transaction request stored by the slave module, a replay of the postponed transaction request, thereby causing each respective master module to replay each postponed transaction request;
performing arbitration between the replayed transaction requests to determine which of the replayed transaction request to store in the slave transaction request queue.
8. The system of claim 1 , where the plurality of modules are configured to communicate on the system bus using a non-blocking transaction protocol.
9. The system of claim 1 , wherein the system bus comprises a plurality of master bus layers and a plurality of slave bus layers, and wherein the system bus is configured to dynamically route signals of the master bus layers to the slave bus layers, and wherein the system bus includes:
a plurality of decoders, each decoder of the plurality of decoders coupled to one of the plurality of master bus layers, and configured for decoding address signals received from the coupled master bus layer;
a plurality of arbiters, each arbiter of the plurality of arbiters coupled to each one of the plurality of decoders and configured to output a select signal based on results of an arbitration of transfer requests and quality of service signals generated by two or more master bus devices; and
a plurality of switches, each switch of the plurality of switches coupled to one arbiter of the plurality of arbiters and each one of the plurality of master bus layers, each one of the plurality of switches configured by one of the select signals to couple one of the plurality of master bus layers to one of the plurality of slave bus layers.
10. The system of claim 1 , wherein the slave module is configured to reserve one or more slots in the slave transaction request queue for write transaction requests.
11. A method performed by a slave module communicating on a system bus, the method comprising:
receiving a first transaction request from a master module;
determining that a slave transaction request queue is full;
in response to determining that the slave transaction request queue is full, determining, based on at least a first pending transaction in the slave transaction request queue, not to evict the first pending transaction from the slave transaction request queue and not to insert the first transaction request into the slave transaction request queue;
in response to determining not to evict the first pending transaction, postponing the first transaction request by storing a first record for the first transaction request for later replay of the first transaction request;
receiving a second transaction request from the master module; and
in response to determining that the slave transaction request queue is full, determining to evict a second pending transaction from the slave transaction request queue and to insert the second transaction request into the slave transaction request queue.
12. The method of claim 11 , wherein determining not to evict the first pending transaction comprises determining that a quality of service value for the first pending transaction is greater than a quality of service value for the first transaction request.
13. The method of claim 11 , further comprising:
in response to evicting the second pending transaction, postponing the second pending transaction by storing a second record for the second pending transaction for later replay of the second pending transaction.
14. The method of claim 11 , wherein determining to evict the second pending transaction comprises determining that a quality of service value for the second transaction request is greater than a quality of service value for the second pending transaction.
15. The method of claim 11 , further comprising:
calling back, for each record of a postponed transaction request stored by the slave module, a replay of the postponed transaction request, thereby causing each respective master module to replay each postponed transaction request; and
performing arbitration between the replayed transaction requests to determine which of the replayed transaction request to store in the slave transaction request queue.
16. The method of claim 11 , further comprising communicating on the system bus using a non-blocking transaction protocol.
17. The method of claim 11 , further comprising reserving one or more slots in the slave transaction request queue for write transaction requests.
18. A method performed by a master module communicating on a system bus, the method comprising:
sending a first transaction request over the system bus to a slave module with a first quality of service value, thereby causing the slave module to evict a first pending transaction from a slave transaction request queue, to insert the first transaction request into the slave transaction request queue, and to store the first transaction request in the slave transaction queue with the first quality of service value, the first pending transaction having a quality of service value lower than the first quality of service value; and
sending a second quality of service value for the first transaction request to the slave module, thereby causing the slave module to update the first quality of service value in the slave transaction queue with the second quality of service value.
19. The method of claim 18 , further comprising:
sending a second transaction request over the system bus to the slave module, thereby causing the slave module to postpone the second transaction request by storing a record for the second transaction request for later replay of the second transaction request, the second transaction request having a quality of service value lower than a second pending transaction in the slave transaction request queue; and
initiating one or more replays of the second transaction request until the second transaction request is completed.
20. The method of claim 19 , wherein each replay of the second transaction request begins from a data transfer beat where the second transaction request was left off.