Dual burst latency timers for overlapped read and write data transfers

[0002] The present invention relates in general to data processing systems, and in particular, to bus systems with independent read and write data buses.

[0003] Recent advances in silicon densities now allow for the integration of numerous functions onto a single silicon chip. With this increased density, peripherals formally attached to the processor at the card level are now integrated onto the same die as the processor. As a result, chip designers must now address issues traditionally handled by the system designer. In particular, the on-chip buses used in such system-on-a-chip (SOC) designs must be sufficiently flexible and robust in order to support a wide variety of embedded system needs.

[0004] The IBM Blue logic core program, for example, provides the framework to efficiently realize complex system-on-a-chip designs. Typically, an SOC contains numerous functional blocks representing a very large number of logic gates. Designs such as these are best realized through a macro-based approach. Macro-based designs provide numerous benefits during logic entry and verification, but the ability to reuse intellectual property is often the most significant benefit. From generic serial ports to complex memory controllers and processor cores, each SOC generally requires the use of common macros.

[0005] Many single chip solutions used in applications today are designed as custom chips, each with their own internal architecture. Logical units within such a chip are often difficult to extract and reuse in different applications. As a result, many times the same function is redesigned from one application to another. Promoting reuse by ensuring macro interconnectivity is accomplished by using common buses for inter-macro communications. To that end, the IBM CoreConnect architecture, for example, provides three buses for interconnecting cores, library macros, and custom logic. These buses are the Processor Local Bus (PLB), On-chip Peripheral Bus (OPB) and Device Control Register (DCR) Bus. Other chip vendors may have similar SOC core architectures, for example the Advanced Microcontroller Bus Architecture (AMBA) commercially available from ARM Ltd.

[0006] FIG. 1 illustrates how the prior art CoreConnect architecture is used to interconnect macros in the PowerPC 405 GP embedded controller. High-performance, high bandwidth blocks such as the Power PC 405 CPU core, PCI bridge and SDRAM controller reside on the PLB 102, while the OPB 101 hosts lower data rate peripherals. The daisy chain DCR bus 104 provides a relatively low-speed data path for passing configuration and status information between the PowerPC 405 CPU core and other on-chip macros. A PLB Arbiter 103 would handle contention between devices on PLB 102.

[0007] The CoreConnect architecture shares many similarities with other advanced bus architecture in that they both support data widths of 32 bits and higher, utilize separate read and write data paths and allow multiple masters. For example, the CoreConnect architecture and AMBA 2.0 now both provide high-performance features including pipelining, split transactions and burst transfers. Many custom designs utilizing the high-performance features of the CoreConnect architecture are available in the marketplace today.

[0008] The PLB and OPB buses provide the primary means of data flow among macro elements. Because these two buses have different structures and controls, individual macros are designed to interface to either the PLB or the OPB. Usually the PLB interconnects high bandwidth devices such as processor cores, external memory interfaces and DMA controllers. The PLB addresses the high-performance, low latency and design flexibility issues needed in the highly integrated SOC.

[0009] In any SOC design, the utilization of the on-chip bus structure is an important consideration. Efficient use of the bus produces better system throughput and response maps to real-time applications. It is therefore essential to architect means by which certain devices attached to the bus do not load or dominate the bus. The PLB has such a means designed into the architecture. This mechanism consists of logic designed into the bus masters to perform long variable-length burst transfers. Each master that attempts long burst transfers is required to monitor a signal, PLB_pendReq (PLB pending request). PLB_pendReq is signaled during long burst transfers which indicates if other master requests are active. Masters implement a programable latency timer such that once their burst transfer has begun on the data bus their timer starts counting down from the program value. When the latency timer reaches zero (times out), the master begins to sample the PLB_pendReq signal. If the PLB_pendReq signal is inactive, it indicates no other masters are requesting use of the bus and bursting may continue as long as PLB_pendReq remains inactive. If the latency timer has timed out and the PLB_pendReq is active, the bursting master must sample priority signals (e.g., PLB_pendPri(0:1)) to determine the relative request priority of other master(s) with the requests which are active. If a pending request priority of another master which is requesting the bus is equal to or greater than that of the bursting master, the bursting master must immediately terminate its burst transfer thereby allowing the pending master access to the bus.

[0010] In the above example, the PLB has two separate and completely independent data buses and burst control signals which allows for read and write data transfers to be performed simultaneously. Thus a condition may exist where, for example, a long read burst transfer is in progress and a higher priority write request is generated. Even though the write request would not affect the read transfer in any way, because it only needs access to the address and controls of the write data bus, the higher priority write request will cause a read bursting master to unnecessarily terminate its transfer if its latency timer has timed out. Thus the read master would have to again request the use of the read bus and arbitrate amongst the current pending requests. This has a negative effect on the overall system performance.

