EP0979457A2

EP0979457A2 - Method and apparatus for intermodule data transfer

Info

Publication number: EP0979457A2
Application number: EP99903037A
Authority: EP
Inventors: Timothy E. Hoglung
Original assignee: LSI Logic Corp
Current assignee: LSI Corp
Priority date: 1998-01-12
Filing date: 1999-01-11
Publication date: 2000-02-16
Also published as: WO1999048008A3; WO1999048008A2

Abstract

A method and apparatus for transferring data between devices in an integrated circuit (100). The devices are coupled to each other through a bus (116, 118, 120, 122, 124, 126) in which tri-state non-contention is insured through the use of turnaround cycles. Signals driven during an address state are turned around during data states while flow control signals are turned around during address cycles. Additionally, the bus of the present invention allows for both master devices (102, 104) and slave devices (106, 108, 110, 112) to regulate the transfer of data. Decentralized decoding also is employed in the transfer.

Description

METHOD AND APPARATUS FOR INTERMODULE DATA TRANSFER

1. Technical Field

The present invention relates to an improved data processing system and in particular to an improved method and apparatus for transferring data within a data processing system. Still more particularly, the present invention provides an improved bus architecture for transferring data between modules in a chip.

2. Description of the Related Art

In designing and manufacturing integrated circuit devices for computers, system level integration (SLI) is becoming more and more prevalent as consumers are interested in smaller and smaller computers. The smaller size requires consolidating and decreasing the size of components within a computer. In designing integrated circuits with increased system level integration, design efficiencies have been improved with better gate utilization with synthesis and improved place and route tools that minimize silicon area. Increasing data utilization and density also require that designers focus on implementing system components on a single die, also called system level integration. The market for system level (SLI) chips is estimated to grow to 14 billion dollars by the year 2000 from the 2 billion dollar level today.

With increased SLI in integrated circuits, performance problems are encountered in transferring data between various modules or devices on a SLI integrated circuit that are not encountered on higher level designs.

Therefore, it would be advantageous to have an improved method and apparatus for transferring data between various components within a SLI device.

-!• 3. Summary of the Invention

The present invention provides a method and apparatus for transferring data between devices in an integrated circuit. The devices are coupled to each other through a bus in which tri-state non-contention is insured through the use of turnaround cycles. Signals driven during an address state are turned around during data states while flow control signals are turned around during address cycles. Additionally, the bus of the present invention allows for both master devices and slave devices to regulate the transfer of data. Decentralized decoding also is employed in the transfer of data between devices.

4. Brief Description of the Drawings The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

Figure 1 is a block diagram of a system level integrated circuit;

Figure 2 is a block diagram of a slave device in accordance with a preferred embodiment of the present invention;

Figure 3 is a block diagram of a master device in accordance with a preferred embodiment of the present invention; Figure 4 is a state diagram for a slave device in accordance with a preferred embodiment of the present invention;

Figure 5 is a state diagram for a master device in accordance with a preferred embodiment of the present invention; Figure 6 is a state diagram for an arbiter in accordance with the preferred embodiment of the present invention;

Figure 7 is a state diagram for a bus in accordance with the preferred embodiment of the present invention;

Figure 8 is a timing diagram of single data read transactions with no wait states in accordance with a preferred embodiment of the present invention;

Figure 9 is a timing diagram of signal data read transactions with wait states in accordance with a preferred embodiment of the present invention;

Figure 10 is a timing diagram of single data write transactions with no wait states in accordance with a preferred embodiment of the present invention; Figure 11 is a timing diagram of write transactions with wait states in accordance with a preferred embodiment of the present invention;

Figure 12 is a timing diagram of burst read transactions without wait states in accordance with the preferred embodiment of the present invention;

Figure 13 is the timing diagram of burst read transactions involving wait states in accordance with a preferred embodiment of the present invention;

Figure 14 is a timing diagram of burst write transactions without wait states in accordance with a preferred embodiment of the present invention; and

Figure 15 is a timing diagram of burst write transactions involving wait states in accordance with a preferred embodiment of the present invention.

5. Detailed Description of the Preferred Embodiment

