Low cost data streaming mechanism

[0002] 1. Field of the Invention

[0003] The present invention relates generally to computer systems, and specifically, to a method and apparatus for providing a low-cost, efficient data streaming mechanism between two buses.

[0004] 2. Background Information

[0005] In computer systems, bus bridges are typically used to separate a first bus from a second bus. This isolates transactions on the first bus from affecting transactions on the second bus, and vise versa. Moreover, the physical characteristics of a bus place a limit on the number of devices (or agents) that may be attached to it. Accordingly, many computer systems implement multiple-bus architectures having a number of physically separate buses to further expand functionality. The buses may be the same bus (protocol) or may be of different protocols. Thus, the bus bridge also interfaces one bus protocol to another, thereby allowing agents on the different buses to communicate.

[0006] A bus bridge that couples two buses together is typically transparent so that the physically separate buses may be treated by an agent and the system as on bus. To accomplish such a result, an address space is shared by agents on each bus. Read and write requests bearing an address range within the shared address space are generated by an initiator agent on an initiating bus. The bridge recognizes the address range and forwards the request to a target agent on a target bus. Thus, the bridge acts as the initiator on the target bus for the initiator agent on the initiating bus.

[0007] There is a myriad of bus and bridge architectures in the current state of computer technology. An example of a modern, computer bus is the Peripheral Components Interconnect (PCI) bus. The PCI bus is an industry standard, high performance, low latency system bus, generally defined by the PCI Special Interest Group (SIG) in PCI Local Bus Specification, Revision 2.1, Oct. 21, 1994. The PCI SIG also maintains a bridge architecture described in PCI-to-PCI Bridge Architecture Specification, Revision 1.0, Apr. 5, 1994.

[0008] Transactions are defined here as complete transfers of data between an initiator and a target, where the initiator and target are on different physical buses coupled by a bridge. When forwarding data from one bus to another, bridges typically implement data queues to hide the delay associated with requesting and obtaining access to the target bus for obtaining or forwarding the data. Each transaction is typically assigned a logical queue which is released when the transaction is completed.

[0009] The queue will typically be part of a memory or buffer that implements a First-In-First-Out (“FIFO”) data structure. The FIFO is a data structure from which items are taken out in the same order they were put in. Typically, the FIFO may be written to and read from simultaneously.

[0010] A transaction as defined herein involves a request from an initiator to read from or write to a given address range which is claimed by a target. If the request is accepted by the bridge, the transaction begins and an appropriate access is started. An access typically includes an idle phase for setup, an address phase during which address information for the particular request is exchanged, and a data phase during which data is exchanged.

[0011] Alternatively, the request may be denied by the bridge. In that case, the bridge issues a termination known as a retry signal to the initiator. This may occur if the assigned bridge queue has no data to transfer or is full (e.g., the queue is being used for another pending transaction). If the request is denied, the initiator may repeat the request to complete an ongoing transaction or attempt to start a new one.

[0012] Where the request is accepted and a first access is started, the access may be prematurely terminated by the initiator, the target, or the bridge, for various reasons. If this happens, the request may be repeated or a subsequent request may be issued by the initiator to complete the transaction and transfer all of the requested data. Splitting the transaction so that the desired data is transferred in multiple accesses, however, introduces increased overhead in the form of additional accesses having additional idle and address phases. The increased overhead can reduce throughput, where throughput is the amount of data transferred across the bridge per unit time, averaged over a given period. It would be desirable to have a technique that permits an increase in throughput so that the bridge may be tuned to the particular application.

[0013] FIG. 1 illustrates a block diagram of a portion of a conventional computer system having two buses separated by a bus bridge. As shown therein, a bus bridge 10 is coupled between first and second buses 30 and 40. Also coupled to the first bus 30 are a plurality of devices including agent 32 and memory 34. Similarly, coupled to bus 40 are a plurality of devices including agent 42 and memory 44. The bus bridge 10 includes first and second unidirectional data queues 12 and 14, bus interface 16 for interfacing with the first bus 30, and bus interface 18 for interfacing with the second bus 40. The unidirectional data queue 12 is used solely for data transfers from the bus 40 to the bus 30 (i.e., a read by agent 32 from a device on bus 40 or a write by agent 42 to a device on bus 30), which is referred to as an outbound direction. Conversely, the unidirectional data queue 14 is used solely for data transfers from the bus 30 to the bus 40 (i.e., a read by agent 42 from a device on bus 30 or a write by agent 32 to a device on bus 40), which is referred to as an inbound direction.

[0014] Read Transaction