[0011] Therefore, there exists a need for a solution to the problem of interrupting a process on a bus because a higher priority process seeks access, especially in the case where those operations are read and write burst operations.

[0012] The present invention discloses a method and apparatus for managing a bus system with independent read and write buses. The internal bus structure, connecting high speed units internal to a microprocessor, usually has separate read and write buses. These buses are controlled by a master or arbiter that determines which device has control of the bus at a particular time. Different devices are assigned levels of priority which indicate their service priority in the case of bus contention. In the prior art, if a device was using the bus, for example a burst read or write, the device controlled the bus for the length of time indicated by its priority and the status of its latency timer. If it was a high priority device and another device of lower priority requested the bus, the lower priority device was placed in a queue dependent on its service priority.

[0013] The present invention separates the pending bus request signals, latency timers, and the pending bus priority signal for a read and a write operation. In embodiments of the present invention, a high priority device is granted a read request while the write bus may be granted to another device with a lower read request but a higher priority write request. The embodiments of the present invention allow bursting reads and writes to remain operational by a low priority device when a higher priority device requests the corresponding other bus operation.

[0014] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.

[0015] For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0016] FIG. 1 is a detailed block diagram of the interconnect macros in the prior art Power PC 405GP embedded controller;

[0017] FIG. 2 is a simplified diagram of the interconnect macros on the Processor Local Bus (PLB) and the On-Chip Peripheral Bus (OPB) illustrating independent PLB read and write buses;

[0018] FIG. 3 is an illustration of a prior art read/write bus;

[0019] FIG. 4 is an illustration of dual operation of independent read write buses;

[0020] FIG. 5 is a flow diagram of steps employed in embodiments of the present invention;

[0021] FIG. 6 is a data processing system configured in accordance with of the present invention; and

[0022] FIG. 7 is a flow diagram illustrating method steps in embodiments of the present invention.

[0023] In the following description, numerous specific details are set forth such as specific word or byte lengths, etc. to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known circuits have been shown in block diagram form in order not to obscure the present invention in unnecessary detail. For the most part, details concerning timing considerations and the like may have been omitted in as much as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art.

[0024] Refer now to the drawings wherein depicted elements are not necessarily shown to scale and wherein like or similar elements are designated by the same reference numeral through the several views.

[0025] The present invention solves the problem of unnecessarily terminating a burst transfer on one (e.g., read) data bus when higher priority requests are made for the other (e.g., write) data bus. Embodiments of the present invention allow burst read and write transfers to operate on one bus unaffected by requests made to the other data bus thereby producing a better overall system throughput.

[0026] Embodiments of the present invention add signals to the signals typically used in the control of a bus, for example the PLB architecture. The description of embodiments of the present invention will use elements of the IBM CoreConnect architecture with the understanding that other similar architectures may correspondingly employ embodiments of the present invention.

[0027] FIG. 2 illustrates the prior art IBM CoreConnect architecture with Processor Local Bus (PLB) 202 and On-Chip Peripheral Bus (OPB) 207 connected via a Bus Bridge 206. The PLB 202 is the high speed bus and typically comprises a separate read bus 203, write bus 204 and PLB Arbiter 205. PLB Arbiter 205 would handle contention for the buses by exemplary devices, the system core, the Processor core, etc. Address and transfer qualifiers used in bus communication are coupled on lines 208.

[0028] FIG. 3 is a more detailed illustration of prior art read write bus 303 coupled to an exemplary device 307 via a read/write bus 301. Arbiter 305 would handle contention for bus 303 by device 307 and other devices (not shown). Bus signals 302 are separated into a request, read/write, priority, and read and write data signals. In this prior art illustration, a device requests the bus and is granted access to either the read or write facilities. Contending devices (not shown) would have a combined priority for both a read and a write operation. Bus Bridge 306 would connect the bus 303 to other buses. Address and transfer qualifiers (request, read or write, priority, etc.) are coupled on 308.