With reference now to the figures, and in particular to Figure 1, a block diagram of a system level integrated circuit. Integrated circuit 100 includes a master device 0 102 and a master device 1 104. These master devices may take the form of various devices, such as, for example, central processing unit, a direct memory access unit, and a bus bridge. In addition, slave devices 106, 108, 110, and 112 also are located within integrated circuit 100. Those of ordinary skill in the art will realize that slave devices may be implemented using numerous well-known devices, such as, for example, a memory controller, a timer, and a UART. In addition, integrated circuit 100 contains an arbiter 114. These devices are interconnected to each other by signal lines 116, 118, 120, 122, 124, and

126.

These signal lines make up a bus system for integrated circuit 100. These signal lines carry address information, data, along with control and request signals. Arbiter 114 is a source of point-to-point signals used for arbitration and for cycle start control. Arbiter 114 receives requests for the bus through signal lines 122 and 124. Arbiter 114 grants access to the bus through signal lines 120 and 126 in integrated circuit 100. For example, master device 0 102 sends a ZReq[0] signal to arbiter 114 through signal line 122 and receives a ZGnt[0] signal through signal line 120. Similarly, master device 1 and 104 sends a ZReq[l] signal on line 124 and receives ZGnt[l] on signal line 126. Address strobe signals (ZAds) , indicate a valid address and transfer direction are available on the bus, are sent on signal line 118. Signal line 116 carry shared signals, which are common to all master and slave devices. Each of these signals could be driven by multiple sources and involve sequencing to prevent tri-state contention. In particular, signal line 116 carries the following shared signals in the depicted example :

ZA, ZWrite, ZMrdy, ZSrdy, ZBlast, ZBen, and ZD. In the depicted example, signal line 116 may carry multiple bits of data across the line at the same time. For example, signal line 116 may be a 64 bit data path.

The following are descriptions of signals used in a bus in accordance with a preferred embodiment of the present invention: ZClk is a bus reference clock. All other bus signals must be stable within the specified setup and hold times with respect to the rising edge of ZClk.

ZReq[N:0] is a bus request signal. ZReq[N:0] are point-to-point signals driven by a bus master to the arbiter to request usage of the bus.

ZGnt[N:0] are bus grant signals. ZGnt[N:0] are point-to-point signals driven by the bus arbiter to each bus master. The ZGnt signals indicate which bus master will own the bus at the next transaction boundary. ZA[31:2] is a bus address. ZA[31:2] is driven by the active bus master during an address cycle to indicate the starting address of a burst or non-burst transaction.

ZWrite is a bus transfer direction signal, which is driven by the active bus master during an address cycle to indicate transfer direction for this transaction (1 == bus master writing data to slave, 0 == bus master reading data from slave) .

ZBen [3:0], ZBen[7:4] (64-bit) are bus byte enables. ZBen[3:0], ZBen[7:4] (64-bit) are driven by the active bus master during data cycles to indicate which byte lanes contain valid data.

ZAds is a bus address strobe signal, which is driven by the bus arbiter to indicate that valid address and transfer direction are available on the bus. ZAds, ZA, and ZWrite are monitored by slave devices to determine when they have been selected as a transaction target and what type of transaction is being requested.

ZBlast is a bus burst last signal. ZBlast is driven by the active bus master during data cycles to terminate a transaction. A transaction is complete when ZBlast, ZMrdy, and ZSrdy are all sampled asserted.

ZMrdy is a bus master ready signal, which is driven by the active bus master during data cycle to indicate that the bus master is ready to continue the transaction. This signal allows a bus master to pace a transfer.

ZSrdy is a bus slave ready signal. ZSrdy is driven by the selected slave device during data cycles to indicate that the slave device is ready to continue the transaction. This signal allows a slave device to pace a transfer .

ZD[31:0], ZD[63:32] (64-bit) represent in bidirectional bus data which is driven by a bus master during data cycles of write transactions and by a slave device during data cycles of read transactions.

