The present invention relates in general to data processing systems, and in particular, to interfacing two buses that may be clocked at different frequencies.
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 have drivers that 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.
The IBM Blue logic core program, for example, provides the framework to efficiently realize complex system-on-a-chip designs. Typically, a 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.
Many single chip solutions used in applications today are designed as custom chips, each with its 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 Advanced Microcontroller Bus Architecture (AMBA) from ARM Ltd.
FIG. 1 illustrates how the prior art CoreConnect architecture is used to interconnect macros and 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 103, while the OPB 102 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 105 would handle contention between devices on PLB 103.
The CoreConnect architecture shares many similarities with other advanced bus architecture in that they 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.
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.
The PLB specification describes a system architecture along with a detailed description of the signals and transactions. PLB based custom logic systems require the use of PLB macro to interconnect their various master and slave macros.
FIG. 1 also illustrates a connection of multiple masters and slaves through the PLB macro. Each PLB master is attached to the PLB macro by separate address, read data and write data buses and a plurality of transfer qualifier signals. PLB slaves are attached to the PLB macro via shared, but decoupled, address, read data and write data buses along with transfer control and status signals for each data bus.
The OPB 102 is a secondary bus architected to alleviate system performance bottlenecks by reducing capacitive loading on the PLB 103. Peripherals suitable for attachment to the OPB include serial ports, parallel ports, Universal Asynchronous Receiver Transmitters (UARTs), timers and other low-bandwidth devices. As part of the IBM Blue Logic cores program, all OPB core peripherals directly attach to OPB. This common design point accelerates the design cycle time by allowing designers to easily integrate complex peripherals into an application specific integrated circuit (ASIC).
PLB masters gain access to the peripherals on the OPB 102 through the OPB Bridge macro. The OPB Bridge acts as a slave device on the PLB and a master on the OPB 102. The OPB Bridge performs dynamic bus sizing, allowing devices with different data path widths to efficiently communicate. When the OPB Bridge master performs an operation wider than the selected OPB slave, the bridge splits the operation into two or more smaller transfers.
As stated, the PLB 103 and OPB 102 buses may operate at different speeds. The PLB 103 handles primarily high speed communication and the OPB 102 lower speed communication. The PLB and OPB may operate with speed multiples of two to one or higher and Interbus communication is handle via the OPB Bridge macro. If the PLB 103 is operating at a higher clock than the OPB 102, a portion of the OPB Bridge would likewise have to operate at the same clock speed even though the transfer to the OPB 102 could only handle lower speed transactions. If the clock speed ratio between a PLB103 and a OPB102 was known in advance, then on certain transactions, the extra clock cycles of the PLB clock may be xe2x80x9csavedxe2x80x9d for other purposes while maintaining an optimum communication between buses, set by the speed of the slower OPB. Clearly there is a need for a method to optimize transactions between two buses operating at different clock speed ratios.
The present invention discloses a method and apparatus for managing data transfers between buses operating at different clock frequencies. A low speed bus communicating with a higher speed bus may cause both buses to operate at a speed determined by the lower speed bus. Embodiments of the present invention disclose a system that allows the higher speed bus to utilize unused clock cycles of its bus clock during data transfers between buses. A ratio circuit determines the ratio of the clock frequencies of communicating buses on a transaction reset. Cycle control data is calculated and used to set a logic state machine coupled to each bus. The logic state machine for the lower speed bus determines selected cycles of the high speed bus clock optimized to the low speed bus clock. These selected cycles are used in data transfers between the high speed bus and the low speed bus. The cycles of the higher speed bus clock not used to transfer data to the lower speed bus may be used in data transfers between devices communicating only on the higher speed bus. In this manner the idle cycles of the higher speed bus may continue to be utilized during inter-bus data transfers. Embodiments of the present invention update the logic state machines on a transaction reset so that communication between buses may be optimized on different bus transactions. The clock ratio detection circuit and the cycle control circuit may be disabled after cycle control data is latched in the logic state machines thus conserving power.
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.
USPTO Backgrounds
USPTO Backgrounds