[0015] For a read, agent 322 initiates a read transaction for data from memory 44. The bridge 10 decodes the address of the transaction and checks at the queue 12 to determine whether the queue 12 has any data. Initially, the data queue 12 is empty and, as a result, the bridge 10 retries the initiator agent 32 indicating that no data is available. The bridge 10 begins filling up the data queue 12 with read data. In the meantime, the initiator agent 32 retries the bridge 10. This time the bridge 10 has data and starts draining the data from the queue 12. There are three conditions where the data transfer is stopped. The first is where there is an error due to any event. The second is where agent 32 is completely satisfied. The third is where the data queue 12 becomes empty (i.e., and under-run condition). If there is an under-run condition, the bridge 10 disconnects the agent 32, The agent 32 then has to initiate a further transaction to retrieve the data from the beginning or from the point where the under-run condition occurred. As can be seen, this reduces the efficiency of the data transfer.

[0016] One technique to prevent the queue 12 from becoming empty involves including logic within the bridge 10 to reacquire the bus 40 to maintain data in the data queue 12. From a data movement point of view, this technique is effective. However, from a complexity and silicon point of view, this technique poses a problem. That is, the logic required to prevent the queue 12 from becoming empty is complex and out of proportion to the rest of the logic in the bridge 10. Another problem, is that since the data queue 12 is unidirectional, agent 42 on bus 40 is blocked from initiating any transactions. Moreover, agent 42 is blocked from placing write data in the data queue 12 because the data queue is being used by the read transaction. This further hampers performance.

[0017] Write Transaction

[0018] For a write, agent 32 initiates a write transaction targeted for memory 44. The bridge 10 decodes the address and indicates to agent 32 that it is ready to receive data (assuming that the queue 14 has sufficient space). As a result, data begins filling the data queue 14. The bridge 10 then initiates a transaction on the bus 40 to write data to memory 44. Once the bridge 10 gets control of bus 40, it transfers data from queue 14 to memory 44. Again, from the point of view of agent 32, this is efficient because its request is being serviced uninterrupted. However, from a system stand point, this technique causes a problem because both buses are tied up, preventing agents hanging off bus 40 from utilizing the bus 40.

[0019] Consequently, it is desirable to provide a method and apparatus which overcome the aforementioned drawbacks.

[0020] The present invention comprises a data streaming method and apparatus. In one embodiment, a data streaming method includes detecting a transaction on a first bus that is targeted to a second bus, claiming the transaction to begin filling data in a queue, initiating a further transaction on the second bus to commence draining data from the queue when the first queue is filled up to a threshold value, and terminating the further transaction on the second bus when the queue is substantially empty, while data is filling in the queue from the first bus. One or more subsequent transactions are initiated and terminated on the second bus, as necessary, to drain data from the queue to the second bus when the queue is filled up to the threshold value and/or until the transaction is completed. The second bus operates at a faster speed than the first bus.

[0021] FIG. 1 illustrates a block diagram of a portion of a conventional computer system having two buses separated by a bus bridge.

[0022] FIG. 2 illustrates a block diagram of a portion of a computer system according to one embodiment of the present invention.

[0023] FIG. 3 graphically and sequentially illustrates a data write streaming mechanism according to one embodiment of the present invention.

[0024] FIG. 4 graphically and sequentially illustrates a data read streaming mechanism according to one embodiment of the present invention.

[0025] FIG. 5 illustrates a portion of the control logic of FIG. 2 according to one embodiment of the present invention.

[0026] The present invention comprise a method and apparatus for providing an efficient, low cost data streaming mechanism from a first bus architecture to a second bus architecture across a bus bridge. Separate read and write data queues are provided in the bus bridge for inbound and outbound directions, and the speed of one of these buses is greater than the speed of the other one of the buses. In one embodiment, the first bus is a PCI bus and the second bus us an internal CPU bus.

[0027] FIG. 2 illustrates a block diagram of a portion of a computer system 200 according to one embodiment of the present invention. Referring to FIG. 2, the computer system 200 includes a bus bridge 110 coupled to a first bus 140 by way of a first bus interface 130, and a second bus 150 by way of a second bus interface 132. Coupled to the first bus 140 are a plurality of agents 142₁-142_A(where “A” is a positive whole number), and memory 144. Further, coupled to the second bus 150 are a plurality of agents 152₁-152_B(where “B” is a positive whole number), and memory 154. Agents on the first and/or second buses may include a communication device such as a network card, an input/output controller device for coupling to a mass storage device, a central processing unit (e.g., microprocessor, microcontroller, digital signal processor, etc.), and the like. In one embodiment, the first bus 140 is a core or internal CPU bus whereas the second bus 150 is a PCI bus, although the first and second buses 140 and 150 may adhere to any other type of bus architecture and protocol.