In the depicted example, the basic unit of transfer for bus transactions is a pipelined burst in accordance with a preferred embodiment of the present invention. After a bus master has won arbitration and waited for the previous transaction to complete, the bus master issues an address cycle where it drives ZWrite as appropriate for the transaction and ZA[31:2] to the transaction start address. The bus master will then transition to data cycles until the transaction is complete (as indicated by ZBlast, ZMrdy, ZSrdy all asserted) . When a slave device determines that it has been "Selected" by sampling ZAds and ZA[n:m] equal to the address decode allocated for this slave, it either supplies read data or accepts write data on every clock rising edge where (ZMrdy == ZSrdy == 1) . A slave device is "Ready" when the slave device is ready to transfer data. The slave device will indicate that it is Ready by driving the signal ZSrdy to a logic 1. Both the bus master and slave device may regulate the data flow using ZMrdy and ZSrdy, respectively. When the slave device samples ZBlast, ZMrdy, ZSrdy all asserted, the slave device then considers the transaction to be complete. In accordance with a preferred embodiment of the present invention, the transfer direction (indicated by ZWrite) is sampled at the start of a transaction and is considered constant during a burst transaction.

Turning now to Figure 2, a block diagram of a slave device is depicted in accordance with a preferred embodiment of the present invention. Slave device 200 is illustrative of a slave device, such as slave devices 106, 108, 110, or 112 from Figure 1. Slave device 200 includes a slave address decoder unit 202, a slave device state machine 204 and a slave device function 206.

Slave device decoder 202 in Figure 2 illustrates decentralized decoding. Each slave device decodes its own address through slave device decoder 202 rather than employing a centralized decoding system. Slave address decoder 202 receives an address placed on the bus and decodes the address to determine whether the address falls within a range identified for slave device 200. If the address falls within the range for slave device 200, the slave device is then in a "selected" condition.

Slave device function 206 provides various functions known to those of ordinary skill in the art, such as, for example, reading and writing data.

According to the present invention, slave device function 206 indicates that it is in a "Ready" condition when it is ready for a data transfer. Slave device indicates that it is in the ready condition as evidenced by the assertion of the ZSrdy signal when it is ready for data transfer. Slave device state machine 204 provides the mechanism for transferring data between slave device function 206 and the bus. Slave device state machine 204 asserts a ZSrdy signal at a logic 1 when slave device function 206 indicates that it is ready and when slave address decoder 202 indicates that slave device 200 has been selected. Slave device state machine 204 is described in more detail in Figure 4 below.

With reference now to Figure 3, a block diagram of a master device is depicted in accordance with a preferred embodiment of the present invention. Master device 300 includes master device function 302 and master device state machine 304. Master device function 302 provides functions known to those of ordinary skill in the art that are normally associated with master devices. According to the present invention, master device function 302 indicates a "Request" condition when master device function 302 desires to access the bus. A "Done" condition is indicated by master device function 302 when master device 302 is finished transferring data. Master device state machine 304 provides the functions for requesting the bus, sending addresses onto the bus and transferring data. This state machine is described in more detail below in Figure 5. Turning now to Figure 4, a state diagram for a slave device is depicted in accordance with a preferred embodiment of the present invention. The state machine may be implemented in slave state machine 204 in slave device 200 as depicted in Figure 2. A slave device begins in Idle State SI. The slave device remains in Idle State SI as long as ! (ZAds & Selected) is present. The symbol "!" is used to indicate the inverse of the signal or condition. For example, if ZAds is normally indicated by logic 1, signal ! ZAds indicates logic 0 for the signal. The slave device shifts into Data State S2 in response to signal ZAds and conditions Selected & Ready being present. The slave device remains in this state as long as signals ! ZMrdy, ZMrdy, and ! ZBlast and condition Ready are present. In response to detecting signals ZBlast & ZMrdy on the bus, the slave device moves from Data State S2, in which data is being transferred, to Idle State SI. In response to detecting signals ZMrdy and ! ZBlast and condition ! Ready in Data State S2, the slave device transitions into Wait State S3. The slave device transitions into Wait state S3 from Idle State SI in response to detecting signals ZAds and Selected and condition ! Ready are present. From Wait State S3, the slave device remains in this state as long as ! Ready is present. The slave device transitions from Wait State S3 to Data State S2 when the condition Ready is present.