[0029] FIG. 4 is an illustration of embodiments of the present invention where a bus 400 is shown to have independent read bus 403 and write bus 404. A device 407 is coupled to the read bus 403 using its read bus 402 and write bus 404 using its write bus 401. Arbitration between contending device 407 and other devices (not shown) would be handled by Arbiter 405 and bus 400 would be connected to other buses via bus bridge 406. Write bus data 409 also comprises independent write priority and write request signals. Likewise read bus data 408 comprises independent read priority and read request signals. The independent read and write priority and request signals from device 407 and other devices (not shown) communicating on bus 400 would be coupled to Arbiter 405. Arbiter 405 would also comprise, in embodiments of the present invention, independent latency counters for both the read bus 403 and the write bus 404. The latency counters are started at the beginning of a read or a write operation and are used to determine how much time will be dedicated to an in process operation before the exemplary Arbiter 405 samples pending requests to determine if higher priority requests are pending. Bus masters (not shown) are circuits within each device that manage bus accesses for the device. The bus master for device 407, for example, would present to the exemplary Arbiter 405 its independent read and write requests and access priority for each. Address and transfer qualifiers (request, read/write, priority, etc.) are communicated on bus 411. Other bus masters (not shown) would be incorporated in other devices (not shown) that communicate on bus 400.

[0030] In another embodiment of the present invention, a bus master (e.g., Master 410 in a device 407) resides in each device communicating on a bus: In this embodiment each bus master 410 initiates its a read or a write request which is arbitrated by arbiter 405 amongst other devices (not shown) seeking access to bus 400. If bus master 410 wins the bus arbitration, the arbiter 405 broadcasts the read or write to the “slaves” (other devices receiving data and not having a higher priority for the requested operation). A slave will acknowledge the read or write addresses. The master 410, in this embodiment, has its own latency timers and samples read and write pending request and priority signals. The master would then start the granted request (read, write, or both) and start a latency counter(s) (read, write or both) and increment the counter(s) on each data transfer. The master 410 would continue the data transfer monitoring its latency counter(s) and only sampling pending requests and their priority when a latency counter times out. After a latency timer times out, the master determines whether to continue its active data transfers or relinquish the bus (read, write, or both) to a device with a higher priority request pending. The master 407 or other masters (not shown) use their read and write latency timers along with sampling pending requests and priorities to perform reads, writes, or both reads and writes separately or simultaneously over exemplary bus 400. In this manner the latencies of read and write data transfers are independently controlled and requests for idle data busses do not preempt active burst data transfers.

[0031] Using the exemplary PLB architecture, the pending request signal, PLB_pendReq, is separated into two signals, pending read request (PLB_rdpendReq) and pending write request (PLB_wrpendReq). When the PLB_rdpendReq signal is true, a master on the bus has a read request active and likewise when PLB_wrpendReq is active a master on the bus has a write request active. An exemplary priority level signal, PLB_pendPri(0:1), is also separated into two different signals PLB_rdpendPri(0:1) (pending PLB read priority level 0:1) and PLB_wrpendPri(0:1) (pending PLB write priority level 0:1). In cases where exemplary priority level signal PLB_pendPri(0:1) was the highest priority pending request, PLB_rdpendPri(0:1) and PLB_wrpendPri(0:1) likewise become the highest priority of all pending read and write requests respectively. Each master on the PLB bus will monitor only the appropriate pending request and priority signals for the type of transfer that it is performing. Thus when a master is performing a long burst read transfer, for example, it will monitor PLB_rdpendReq only after its latency timer times out. If a high priority write request becomes active, then only the PLB_wrpendReq signal will become active. Thus the long read burst will continue unaffected by the write request, which can transparently gain control of the write data bus. If a high priority read request becomes active, the PLB_rdpendReq signal would become active and the master will compare its in process read priority to the PLB_rdpendPri(0:1) signals. If the read pending priority is equal to or greater than the priority of the in process read bursting master, it will terminate the burst to allow the high priority read access to the read data bus. The same operation holds true if read and write transfers are reversed in the preceding example. Further a master which performs long burst reads and long burst writes can actually do both simultaneously because of the independent data buses. The master would have two independent latency timers, one for the read and one for the write data bus. In such an implementation, a master could initiate a read burst and then a write bust transfer and independently monitor pending requests and pending priorities for each data bus. In such an arrangement, the master would only terminate one of the burst transfers for a specific higher priority request, while the other burst continues uninterrupted.

[0032] FIG. 5 is a flow diagram illustrating method steps in embodiments of the present invention. In step 501 the master request signals are sampled and the master processes the highest priority requests. If a request is pending, it is either a read, a write, or possibly a read and a write request in step 502. If the request is a read, then a determination is made in step 504 as to whether the read bus is busy. If the read bus is not busy in step 504, then access to the read bus is granted in step 505 and a read bus latency counter is started in step 509 and a return to step 501 is executed in step 513 awaiting new requests. If the read bus is busy in step 504 then the read latency counter is tested in step 508. If the read latency counter has not timed out, then a wait is executed by a return to step 508. Once the read latency timer has timed out in step 508, then the pending read request priority signals are sampled in step 511. If the pending request is a higher priority in step 514, then the in process read is terminated in step 519 and read bus access is granted to the pending request in step 521 and a return to step 501 is executed in step 526 awaiting new read or write request signals. If the pending read request is not a higher priority in step 514 then the in process read is continued in step 518 and a return is executed to step 501 in step 523.