[0028] The bridge 110 includes an inbound queue 112 having an inbound write queue (“IWQ”) 114 and an inbound read queue (“IRQ”) 116, and an outbound queue 120 having a an outbound write queue (“OWQ”) 122 and an outbound read queue (“ORQ”) 124. Data transfer for a write transaction initiated on bus 150 and targeted to a device on bus 140 across the bus bridge 110 flows through the IWQ 114, whereas data transfer for a write transaction initiated on bus 140 and targeted to a device on bus 150 flows through the OWQ 122. Correspondingly, data transfer for a read transaction initiated on bus 150 and targeted to a device on bus 140 across the bus bridge 110 flows through the IRQ 116, whereas data transfer for a read transaction initiated on bus 140 and targeted to a device on bus 150 flows through the ORQ 124.

[0029] Each queue behaves as a FIFO data structure. The depth of each queue is selected such that data transfer efficiency and throughput is maximized. In one embodiment, the depth of each queue is 128 bytes, though the depth may be higher or lower, and may differ from one queue to another. The bridge 110 further includes control logic 134 for controlling the queues and the bus interfaces.

[0030] In the embodiment of FIG. 2, separate inbound and outbound read and write queues are provided, allowing for a read request initiated by an agent on bus 150 and targeted for a device on the second bus 140, and a write request initiated by an agent on bus 140 and targeted for a device on bus 150 to occur simultaneously. This provision was not provided for in the prior art mechanism where a write request initiated on bus 140 and targeted to bus 150 was blocked by a previous read request initiated on bus 150 and targeted to bus 140 because of the unidirectional data queues.

[0031] Additionally, with the present invention, the speed of the first bus 140 is faster then the speed of the second bus 150. In one embodiment, the speed of the first bus 140 is twice as fast as the speed of the second bus 150.

[0032] The combination of separating the data queues and the greater speed of one bus over the other allows for an efficient, low cost data streaming mechanism to be realized, as will be seen in the following sections.

[0033] Write Transaction

[0034] For a write transaction initiated on bus 150 and targeted to bus 140, the initiator is hereinafter referred to as agent 152, and the target is hereinafter referred to as memory 144. Agent 152 initiates a write request to write data to memory 144 by placing an address of memory 144 on bus 150. The bridge 110 detects the address and claims the transaction. Assuming that the IWQ 114 is not full, the bridge 110 begins filling data in the IWQ 114. Data is placed in the IWQ 114 until a predetermined threshold level is reached or the write data is completed (in the case where the predetermined threshold level is not reached). The predetermined threshold level is also hereinafter referred to as the high watermark. As soon as the high watermark is reached, the bridge 110 initiates a write request on bus 140. After acquiring control of the bus 140, the bridge begins draining the IWQ 114 to memory 144. Since the speed of the bus 140 is faster than the speed of the bus 150, the bridge 110 will likely drain the IWQ 114 before it fills. The high watermark should be set at a value that will ensure or substantially ensure that the IWQ 114 will not be filled before the bridge starts draining data. In one embodiment, in the case where the speed of bus 140 is twice of fast as the speed of bus 150, the high watermark is set at 50% of the IWQ 114 capacity. Generally, the depth of the IWQ 114 and the high watermark should be set at values that take into consideration the latency of acquiring control of bus 140 to maximize efficiency of the system, without causing the IWQ 114 to become filled (e.g., an over-run condition).

[0035] Continuing to refer to FIG. 2, once the bridge 110 drains and empties the IWQ 114, the bridge 110 ends the transaction on the bus 140, but continues to fill the IWQ 114 from the transaction on bus 150. The bus 140 is now available for use by other agents or other data transfers. The bridge 110 then reacquires the bus 140 as often as necessary to drain the IWQ 114 to the end of the transaction. The bridge 110 then ends the transaction on the bus 150. From the initiator-master point of view, the streaming of data is uninterrupted and unbroken, thereby maximizing data movement. From the system point of view, agents on the bus 140 are free to acquire the bus 140 in between the bridge 110 acquiring the bus to maximize overall efficiency.