Turning now to Figure 5, a state diagram for a master device is depicted in accordance with a preferred embodiment of the present invention. The state diagram may be implemented in master device state machine 304 in master device 300 as illustrated in Figure 3. A master device begins in Idle State Tl and remains in Idle State Tl as long as the ! Request is not asserted present. A master device begins in idle state and remains there as long as the internal condition indicating a requirement to request the bus is absent with this being evidenced by the signal ZReq remaining at a logic zero. The master device transitions from Idle State Tl to Request (Req) State T2 in response to an internal condition indicating a requirement to request the bus from the master device indicating Request condition. In Request State T2 and drives the signal ZReq to a logic 1, the master device remains in Request State T2 as long as the signals ! (ZGnt & ZMrdy & ZSrdy & ZBlast) are present on the bus. The master device transitions to Request State T2 to Address State T3 when the signals ZGnt & ZMrdy & ZBlast are present on the bus. At this transition signal ZReq is deasserted. From Address State T3, the master device transitions into Data State T4 and remains in Data State T4 while the master device has additional data to transfer as indicated by the ! Done condition. The "Done" condition is an Internal State of the master device indicating that it is done transferring data and results in the assertion of the signal ZBlast. The master device returns to Idle State Tl after detecting the condition Done and detecting the signal ZSrdy on the bus. The bus of the present invention provides a pipelined arbitration protocol to support multiple master access to the bus. Determination of the next bus master is made while the current transaction is completing. The arbitration protocol is as follows:

1. Bus masters assert ZReq[m] to request ownership of the bus;

2. The Arbiter samples all ZReq[N:0] signals and responds with an appropriate ZGnt [m] signal which indicates which bus master will own the bus after the next transaction boundary (as indicated by ZMrdy == ZSrdy == ZBlast == 1) ;

3. The bus master with ZGnt [m] asserted becomes Active and issues an Address cycle upon sampling (ZGnt[m] & ZMrdy & ZSrdy & ZBlast) asserted; and

4. A bus master must deassert ZReq[m] during the Address cycle immediately after winning arbitration.

With reference now to Figure 6, a state diagram for an arbiter is depicted in accordance with the preferred embodiment of the present invention. This state diagram is for an arbiter such as arbiter 114 in Figure 1. The arbiter begins in Idle State Ul and remains there as long as no request is made for the bus as indicated by ! AnyRequest is present on the bus. AnyRequest is any individual ZREQ signal that is driven by any of the bus masters in the data processing system. The determination of whether a request has occurred is performed by the arbiter monitoring the bus for a signal ZReq[N:0]. At this time, the bus is in an Idle State in response to a request as indicated by AnyRequest, the arbiter shifts into IGrant state U2, which grants the bus from Idle State Ul . The bus grant is a single grant indicated by signal ZGnt[N:0], which is issued based on an arbitration algorithm, such as, for example, fixed priority, simple round robin, activity/slot based, etc.

From IGrant State U2, the arbiter shifts into Address State U3 in which the signal ZAds is driven active during this state. This signal tells all of the slave devices to evaluate the bus address to test for whether a particular slave device has been selected for a data transfer. If a new request (AnyRequest) occurs, the process then shifts into AGrant State U4 in which the arbiter waits for the current cycle to complete, which is indicated by CycleDone. CycleDone is the condition indicating that the current transaction is complete as evidenced by signals ZMrdy, ZSrdy, ZBlast being equal to a logic one.

As long as the cycle is not done (! CycleDone) , the arbiter remains in AGrant State U4. When the cycle is done, the arbiter shifts back to Address State U3. In Address State U3, if a new request does not occur, the process then shifts to NGrant State U5 and waits in this state until either another request occurs (AnyRequest) or the current cycle completes (CycleDone) . When the current cycle completes, the arbiter shifts back into Idle State Ul .

When the arbiter is in Idle State Ul or IGrant State U2, the arbiter will drive signals ZMrdy, ZSrdy, and ZBlast to a logic 1. This feature prevents the bus from locking up if a master device attempts to read or write a non-existent slave device.

Turning now to Figure 7, a state diagram for a bus is depicted in accordance with the preferred embodiment of the present invention. The bus is in Idle State VI until the arbiter grants the bus to a requesting bus master. At this time, the bus transitions from Idle State VI to Address state V2. During Address State V2, the active master device, also referred to as the bus master, sends data indicating the starting address of the data transaction. Thereafter, the bus transitions into

