System bus transaction queue reallocation
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 slave module implementing a slave transaction request queue and operable to:
receive a transaction request;
determine that the slave transaction request queue is full;
determine that a quality of service value for the transaction request is greater than a quality of service value for a pending transaction in the slave transaction request queue; and
in response to the slave transaction request queue being full and the quality of service value for the transaction request being greater than the quality of service value for the pending transaction, remove the pending transaction from the slave transaction request queue before the pending transaction is completed and insert the transaction request into the slave transaction request queue.
2. The system of claim 1 , wherein the slave module is operable to:
receive a second transaction request;
in response to determining that the slave transaction request queue is full, determine that a quality of service value for the second transaction request is not greater than a quality of service value for at least a second pending transaction in the slave transaction request queue; and
determine not to remove the second pending transaction from the slave transaction request queue and not to insert the second transaction request into the slave transaction request queue.
3. The system of claim 2 , wherein the slave module is operable to:
in response to determining not to remove the second pending transaction, postpone the second transaction request by storing a record for the second transaction request for later replay of the second transaction request.
4. The system of claim 1 , wherein the slave module is operable to reserve one or more slots in the slave transaction request queue for writing transaction requests.
5. The system of claim 1 , further comprising a master module implementing a master transaction request queue,
wherein the slave module is operable to receive the transaction request from the master module.
6. The system of claim 5 , wherein the slave module is operable to:
call back, for each record of a postponed transaction request stored by the slave module, a replay of the postponed transaction request, thereby causing the master module to replay each postponed transaction request; and
perform arbitration between the replayed transaction requests to determine which of the replayed transaction requests to store in the slave transaction request queue.
7. The system of claim 5 , wherein the master module is operable to:
send a second transaction request over a 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 request queue with the first quality of service value; and
send 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 request queue with the second quality of service value.
8. The system of claim 5 , wherein the master module is operable to:
initiate one or more replays of the transaction request until the transaction request is completed, each replay of the transaction request beginning from a data transfer beat where the transaction request was left off.
9. The system of claim 8 , wherein the master module is operable to update the quality of service value for the transaction request on at least one of the one or more replays of the transaction request.
10. The system of claim 5 , further comprising:
a system bus; and
a plurality of modules including the master module and the slave module,
wherein the plurality of modules is operable to communicate on the system bus using a non-blocking transaction protocol.
11. The system of claim 10 , 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.
12. The system of claim 11 , 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.
13. The system of claim 1 , wherein the slave module is operable to:
in response to evicting the pending transaction, postpone the pending transaction by storing a record for the pending transaction for later replay of the pending transaction.
14. The system of claim 13 , wherein the storing a record for the pending transaction for later replay comprises storing the pending transaction in a second queue for later replay of the transaction, the second queue being different from the slave transaction request queue and configured to store respective records for postponed pending transactions.
15. A method performed by a slave module, comprising:
receiving a transaction request;
determining that a slave transaction request queue implemented by the slave module is full;
determining that a quality of service value for the transaction request is greater than a quality of service value for a pending transaction in the slave transaction request queue; and
in response to the slave transaction request queue being full and the quality of service value for the transaction request being greater than the quality of service value for the pending transaction, evicting the pending transaction from the slave transaction request queue and inserting the transaction request into the slave transaction request queue, wherein evicting the pending transaction comprises removing the pending transaction from the slave transaction request queue before a pending transaction is completed.
16. The method of claim 15 , further comprising:
receiving a second transaction request;
in response to determining that the slave transaction request queue is full, determining that a quality of service value for the second transaction request is no greater than a quality of service value for at least a second pending transaction in the slave transaction request queue;
determining not to evict the second pending transaction from the slave transaction request queue and not to insert the second transaction request into the slave transaction request queue; and
postponing the second transaction request by storing a record for the second transaction request for later replay of the second transaction request.
17. The method of claim 15 , further comprising:
calling back, for each record of a postponed transaction request stored by the slave module, a replay of the 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.
18. The method of claim 15 , further comprising:
communicating with a master module on a system bus using a non-blocking transaction protocol, the master module implementing a master transaction request queue,
wherein receiving a transaction request comprises receiving, by the slave module the transaction request from the master module.
19. The method of claim 18 , further comprising:
storing the transaction request in the slave transaction request queue with the quality of service value;
receiving, from the master module, a second quality of service value for the transaction request; and
updating the stored quality of service value for the transaction request in the slave transaction request queue with the second quality of service value.
20. The method of claim 15 , further comprising:
reserving one or more slots in the slave transaction request queue for writing transaction requests.
21. A system comprising:
a slave module implementing a slave transaction request queue and operable to:
receive a transaction request;
determine that the slave transaction request queue is full;
determine that a quality of service value for the transaction request is greater than a quality of service value for a pending transaction in the slave transaction request queue;
evict the pending transaction from the slave transaction request queue and insert the transaction request into the slave transaction request queue;
receive a second transaction request; and
in response to determining that the slave transaction request queue is full, determine that a quality of service value for the second transaction request is no greater than a quality of service value for at least a second pending transaction in the slave transaction request queue;
determine not to evict the second pending transaction from the slave transaction request queue and not to insert the second transaction request into the slave transaction request queue; and
in response to determining not to evict the second pending transaction, postpone the second transaction request by storing a record for the second transaction request for later replay of the second transaction request.