Crossbar interconnection architecture based on AMBA AXI protocol
By adopting a Crossbar interconnect architecture based on the AMBA AXI protocol, the competition and blocking problems of shared bus interconnect architecture in SoC are solved, enabling multiple master devices to access each other in parallel, thereby improving data transmission efficiency and system performance.
Patent Information
- Application Number
- CN202510701030.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-28
- Publication Date
- 2025-10-31
AI Technical Summary
Traditional SoC shared bus interconnect architecture suffers from intense competition and bus congestion when multiple IP cores communicate, resulting in low data transmission efficiency. While the Crossbar interconnect architecture improves parallelism, it is difficult to arbitrate and has low routing efficiency between master and slave devices.
The Crossbar interconnect architecture, based on the AMBA AXI protocol, is adopted, including a top-level interface, an arbitration system, and a data distribution system. It supports multiple master devices to access slave devices in parallel, implements transmission mechanisms such as Outstanding, Out-of-order, and Interleaving, and improves master-slave routing efficiency through the arbitration system and data distribution system.
It significantly improves the bus bandwidth utilization and system throughput of the system-on-chip, supports low-latency, high-bandwidth data transmission, and meets the needs of high-performance computing.
Smart Images
Figure CN120872879A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of SoC design technology in integrated circuits, and specifically to a Crossbar interconnect architecture based on the AMBA AXI protocol. Background Technology
[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.
[0003] With the rapid development of semiconductor process technology and chip manufacturing technology, the number of transistors per unit area on a silicon wafer has increased rapidly. The industry's requirements for the performance and functionality of integrated circuits have also become increasingly stringent. As a result, multiple chips connected to the processor at the board level have begun to be integrated onto a single chip. Integrating such a system composed of various functional modules onto a single chip is called a System on Chip (SoC). The emergence of SoCs marked the transition from circuit integration to system integration in chip design. Because SoCs integrate a series of functional units such as processor cores, memory modules, communication modules, and serial ports, they possess certain data processing and information transmission capabilities, and are therefore widely used in various computing fields, mobile devices, and embedded systems. However, as user demands continue to increase, the number of functional units integrated onto a single chip is growing, leading to increasing design complexity. Therefore, designers have decoupled the different functional units in the SoC, with each functional module having its circuit design and verification completed by different developers, and then packaged into an IP core (Intellectual Property). IP cores are verified modules with independent and complete functional logic that are only visible to the outside world through interfaces and can be reused. By properly selecting and integrating IP cores, SoCs with specific functions can be designed, which greatly improves the design efficiency of chips. This SoC design and integration method with IP cores as the basic unit has become the mainstream in the industry.
[0004] Communication between IPs in a System-on-a-Chip (SoC) is accomplished via an on-chip bus. The bus's communication protocol and interconnect architecture directly affect the data interaction methods and communication efficiency between modules, thus impacting the overall performance of the SoC. Traditional SoC on-chip bus interconnect architectures employ a shared bus architecture. In this architecture, the bus needs to decode address signals from the master device and arbitrate shared communication resources. Based on the decoding and arbitration results, communication interconnection and resource reuse between master and slave devices are achieved. The shared bus interconnect architecture is widely used in microcontrollers and embedded systems due to its relatively simple structure, low hardware resource overhead, low control logic complexity, and ease of implementation. However, this architecture only allows one master device and one slave device to occupy bus resources at a time. Other devices must wait for the bus to be released before they can communicate with each other. As the number of on-chip IP cores increases, competition for bus communication resources between devices intensifies, easily leading to bus congestion. The inability to promptly meet the communication needs of devices due to bus congestion has become a bottleneck for improving SoC system performance.
[0005] To address the limitations of traditional shared bus interconnect architectures in terms of data transmission efficiency, designers proposed the crossbar interconnect architecture. This architecture no longer treats the bus as a shared communication resource, but instead establishes a transmission path between each pair of master-slave devices that need to communicate. This allows multiple pairs of master-slave devices to communicate in parallel, meaning that more than two IP cores can communicate simultaneously at any given time, supporting multi-path concurrent transmission. This alleviates the severe contention and blocking problems in shared bus interconnect architectures and greatly improves data transmission efficiency and system parallelism. However, the crossbar interconnect architecture still suffers from challenges such as difficult arbitration and low routing efficiency between master-slave devices. Summary of the Invention
[0006] To address the shortcomings of existing technologies, this invention provides a Crossbar interconnect architecture based on the AMBA AXI protocol, which supports multiple master devices accessing different slave devices in parallel. It supports the Outstanding, Out-of-order, and Interleaving transmission mechanisms of the AXI protocol, achieving efficient master-slave routing and effectively improving the utilization of bus bandwidth.
[0007] To achieve the above objectives, the present invention adopts the following technical solution:
[0008] A Crossbar interconnect architecture based on the AMBA AXI protocol includes: a top-level interface, an arbitration system, and a data distribution system;
[0009] The top-level interface is used to connect to all master and slave device ports of the system on chip, and is responsible for connecting the interconnect architecture with the peripheral AXI communication protocol ports of the master and slave devices in the system on chip, and exchanging information with all device channel signals;
[0010] The arbitration system is used to arbitrate communication transaction requests initiated by master and slave devices, including read or write communication requests initiated by multiple master devices to the same slave device, and return read data requests initiated by different slave devices to the same master device, and submits the arbitration results to the data distribution system.
[0011] The data distribution system is used to distribute data sent by the master and slave devices to the corresponding communication objects based on the result of the arbitration system.
[0012] In one implementation, the top-level interface includes a master interface and a slave interface;
[0013] The main interface is connected to all slave device ports of the on-chip system, and is responsible for receiving read data information and write response information returned by the slave devices, and sending address and control information and write data information to the slave devices.
[0014] The slave interface is connected to all master device ports of the on-chip system and is responsible for receiving address and control information and write data information sent by the master device, and returning the corresponding read data information and write response information to the master device.
[0015] In one implementation, the arbitration system includes a decoding module and an arbitrator. The decoding module is responsible for assisting the arbitration system in determining the access object based on the communication requests received from each device. The decoding module includes a write transaction channel decoder, a read address channel decoder, and a read data channel decoder. The arbitrator is responsible for arbitrating all arbitration requests, with an arbitration delay of one clock cycle.
[0016] As a further limitation, the write transaction channel decoder is used to decode the write address channel of the master device. The decoding result is related to the write address signal in the master device's write address channel and the address space allocated to the slave device in the system. The input of the write transaction channel decoder includes the write address signals of all master devices and the start and end addresses of all slave devices.
[0017] The read address channel decoder is used to decode the read address channel of the master device. The decoding result is related to the read address signal in the read address channel of the master device and the address space allocated to the slave device in the system. The input of the read address decoder includes the read address signals of all master devices and the start address and end address of all slave devices.
[0018] The read data channel decoder is used to decode the read data channels of slave devices. The decoding result is related to the RID signal in the read data channel of the slave device and the number assigned to the master device in the system. The input of the read data channel decoder includes the RID signals of all slave devices and the system number of all master devices.
[0019] In one implementation, the data distribution system includes: a write transaction channel occupancy table, a read transaction channel occupancy table, and a multi-channel data selection module. The read transaction channel occupancy table includes a read address channel occupancy table and a read data channel occupancy table. The read transaction channel occupancy table is responsible for recording the read communication status of each master and slave device and controlling the interconnection of related signals of the read address channel and read data channel between the master and slave devices by the multi-channel data selection module.
[0020] As a further limitation, the write transaction channel occupancy table has several entries. Each entry records whether a write communication is in progress between a master device and a slave device. The entries have two states: IDLE and BUSY. The IDLE state indicates that no write transaction communication is in progress between the master and slave devices corresponding to this entry, while the BUSY state indicates that the master and slave devices are in progress.
[0021] When a master device wins the arbitration in a write communication contention with a slave device, it looks up the write channel transaction occupancy table. If the corresponding table entry for the master and slave devices is in the IDLE state, and neither the master nor the slave device has any other write communication tasks, the table entry state changes from IDLE to BUSY. After the write transmission transaction between the master and slave devices is completed, the corresponding table entry state changes from BUSY to IDLE. The end of the write transmission transaction is marked by the completion of the write response channel handshake.
[0022] As a further limitation, the read address channel occupancy table is used to record the communication status of the read address channels of each master and slave device, and to control the interconnection of related signals of the channel between the master and slave devices by the multi-channel data selection module.
[0023] As a further limitation, the read address channel occupancy table has several entries. Each entry records whether a read address communication is in progress between a master device and a slave device. The entries have two states: IDLE and BUSY.
[0024] When the master device wins a competition for control of the write address channel of the slave device, and both the master and slave devices have idle read address channels, the status of the corresponding entry will change from IDLE to BUSY.
[0025] When the read address channel between the master and slave devices completes the handshake, the table entry status changes from BUSY to IDLE.
[0026] As a further limitation, the read data channel occupancy table is used to record the communication status of the read data channels of each master and slave device, and to control the interconnection of related signals of the channel between the master and slave devices by the multi-channel data selection module.
[0027] As a further limitation, the read data channel occupancy table has several entries. Each entry records whether read data communication is in progress between a master device and a slave device. The entries have three states: IDLE, RESERVED, and BUSY. The IDLE state indicates that there is no communication task on the read address channel between the corresponding master and slave devices. The RESERVED state indicates that the master and slave devices have just completed a read data channel handshake. The BUSY state indicates that the master and slave devices are in the process of transmitting read data.
[0028] When the status of a table entry is IDLE, the corresponding slave device has won the arbitration, and there are no other communication tasks on the master and slave device read data channels. In this case, the status will change from IDLE to BUSY.
[0029] When the status of the table entry is BUSY, the status changes from BUSY to IDLE when the last transfer in the master-slave data read channel completes the handshake. If it is not the last transfer that completes the handshake, the status changes to RESERVED.
[0030] When the table entry status is RESERVED, the slave device does not have the ability to continue returning read data, that is, the RVALID signal is low. If other slave devices do not have a need to return read data to the master device, the table entry status remains unchanged. If other slave devices have a need to return read data, the table entry status changes from RESERVED to IDLE. If the slave device has the ability to continue returning read data, that is, the RVALID signal is high, the status changes to BUSY.
[0031] Compared with the prior art, the beneficial effects of the present invention are:
[0032] 1. This invention provides a Crossbar interconnect architecture based on the AMBAAXI protocol. By setting up a top-level interface, arbitration system, and data distribution system, it allows multiple master devices to access slave devices in parallel. For communication requests from different master devices to the same slave device using the same access method, communication arbitration can be completed in one cycle. It can support the implementation of communication mechanisms such as Outstanding, Out-of-order, and Interleave in the AXI protocol. The master-slave routing is efficient, which can effectively improve the bus bandwidth utilization of the on-chip system.
[0033] 2. The top-level interface of this invention connects directly to all master and slave devices, eliminating the contention bottleneck in the traditional shared bus architecture, supporting multiple master devices to access slave devices in parallel, and significantly improving system throughput; through the handshake signals (such as VALID / READY) and channel separation (read / write address, data, and response channels) of the AXI protocol, low-latency, high-bandwidth data transmission is achieved, meeting the needs of high-performance computing.
[0034] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0035] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.
[0036] Figure 1 This is a schematic diagram of the overall architecture of the Crossbar interconnect architecture based on the AMBA AXI protocol provided in an exemplary embodiment of this application;
[0037] Figure 2 This is a schematic diagram of a write transaction channel decoder provided in an exemplary embodiment of this application;
[0038] Figure 3 This is a schematic diagram of a read data channel decoder provided in an exemplary embodiment of this application;
[0039] Figure 4 This is a state transition diagram of the write transaction channel occupancy table entries provided in an exemplary embodiment of this application;
[0040] Figure 5 This is a state transition diagram of the read address channel occupancy table entries provided in an exemplary embodiment of this application;
[0041] Figure 6 This is a state transition diagram of the read data channel occupancy table entries provided in an exemplary embodiment of this application;
[0042] Figure 7 This is a schematic diagram of a multi-channel data selection module provided in an exemplary embodiment of this application. Detailed Implementation
[0043] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0044] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.
[0045] This implementation proposes a Crossbar interconnect architecture based on the AMBA AXI protocol, such as... Figure 1As shown, it consists of three parts: a top-level interface, an arbitration system, and a data distribution system. The top-level interface includes a slave interface and a master interface. The arbitration system includes a decoding module and an arbitrator. The decoding module includes a write transaction channel decoder, a read address channel decoder, and a read data channel decoder. The data distribution system includes a write transaction channel occupancy table, a read transaction channel occupancy table, and a multi-channel data selection module. The read transaction channel occupancy table includes a read address channel occupancy table and a read data channel occupancy table.
[0046] In this implementation, the top-level interface is connected to all master and slave device ports of the on-chip system, and is responsible for connecting the interconnect architecture with the peripheral AXI communication protocol ports of the master and slave devices within the on-chip system, and exchanging information with all device channel signals.
[0047] In this implementation, the slave interface is connected to all master device ports of the on-chip system, and is responsible for receiving address and control information and write data information sent by the master device, and returning the corresponding read data information and write response information to the master device.
[0048] In this implementation, the main interface is connected to all slave device ports of the on-chip system, and is responsible for receiving read data information and write response information returned by the slave devices, and sending address and control information and write data information to the slave devices.
[0049] In this implementation, the arbitration system is responsible for arbitrating communication transaction requests initiated by master and slave devices, including read or write communication requests initiated by multiple master devices to the same slave device, as well as return read data requests initiated by different slave devices to the same master device, and submitting the arbitration results to the data distribution system.
[0050] In this implementation, the decoding module is responsible for assisting the arbitration system in determining the access object based on the communication requests received from each device.
[0051] In this implementation, such as Figure 2 As shown, the write transaction channel decoder is responsible for decoding the write address channel of the master device. The decoding result is not related to whether the master device is communicating or has initiated a communication request. It is only related to the write address signal in the master device's write address channel and the address space allocated to the slave device in the system. The input of the write transaction channel decoder includes the write address signals of all master devices and the start address and end address of all slave devices.
[0052] In this implementation, the slave device address allocation table can be customized according to the address space of each slave device based on the integrated SoC system.
[0053] In this implementation, such as Figure 3As shown, the read address channel decoder is responsible for decoding the read address channel of the master device. The decoding result is not related to whether the master device is communicating or has initiated a communication request. It is only related to the read address signal in the read address channel of the master device and the address space allocated to the slave device in the system. The input of the read address decoder includes the read address signals of all master devices and the start address and end address of all slave devices.
[0054] In this implementation, the read data channel decoder is responsible for decoding the read data channel of the slave device. The decoding result is independent of whether the slave device is communicating or has initiated a communication request. It is only related to the RID signal in the read data channel of the slave device and the number assigned to the master device in the system. The input of the read data channel decoder includes the RID signals of all slave devices and the system number of all master devices.
[0055] In this implementation, the master device system number allocation table can be customized according to the system number of each master device based on the integrated SoC system.
[0056] In this implementation, the arbitrator is responsible for arbitrating all arbitration requests, and the arbitration delay is one clock cycle.
[0057] In this implementation, the data distribution system is responsible for distributing the data sent by the master and slave devices to the corresponding communication objects based on the result of the arbitration system.
[0058] The write transaction channel occupancy table is responsible for recording the write communication status of each master and slave device, and controlling the interconnection of related signals of the write address channel, write data channel, and write response channel between the master and slave devices by the multi-channel data selection module.
[0059] like Figure 4 As shown, the write transaction channel occupancy table has several entries. Each entry records whether write communication is in progress between a master device and a slave device. Each entry has two states: IDLE and BUSY. The IDLE state indicates that no write transaction communication is occurring between the master and slave devices corresponding to that entry, while the BUSY state indicates that the master and slave devices are currently engaged in write transaction communication. When a master device wins arbitration in a write communication contention with a slave device, it checks the write channel transaction occupancy table. If the entry for that master / slave device is in the IDLE state, and neither the master nor the slave device has any other write communication tasks, the entry state transitions from IDLE to BUSY. After the write transmission transaction between the master and slave devices is completed, the corresponding entry state transitions from BUSY to IDLE. The end of the write transmission transaction is marked by the completion of the write response channel handshake.
[0060] In this implementation, the read transaction channel occupancy table is responsible for recording the read communication status of each master and slave device, and controlling the interconnection of related signals of the read address channel and read data channel between the master and slave devices by the multi-channel data selection module.
[0061] The read address channel occupancy table is responsible for recording the communication status of the read address channels of each master and slave device, and controlling the interconnection of related signals of the channel between the master and slave devices by the multi-channel data selection module.
[0062] like Figure 5 As shown, the read address channel occupancy table has several entries. Each entry records whether read address communication is in progress between a master device and a slave device. Each entry has two states: IDLE and BUSY. When a master device wins a write address channel control contest with a slave device, and both master and slave devices' read address channels are idle, the corresponding entry's state changes from IDLE to BUSY. When the master and slave devices complete their read address channel handshake, the entry's state changes from BUSY to IDLE.
[0063] In this implementation, the read transaction channel occupancy table is responsible for recording the read communication status of each master and slave device, and controlling the interconnection of related signals of the read address channel and read data channel between the master and slave devices by the multi-channel data selection module.
[0064] The read data channel occupancy table is responsible for recording the communication status of the read data channels of each master and slave device, and controlling the interconnection of relevant signals of the channel between the master and slave devices by the multi-channel data selection module.
[0065] like Figure 6 As shown, the read data channel occupancy table has several entries. Each entry records whether read data communication is in progress between a master device and a slave device. The entries have three states: IDLE, RESERVED, and BUSY. The IDLE state indicates that there is no communication task on the read address channel between the corresponding master and slave devices. The RESERVED state indicates that the master and slave devices have just completed a read data channel handshake. The BUSY state indicates that the master and slave devices are in the process of transmitting read data. When the state of an entry is IDLE, the corresponding slave device has won the arbitration, and there are no other communication tasks on the master-slave read data channel. The state then transitions from IDLE to BUSY. When the state of an entry is BUSY, the last transfer in the master-slave read data channel completes the handshake. The state then transitions from BUSY to IDLE. If it is not the last transfer that completes the handshake, the state transitions to RESERVED. When the state of an entry is RESERVED, the slave device does not have the ability to continue returning read data (i.e., the RVALID signal is low). If other slave devices do not have a need to return read data to the master device, the state of the entry remains unchanged. If other slave devices have a need to return read data, the state of the entry transitions from RESERVED to IDLE. If the slave device has the ability to continue returning read data (i.e., the RVALID signal is high), the state transitions to BUSY.
[0066] In this implementation, such as Figure 7The multi-channel data selection module shown is responsible for interconnecting the signals of each channel of the master and slave devices based on the results of the three occupancy tables.
[0067] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A Crossbar interconnect architecture based on the AMBA AXI protocol, characterized in that, include: Top-level interface, arbitration system, and data distribution system; The top-level interface is used to connect to all master and slave device ports of the system on chip, and is responsible for connecting the interconnect architecture with the peripheral AXI communication protocol ports of the master and slave devices in the system on chip, and exchanging information with all device channel signals; The arbitration system is used to arbitrate communication transaction requests initiated by master and slave devices, including read or write communication requests initiated by multiple master devices to the same slave device, and return read data requests initiated by different slave devices to the same master device, and submits the arbitration results to the data distribution system. The data distribution system is used to distribute data sent by the master and slave devices to the corresponding communication objects based on the result of the arbitration system.
2. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 1, characterized in that, The top-level interface includes a master interface and a slave interface; The main interface is connected to all slave device ports of the on-chip system, and is responsible for receiving read data information and write response information returned by the slave devices, and sending address and control information and write data information to the slave devices. The slave interface is connected to all master device ports of the on-chip system and is responsible for receiving address and control information and write data information sent by the master device, and returning the corresponding read data information and write response information to the master device.
3. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 1, characterized in that, The arbitration system includes a decoding module and an arbitrator. The decoding module is responsible for assisting the arbitration system in determining the access object based on the communication requests received from each device. The decoding module includes a write transaction channel decoder, a read address channel decoder, and a read data channel decoder. The arbitrator is responsible for arbitrating all arbitration requests, with an arbitration delay of one clock cycle.
4. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 3, characterized in that, The write transaction channel decoder is used to decode the write address channel of the master device. The decoding result is related to the write address signal in the write address channel of the master device and the address space allocated to the slave device in the system. The input of the write transaction channel decoder includes the write address signals of all master devices and the start address and end address of all slave devices. The read address channel decoder is used to decode the read address channel of the master device. The decoding result is related to the read address signal in the read address channel of the master device and the address space allocated to the slave device in the system. The input of the read address decoder includes the read address signals of all master devices and the start address and end address of all slave devices. The read data channel decoder is used to decode the read data channels of slave devices. The decoding result is related to the RID signal in the read data channel of the slave device and the number assigned to the master device in the system. The input of the read data channel decoder includes the RID signals of all slave devices and the system number of all master devices.
5. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 1, characterized in that, The data distribution system includes: a write transaction channel occupancy table, a read transaction channel occupancy table, and a multi-channel data selection module. The read transaction channel occupancy table includes a read address channel occupancy table and a read data channel occupancy table. The read transaction channel occupancy table is responsible for recording the read communication status of each master and slave device and controlling the interconnection of related signals of the read address channel and read data channel between the master and slave devices by the multi-channel data selection module.
6. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 5, characterized in that, The write transaction channel occupancy table has several entries. Each entry records whether a write communication is in progress between a master device and a slave device. The entries have two states: IDLE and BUSY. The IDLE state indicates that no write transaction communication is in progress between the master and slave devices corresponding to this entry, while the BUSY state indicates that the master and slave devices are in progress. When a master device wins the arbitration in a write communication competition with a slave device, it looks up the write channel transaction occupancy table. If the table entry for the master and slave devices is in the IDLE state and neither the master nor the slave device has any other write communication tasks, the table entry state will change from IDLE to BUSY. After the master and slave devices complete the write transfer transaction, the status of the corresponding table entry changes from BUSY to IDLE. The end of the write transfer transaction is marked by the completion of the write response channel handshake.
7. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 5, characterized in that, The read address channel occupancy table is used to record the communication status of the read address channels of each master and slave device, and to control the interconnection of related signals of the channel between the master and slave devices by the multi-channel data selection module.
8. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 7, characterized in that, The read address channel occupancy table has several entries. Each entry records whether a read address communication is in progress between a master device and a slave device. The entries have two states: IDLE and BUSY. When the master device wins a competition for control of the write address channel of the slave device, and both the master and slave devices have idle read address channels, the status of the corresponding entry will change from IDLE to BUSY. When the read address channel between the master and slave devices completes the handshake, the table entry status changes from BUSY to IDLE.
9. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 5, characterized in that, The read data channel occupancy table is used to record the communication status of the read data channels of each master and slave device, and to control the interconnection of related signals of the channel between the master and slave devices by the multi-channel data selection module.
10. The Crossbar interconnect architecture based on the AMBA AXI protocol as described in claim 9, characterized in that, The read data channel occupancy table has several entries. Each entry records whether read data communication is in progress between a master device and a slave device. The entries have three states: IDLE, RESERVED, and BUSY. The IDLE state indicates that there is no communication task on the read address channel between the corresponding master and slave devices. The RESERVED state indicates that the master and slave devices have just completed a read data channel handshake. The BUSY state indicates that the master and slave devices are in the process of transmitting read data. When the status of a table entry is IDLE, the corresponding slave device has won the arbitration, and there are no other communication tasks on the master and slave device read data channels. In this case, the status will change from IDLE to BUSY. When the status of the table entry is BUSY, the status changes from BUSY to IDLE when the last transfer in the master-slave data read channel completes the handshake. If it is not the last transfer that completes the handshake, the status changes to RESERVED. When the table entry status is RESERVED, the slave device does not have the ability to continue returning read data, that is, the RVALID signal is low. If other slave devices do not have a need to return read data to the master device, the table entry status remains unchanged. If other slave devices have a need to return read data, the table entry status changes from RESERVED to IDLE. If the slave device has the ability to continue returning read data, that is, the RVALID signal is high, the status changes to BUSY.