Data State V3 in which data is transferred across the bus between the active master device and the selected slave device. The bus returns to Idle State VI after the data transaction between the active master device and the selected slave device has been completed.

The bus protocol of the present invention insures tri-state non-contention through use of turn-around cycles. The phrase "turned around" means driven to high impedance or tri-stated. Signals driven during the Address State (ZA[31:2], ZWrite) are turned around during data states. The flow control signals (ZBlast, ZMrdy, ZSrdy) and byte enables (ZBen[3:0]) are turned around during address states. When the bus is in an idle state, the bus arbiter will drive the flow control signals (ZBlast, ZMrdy, ZSrdy) to their asserted values, preventing the bus from locking up if a master device attempts to read or write a non-existent slave device. The following table defines which signals are driven by whom during the three possible bus states (Idle, Address, Data) .

Turning now to Figure 8, a timing diagram of single data read transactions with no wait states is depicted in accordance with a preferred embodiment of the present invention. The signals on the bus can be in three states, a high state, a low state, or an off state. A high state may be a logic 1 while a low state may be a logic 0.

In the depicted example, requests ZReq[l] and ZReq [2] are received at the same time by an arbiter from two master devices, master device 1 and master device 2.

These requests are sent by master device 1 and master device 2 by driving signals ZReq[l] and ZReq[2] to a high state from a low state. In response, the arbiter grants the bus to master device 1 through signal ZGnt[l] by driving this signal to a low state to a high state. The signal ZWrite is driven by the bus master, master device 1, to a low state from an off state to indicate that the bus master is reading data from the slave device. During the Address State, an address Al 800 is sent over the bus from master device 1, which is now the bus master, to all slave devices. All slave devices are actively decoding the address to see whether the address is within the target range allocated to the slave device. Data Dl 802 is then sent across the bus by the selective slave device during the Data State.

Thereafter, the arbiter indicates to master device 2 that master device 2 will own the bus at the next transaction boundary for a data transfer with a selected slave device. This indication is provided by signal ZGnt [2]. At the next transaction boundary, which is indicated by ZBlast, ZMrdy and ZSrdy being driven to a high state, an address state occurs in which address A2 804 is sent over the bus by master device 2, which has now become the bus master. Data D2 806 is then sent across the bus by the slave device selected by master device 2.

Subsequently, master device 1 requests access to the bus and is granted access to the bus by the arbiter. An address A3 808 is sent over the bus to the selected slave device by master device 1 with data D3 810 then being sent over the bus. Then, master device 2 again requests access to the bus with access being granted. An address A4 812 is sent to the selected slave device from master device 2 with data D4 814 then being transferred across the bus .

The active bus master drives the signal ZMrdy to a high state to indicate that it is ready to proceed with the transaction. ZMrdy is used by the bus master to pace a data transfer. Additionally, the slave device also is able to pace the transfer to the signal ZSrdy which is driven to a high state in the depicted example to indicate that it is ready to continue the transaction. As can be seen, no wait states occur with the single data read transactions across the bus. Tri-state contention is prevented for the use of turnaround cycles or states . The signals driven during the address state, ZA[31:2] and ZWrite, are turned around during the data state when data is transferred across the bus. The flow control signals, ZBlast, ZMrdy, and ZSrdy, and byte enables, ZBen[3:0], are turned around during the address states. As can be seen, when the bus is in an idle state, the arbiter drives the flow control signals, ZBlast, ZMrdy, and ZSrdy, to an on state in the depicted example to ensure errant cycles will terminate.

With reference now to Figure 9, a timing diagram of single data read transactions with wait states is depicted in accordance with a preferred embodiment of the present invention. In the depicted example, requests, ZReq[l] and ZReq[2], are received by the arbiter from master device 1 and master device 2 for access to the bus. Ownership of the bus at the transaction boundary is granted to master device 1 by the arbiter using a reply signal ZGnt[l] . Address Al 900 is sent over to the bus to the selected slave device. The transfer of data Dl 902, however, does not occur immediately. The bus master, master device 1, has indicated that it is ready through its assertion of ZMrdy to a high state. The wait state occurs because the selected slave device is not yet ready to proceed with the transaction. The selected slave device is ready by driving signal ZSrdy to a high state from a low state. At that time, data Dl 902 is then read by master device 1. Thus, wait states occur during reading of data Dl 902.