[0036] FIG. 3 graphically and sequentially illustrates a data write streaming mechanism according to one embodiment of the present invention. The bar graphs indicate the current level of the IWQ 114. Referring to FIG. 3, at act 1 on bus 150, a write streaming transaction begins where data is placed in the IWQ 114. At act 1 on the bus 140, after the high watermark (“HWM”) is reached, the bridge 110 begins draining data faster than bus 150 can fill the IWQ 114. At act 2 on bus 150, the write streaming continues, whereas at act 2 on bus 140, the write transaction empties the IWQ 114, terminating the transaction on bus 140. At act 3 on the bus 150, the write streaming transaction continues. When the HWM is reached, at act 3 on the bus 140, the bus 140 is reacquired and data is again drained from the IWQ 114. Note that at act 3 on bus 150, an end of write streaming transaction also triggers a further write transaction on bus 140 (in the case where the HWM is not reached). At act 4 on bus 150, the write transaction ends. Finally, at act 4 on bus 140, the write transaction continues until the IWQ 114 is empty.

[0037] Read Transaction

[0038] For a read initiated on bus 150 and targeted to bus 140, agent 152 initiates a read transaction to read data from memory 144 by placing an address of memory 144 on bus 150. The bridge 110 detects the address and claims the transaction. The bridge 110 then indicates to the agent 152 to retry the read transaction (since the bridge 110 has not yet placed data in the IRQ 116), while capturing in the address and command for issuing on the bus 140. The bridge then acquires the bus 140 and begins filling up the IRQ 116 with data. Once a predetermined threshold is reached (i.e., low watermark, “LWM”), the bridge 110 claims the retried read transaction on bus 150. The low watermark ensures that the bridge 110 does not empty after one data transfer. In one embodiment, the low watermark is set at 50% of the depth of the IRQ 116, though it may be set at any percentage. Moreover, the bridge 110, which is being filled faster than it is emptied, can return data to the agent 152 until the IRQ 116 fills. Once this occurs, the bridge 110 no longer tries to acquire more data from memory 144 and relinquishes the bus 140 for use by other agents. Once the agent 152 drains the IRQ 116, the bridge 110 disconnects the agent 152, forcing it to initiate a further read request if more data is desired.

[0039] By selecting the depth of the IRQ 116, and determining the typical amount of data transfer for a read transaction, the number of retries can be minimized, thereby maximizing overall system efficiency. From the initiator agent point of view, the streaming of data is uninterrupted and unbroken. From a system point of view, agents on the bus 140 are free to acquire the bus 140 after the bridge 110 relinquishes the bus.

[0040] FIG. 4 graphically and sequentially illustrates a data read streaming mechanism according to one embodiment of the present invention. The bar graphs indicate the current level of the IRQ 116. Referring to FIG. 4, at act 1 on bus 150, a read streaming transaction is initiated by an agent, and the bridge 110 retries the agent. At act 1 on the bus 140, the bridge 110 acquires control of bus 140 and begins to fill the IRQ 116. At act 2 on bus 150, the agent 152 continues to get retried by the bridge 110 until the IRQ 116 is filled up to the LWM, at which time the bridge 110 grants the request to the agent 152 and begins draining the IRQ 116. At act 2 on bus 140, data is placed in the IRQ 116 faster than it is drained on bus 150. At act 3 on the bus 150, the read streaming transaction continues and data is drained from the IRQ 116. At act 3 on the bus 140, the bridge 110 terminates the read transaction on bus 140 when the IRQ 116 is filled with data. At act 4 on bus 150, the read transaction continues and data is drained from the IRQ 116. Finally, at act 5 on bus 150, the read transaction terminates when the IRQ 116 is empty. If the agent 152 desires more data from memory 144, the agent 152 retries the transaction to acquire more data. However, this is not a frequent event as the agent 152 will be completely satisfied most of the time.

[0041] The provision of keeping the bus 140 occupied until the entire read transaction is completed on bus 150 is at an additional penalty since the bus 140 is not free for other agents. This mechanism provides a tradeoff between maximum usage of the bus 140 against occasional under-run conditions of the IRQ 116.

[0042] FIG. 5 illustrates a portion of the control logic 134 of FIG. 2 according to one embodiment of the present invention. It should be noted that only the portion(s) of the control logic 134 relevant to embodiments of the present invention are shown, namely control logic related to the inbound queue 112.

[0043] Referring to FIG. 5, the control logic 134 includes write logic 210 relating to the IWQ 114, and read logic 250 relating to the IRQ 116. Write logic 210 includes top and bottom pointers, hereinafter references by numerals 212 and 214, respectively, which point to the IWQ 114. More specifically, each time data is clocked in the IWQ 114, the top pointer 212 is incremented, and each time data is clocked out of the IWQ 114, the bottom 214 pointer is incremented. The IWQ 114 is treated as a circular buffer, such that the pointers wrap around from the bottom to the top of the IWQ 114. The bottom pointer 214 is fed into comparators 220, 222, and 224. The top pointer 212 is fed into comparator 220, comparator 222 through a first delay circuit 216, and comparator 224 through the first delay circuit 216 and a second delay circuit 218. The purpose of the delay circuits 216 and 218, and comparators 222 and 224 is to provide a look forward mechanism so that if the IWQ 114 is about to go full, the device providing data into the IWQ 114 can be stopped. In this embodiment, the top pointer 212 can be compared to the bottom pointer 214 up to two clocks ahead of time.