[0033] In step 501, if a write request has been received then step 503 is executed and a determination is made whether the write bus is busy. If the write bus is busy in step 503, then the write latency timer is tested in step 507. If the write latency timer has not timed out, a wait is issued by a return to step 507. If the write latency timer has timed out in step 507, then the write pending request priority signals are sampled in step 510. The pending write request priority is tested in step 516. If the pending write request is a higher priority, then the active write operation is terminated in step 520 and the higher priority write request is granted in step 522 and a return to step 501 is executed in step 525. If the pending write request is not a higher priority in step 516, then the in process write operation is continued in step 517 and a return to step 501 is executed in step 525. In step 503, if the write bus is not busy the write bus access is granted in step 506. The write latency counter is started in step 512 and a return to step 501 is issued in step 515 when the latency counter times out.

[0034] FIG. 7 is a flow diagram of operations initiated by a master according to embodiments of the present invention. In step 701, a master initiates a read or write.(referred to hereafter in FIG. 7 as just a request). Typically the master may only assert either a read or write request at any one time. Once the first request is address acknowledged, the second request may be activated. If the second request is concurrently granted then multiple operations will occur concurrently as illustrated by the steps in FIG. 7. In step 702, a test is done to determine if an arbiter has granted the request. If the request is not won, then a return to step 701 is issued and the request remains asserted. If the bus is won for the request in step 702, then the arbiter broadcasts to all slave devices on the bus in step 703. In step 704, a slave acknowledges to the master the requested address. In step 705, the master starts a latency counter and in step 706 begins a transfer counting down the latency counter on each data transfer. In step 707, the latency counter is tested for time out. If a latency counter has not timed out, then data transfer continues. If in step 707 the latency counter has timed out, then the pending priorities are sampled in step 708. If a higher priority exists, then in step 709 the operation is terminated and the particular bus with a higher priority request pending is relinquished. If a higher priority does not exist in step 708, then continue transfers by a branch to step 706. In step 710, a test is made whether the device still has active operations (only a read or a write in an active read and write may have been terminated). If a device has active operations, a branch to step 706 continues remaining operation. If there are no active operations in step 710, then either a branch to 701 is initiated a new request is issued or a wait is initiated for a new request. Once a particular request has be acknowledged a second request may also be acknowledged as stated above. In the case of multiple accepted requests, a parallel read and write operation may occur concurrently each process using the method steps outlined in FIG. 7.

[0035] Referring to FIG. 6, an example is shown of a data processing system 600 which may be used for the invention. The system has a central processing unit (CPU) 610, which is coupled to various other components by system bus 612. Read-only memory (“ROM”) 616 is coupled to the system bus 612 and includes a basic input/output system (“BIOS”) that controls certain basic functions of the data processing system 600. Random access memory (“RAM”) 614, I/O adapter 618, and communications adapter 634 are also coupled to the system bus 612. I/0 adapter 618 may be a small computer system interface (“SCSI”) adapter that communicates with a disk storage device 620. Communications adapter 634 interconnects bus 612 with an outside network enabling the data processing system to communicate with other such systems. Input/Output devices are also connected to system bus 612 via user interface adapter 622 and display adapter 633. Keyboard 624, track ball 623, mouse 623 and speaker 628 are all interconnected to bus 612 via user interface adapter 622. Display monitor 638 is connected to system bus 612 by display adapter 633. In this manner, a user is capable of inputting to the system through the keyboard 624, trackball 632 or mouse 623 and receiving output from the system via speaker 628 and display 638.

[0036] Various buses employed in the data processing system 600 may employ independent read and write buses and as such may employ embodiments of the present invention where contention for the independent read and write buses are handled using independent read and write bus access signals, access priority signals and latency timer signals. In embodiments of the present invention employed in buses of the data processing system of FIG. 6, independent read and write bus access is granted to a higher priority device after a latency timer of an active process (read or write) has timed out. Lower priority read or write requests are placed in a queue and serviced after a higher priority active process (read or write) has completed.

[0037] While embodiments of the present invention are applicable to the IBM CoreConnect architecture, other chip vendors may have similar SOC core architectures, for example Advanced Microcontroller Bus Architecture (AMBA) from ARM Ltd in which embodiments of the present invention are applicable.

[0038] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.