The arbiter grants master device 2 ownership of the bus at the next transaction boundary with this indication being delivered to master device 2 through signal ZGnt [2]. Master device 2 sends address A2 904 over the bus, to all slave devices. All slave devices are actively decoding the address to see whether the address is within the target range allocated to the slave device. Data D2 906 is transferred over the bus. Again, wait states occur in the transferring of data D2 906 across the bus. Subsequently, master device 1 requests access to the bus through signal ZGnt[l] and is granted access by the arbiter, resulting in address A3 908 being sent to the selected slave device. After a period of time, data D3 910 is sent over the bus. With reference now to Figure 10, a timing diagram of single data write transactions with no wait states is illustrated in accordance with a preferred embodiment of the present invention. A write transaction is indicated by the master device driving the ZWrite signal to a high state from an off state. During a write transaction in the depicted example, master device 1 and master device 2 send requests ZReq[l] and ZReq[2] to gain access to the bus for write transactions. The arbiter grants access to master device 1, which then, as the bus master, sends an address Al 1000 to all of the slave devices. Master device 1 sends data Dl 1002 across the bus to the selected slave device. In addition, at the same time the master device sends byte enables data BE1 1004 to indicate to the selected slave device which byte lanes contains valid data.

Master device 2 is granted ownership of the bus at the next transaction boundary and becomes the bus master at that time. Master device 2 sends address A2 1006 across the bus to the selected slave device, which responds to address A2 1006. Byte enables data BE2 1008 and data D2 1010 are sent across the bus to the selected slave device. Subsequent writes are made by master device 1, to write data D3 1012 and master device 2 to write data D4 1014. With reference now to Figure 11, a timing diagram of write transactions with wait states is depicted in accordance with a preferred embodiment of the present invention. In this diagram, write transactions occurred in which master device 1 and master device 2 write data to a selected slave device. In this case, however, wait states occur in the transfer data of Dl 1100, D2 1102, and D3 1104. In the depicted example, the transfer of data Dl 1100 to the selected slave device from master device. The transition of ZMrdy and ZSrdy from a high state to an off state and then to a low state with a transition back to a high state or an off state illustrates the mechanism of tri-stated non-contention on the bus .

Next, master device 1 is granted access to the bus and sends address A3 1110 to the selected slave device. The selected slave device indicated that it is ready for the transaction through its assertion of the signal ZSrdy to a high state. In the depicted example, however, the bus master, master device 1, is not ready to proceed with the transaction, which is indicated by the signal ZMrdy being driven to a high state. This signal results in wait states occurring until master device 1 indicates that master device 1 is ready by driving the signal ZMrdy to an off state. With reference now to Figure 12, a timing diagram of burst read transactions without wait states is depicted in accordance with the preferred embodiment of the present invention. In the depicted example, both master device 1 and master device 2 send requests, ZReq[l] and ZReq[2], for access to the bus. In the depicted example, the arbiter grants master device 1 access to the bus. Master device 1 sends address Al 1200 across the bus and drives signal ZWrite low to indicate a read operation. Additionally, master device 1 drives signal ZBlast from a high state to an off state and then to a low state.

Thereafter, data D1-D4 1202-1208 are transferred across the bus. While data is being transferred, the arbiter grants master device 2 access to the bus for the next transaction boundary. As a result, address data A5 1210 is not sent to the selected slave device until the active bus master, master device 1, drives this signal to a high state to indicate that the transaction has been completed. At that time, master device 2 sends address A5 1210 on the bus to be decoded by the slave devices to determine which slave device will be involved in the data transaction and then data D5-D12 1212-1226 is read in a burst transaction.