[0044] The output of comparators 220, 222, and 224 are fed to a combination logic 226. Also coupled to the combination logic 226 is a read/write signal generated by an initiator on bus 150 and forwarded by the bus interface 132, and the HWM value that is loaded from a memory location or programmable register contained within the bridge 110 (not shown). The combination logic 226 compares the HWM value with the depth of the IWQ 114 (difference between the top and bottom pointers 212 and 214 output by, for example, comparator 224). If the depth of the IWQ 114 reaches the HWM value or the write transaction is terminated before such event, the combination logic 226 asserts a drain signal on signal line 228, which is fed to the bus interface 130. The bus interface 130 then requests acquisition of the bus 140 to drain the IWQ 114. When the IWQ 114 becomes empty (e.g., the output of comparator 224 becomes zero), the combination logic 226 asserts a terminate bus signal on signal line 230, which is also coupled to the bus interface 130. In response, the bus interface 130 terminates the transaction and relinquished control of bus 140. If, however, the IWQ 114 becomes full (e.g., the output of comparator 224 is substantially equal to the maximum capacity of the IWQ 114), the combination logic 226 asserts a terminate bus signal on signal line 232, which is coupled to the bus interface 132. In response, the bus interface 132 terminates the transaction on bus 150, preventing a data over-run condition in the IWQ 114. As can be seen, the control logic is substantially simplified using the data streaming mechanism of the present invention.

[0045] Continuing to refer to FIG. 5, the read logic 250 includes top and bottom pointers, hereinafter references by numerals 252 and 254, respectively, which point to the IRQ 116. Similar to the IWQ 114, each time data is clocked in the IRQ 116, the top pointer 252 is incremented, and each time data is clocked out of the IRQ 116, the bottom pointer 254 is incremented. The IRQ 116 is treated as a circular buffer, such that the pointers wrap around from the bottom to the top of the IRQ 116. The read logic 250 has a similar look ahead circuit as the write logic 210. The look ahead circuit includes delay circuits: 256 and 258, and comparators 260, 262, and 264.

[0046] The output of comparators 260, 262, and 264 are fed to a combination logic 266. Also coupled to the combination logic 266 is a read/write signal generated by an initiator on bus 150 and forwarded by the bus interface 132, and the LWM value which is loaded from a memory location or programmable register contained within the bridge 110 (not shown). The combination logic 266 compares the LWM value with the depth of the IRQ 116 (difference between the top and bottom pointers 252 and 254 output by, for example, comparator 264). If the depth of the IRQ 116 reaches the LWM value or the read transaction is terminated before such event, the combination logic 266 asserts a drain signal on signal line 268, which is fed to the bus interface 132. The bus interface 132 then claims the transaction to drain the IRQ 116, in response to a read request by an agent on bus 150 for the data in the IRQ 116. When the IRQ 116 becomes full (e.g., the output of comparator 264 is substantially equal to the maximum capacity of the IRQ 116), the combination logic 266 asserts a terminate bus signal on signal line 270, which is coupled to the bus interface 130. In response, the bus interface 130 terminates the transaction on bus 140, preventing a data over-run condition in the IRQ 116. When the IRQ 116 becomes empty (e.g., the output of comparator 264 becomes zero), the combination logic 266 asserts a terminate bus signal on signal line 272, which is coupled to the bus interface 132. In response, the bus interface 132 terminates the transaction.

[0047] By utilizing the above implementation, complex logic in the bridge 110 is minimized. The bridge 110 avoids sticky logic and boundary conditions by not reacquiring the bus 140 after it has terminated a read. The read by an agent on the bus 150 can terminate at any time, including just before, during, or after the bridge 110 begins refilling the IRQ 116 (if it were to reacquire the bus 140). These conditions are rife with lockup possibilities which the present invention bypasses completely. For the same reason, the bridge 110 does not attempt to insert wait states on the bus 140 to retain ownership of the bus 140 to maintain a write stream. Instead, the present invention takes advantage of the natural frequency mismatch between the buses 140 and 150 to maximize both bus utilization on bus 140 and opportunity for data streaming. Furthermore, validation time and silicon area are minimized by avoiding expensive solutions such as PCI bus wait-state throttling and read re-acquisition.

[0048] While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.