With reference now to Figure 13, the timing diagram of burst read transactions involving wait states is depicted in accordance with a preferred embodiment of the present invention. In the depicted example, the arbiter receives requests to access the bus at the same time from master device 1 and master device 2 through signals ZReq[l] and ZReq[2]. Master device 1 becomes the bus master before master device 2. Master device 1 sends address Al 1300 to the slave devices. All slave devices are actively decoding the address to see whether the address is within the target range allocated to the slave device. In the depicted example, master device 1 indicates that it is ready to receive data D1-D4 1302- 1308 by asserting signal ZMrdy to a high state. The slave device, however, does not immediately indicate that it is Ready, as indicated by the signal ZSrdy being in a low state for several clock cycles. The data transfer of data Dl 1302 occurs when both the master device and the slave device are Ready to continue the transaction. In the depicted example, additional wait time occurs prior to the transfer of data D2 1304, D3 1306, and D4 1308. At the end of this transaction, master device 2 sends address A5 1310 to the selected slave device to transfer data D5-D8 1312-1318. As with the transfer of data D1-D4 1302-1308, wait states are present prior to the transfer of data D5 1312 and D6 1314 and prior to the transfer of data D7 1316 and D8 1318 from the slave device to master device 2. Turning next to Figure 14, a timing diagram of burst write transactions without wait states is depicted in accordance with a preferred embodiment of the present invention. In the illustrative example, master device 1 and master device 2 both assert requests for the bus at the same time through signals ZReqfl] and ZReq[2]. Master device 1 becomes the bus master and sends address Al 1400 over the bus to all of the slave devices with a selected slave device responding to address Al 1400. Then, master device 1 sends byte enables data BE1-BE4

1402-1406 and data D1-D4 1408-1414 over the bus. After the data has been sent over the bus, master device 1 relinquishes control over the bus and master device 2 becomes the bus master, sending address data A5 1416 over the bus to the selected slave device. Byte enables data BE5-BE12 1418 and data D5-D12 1420-1434 are sent over the bus to the selected slave device.

With reference to Figure 15, a timing diagram of burst write transactions involving wait states is depicted in accordance with a preferred embodiment of the present invention. In the depicted example, both master device 1 and master device 2 has requested access to the bus at the same time. Access is granted to master device 1, which sends address Al 1500 over the bus to all of the slave devices with a selected slave device responding to address Al 1500. Byte enables BE1-BE3 1502-1506 and data D1-D3 1508-1512 are sent over the bus by master device 1. In the depicted example, master device 1 is in a ready state, as indicated by signal ZMrdy, while the selected slave device contains several time periods in which it is not in a ready state, as indicated by a signal ZSrdy being in a low state before the transfer of data Dl 1508 and between the transfer of data Dl 1508 and D2 1510 and data D2 1510 and D3 1512. In this example, wait states caused by the selected slave device occur in the transfer of data D1-D3 1508-1512.

Control of the bus is then given to master device 2, which sends address A4 1514 to the selected slave device and then the transfer of byte enables data BE4-BE8 1516- 1524 and data D4-D8 1526-1534 occurs. In this case, the selected slave device is not ready initially for the transfer of data as indicated by signal ZSrdy. Upon the transfer of data D4 1526, the selected slave device continues to be in a ready state to receive data from master device 2. Master device 2, however, is not ready during the entire transaction as can be seen by signal ZMrdy. As a result, wait states caused by master device 2 occur in transferring data to the selected slave device.

Thus, the bus architecture of the present invention provides a standard interconnect and signaling protocol for inter-module data transfer within a chip design. The present invention defines a bus architecture that provides for multiple bus master and slave devices, efficient burst data transactions, pipelined "hidden" arbitration, and balanced flow control in which both master and slave devices can pace data transfer. The bus architecture of the present invention is for fully synchronous using single clock edge only - "synthesis friendly", frequency scalable, and easily extendable to 64-bit data path. Additionally, the bus architecture of the present invention has minimal dependency on round- trip signal propagation and protocol provides tri-state non-contention.

The description of the preferred embodiment of the present invention has been presented for purposes of illustration and description, but is not limited to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention the practical application to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

Claims :What is claimed is:

1. An integrated circuit comprising: a bus; a plurality of master devices, wherein the plurality of master devices are connected to the bus; a plurality of slave devices, wherein the plurality of slave devices are connected to the bus; and signaling means for providing tristate non- contention in data transfers between the plurality of master devices and the plurality of slave devices.

2. The integrated circuit of claim 1, wherein the bus has an address state and a data state and wherein the signaling means includes: first signal means, active during the data state, for turning around signals driven during the address state; and second signal means, active during the address state, for turning around signals driven during the data state.

3. The integrated circuit of claim 2, wherein the first signal means includes means for returning signals driven during the data state to a default level, wherein the signals are returned to the default level during the data state.

4. The integrated circuit of claim 2, wherein the second signal means includes means for returning signals driven during the address state to a default level, wherein the signals are returned to the default level during the address state.

5. The integrated circuit of claim 1, wherein during a data transfer between a master device within the plurality of master devices and a slave device within the plurality of slave devices, both the master device and the slave device regulate the data transfer.

6. The integrated circuit of claim 5 wherein address decoding is decentralized.

7. The integrated circuit of claim 5, wherein each of the slave device within the plurality of slave devices includes an address decoder such that decoding of addresses occurs within each slave device within the plurality of slave devices.

8. The integrated circuit of claim 1, further comprising second signaling means for driving signals on the bus indicating that a master deivce is ready to continue to transfer data, indicating a slave device is ready to continue to transfer data, and indicating termination of a data transaction, wherein bus lock up caused by a master device attempting to access a non-existent slave device is avoided.

9. The integrated circuit of claim 8, wherein each of the slave device within the plurality of slave devices includes an address decoder such that decoding of addresses occurs within each slave device within the plurality of slave devices.

10. The integrated circuit of claim 8, wherein the signaling means and the second signaling means are located within an arbiter coupled to the bus .

11. An integrated circuit comprising: a bus; a plurality of master devices, wherein the plurality of master devices are connected to the bus, wherein a master device within of the plurality of master devices drives a first signal to a first state to indicate that the master device is ready to continue to transfer data during a data cycle and drives a second signal to the first state to terminate a data transfer; a plurality of slave devices, wherein the plurality of slave devices are connected to the bus, wherein a slave device within the plurality of slave devices drives a third signal to the first state to indicate that the slave device is ready to continue to transfer data during a data cycle; an arbiter, wherein the arbiter drives the first signal, the second signal, and the third signal to the first state such that a lock up condition on the bus caused by a master device within the plurality of master devices attempting to access a nonexistent slave device is avoided.

12. The integrated circuit of claim 11, wherein the first state is a logic one.

13. The integrated circuit of claim 11, wherein the first signal is a bus master ready signal.

14. The integrated circuit of claim 11, wherein the second signal is a burst last signal.

15. The integrated circuit of claim 11, wherein the third signal is a bus slave ready signal.

16. The integrated circuit of claim 11, wherein the data cycle involves a read transaction.

17. The integrated circuit of claim 11, wherein the data cycle involves a write transaction.

18. The integrated circuit of claim 11, wherein each of the plurality of slave devices includes a decode used to decode an address from a master device within the plurality of master devices, wherein the decoded address is used by a slave device to determine whether the address is within an address range associated with the slave device.

19. The intergrated circuit of claim 11, wherein the bus has an address state and a data state and wherein the arbiter includes: first signal means, active during the data state, for turning around signals driven during the address state; and second signal means, active during the address state, for turning around signals driven during the data state .

20. A method for controling transfer of data within an integrated circuit, wherein the integrated circuit includes a bus, a plurality of master devices and a plurality of slave devices, the method comprising: driving signals indicating that a master deivce is ready to continue to transfer data, indicating a slave device is ready to continue to transfer data, and indicating termination of a data transaction, wherein bus lock up caused by a master device attempting to access a non-existent slave device is avoided.

21. The method of claim 20, wherein the step of driving is performed by an artbiter coupled to the bus.

22. The method of claim 20 further comprising providing tristate non-contention on the bus.

23. The method of claim 22, wherein the step of providing is performed by an arbiter coupled to the bus.

24. The method of claim 20 further comprising decoding addresses at each of the plurality of slave devices.

25. A method for controlling transfer of data within an integrated circuit, wherein the integrated circuit includes a bus, a plurality of master devices and a plurality of slave devices, the method comprising: providing tristate non-contention on the bus; decoding addresses at each of the plurality of slave devices; and driving signals indicating that a master device is ready to continue to transfer data, indicating a slave device is ready to continue to transfer data, and indicating termination of a data transaction, wherein bus lock up caused by a master device attempting to access a non-existent slave device is avoided.

26. The method of claim 25, wherein the step of providing and driving are performed by an arbiter coupled to the bus .