Apparatus and method for controlling data, address, and enable buses within a microprocessor

Abstract

A CPU includes a common bus, a bus interface unit (BIU), and a plurality of module units. The BIU includes a decode stage, an arbitration stage, and a control stage. Incoming requests asserted by the CPU module unit are provided to the BIU decode stage which, in response thereto, determines the type of transaction requested, the initiator module unit, and the target module unit. If the target identified in the decoded request is ready to accept a command, the decode stage forwards the request to the arbitration stage. The arbitration stage arbritrates amoung the present requests asserted by the module units and, in response thereto, alerts the control stage as to which of the module units has won the arbitration. The control stage decodes the request corresponding to the module unit that won the arbitration to determine the transaction type and target unit. The control stage selects within appropriate address and data multiplexers those inputs corresponding to the initiator and target units identified in the request. In this manner, the dedicated buses between the initiator unit and the BIU are effectively coupled to the common bus so as to allow for the transmission of information from the initiator unit to the target unit via the BIU.

Description

BACKGROUND

1. Field of Invention

This invention relates generally to a central processing unit of a microprocessor and specifically to a bus system within such a central processing unit.

2. Description of Related Art

In a typical microprocessor based computer system, module units within the central processing unit (CPU) such as, for instance, instruction caches, data caches, a DRAM memory controller, a Peripheral Component Interconnect (PCI) interface unit, and so on, communicate with one another via a common bus. Typically, each of the module units communicates with the common bus through a tri-state I/O driver which, in turn, is controlled by a central bus controller. Since the common bus handles only one transaction at a time, a bus control system is necessary to arbitrate control of the common bus to the module units in a manner which optimizes CPU performance. See, for instance, U.S. Pat. No. 5,590,380 to Yamada et al and U.S. Pat. No. 5,528,767 to Chen. In some bus control and arbitration systems, bus control is granted to a particular module unit until the present transaction is completed. In other systems, bus control is granted for a predetermined period of time, regardless of whether the present transaction is completed. Most conventional bus control and arbitration systems have an interrupt feature whereby bus control is immediately granted to a specific unit such as, for instance, the memory controller when it is desired to receive streamline audio video information from an external source, e.g., the Internet.

Unfortunately, conventional bus control and arbitration systems undesirably limit CPU performance. For instance, the transmission and reception of data to and from each module unit during a transaction is controlled by the tri-state I/O drivers within the module units. The tri-state drivers, in turn, are controlled by the central bus controller. Thus, when a transaction requires data and control signals to be sent back and forth between two module units, the tri-state drivers within these two module units must first alert the central bus controller which, in response thereto, provides control signals back to the tri-state drivers. This command hierarchy consumes an undesirable amount of time and, therefore, undesirably limits CPU performance. In addition, the time required to switch the tri-state drivers between states consumes time and, thus, further limits CPU performance. CPU performance is further limited by the time required to arbitrate among present transaction requests.

SUMMARY

A bus system is disclosed herein which overcomes problems in the prior art discussed above. In accordance with the present invention, a CPU of a microprocessor includes a common bus, a bus interface unit (BIU), and a plurality of module units. The BIU has a plurality of first ports coupled to respective first ports of the module units via dedicated buses therebetween and has a second port coupled to a first port of the common bus. The module units each include a second port coupled to respective second ports of the common bus. Communication between the module units is routed through and controlled by the BIU. To request a transaction, a module unit (the initiator) sends a request to the BIU via its dedicated bus to the BIU. The BIU arbitrates among present requests and, in response thereto, grants the arbitration winner's request and transmits a command to the target of the requested transaction. Both of these signals are transmitted via the dedicated buses. Thereafter, data is routed from the initiator unit to the BIU via a corresponding dedicated bus. The BIU then routes the data to the target unit via the common bus.

In preferred embodiments, the BIU includes a decode stage, an arbitration stage, and a control stage. Incoming requests are provided to the BIU decode stage which, in response thereto, determines the type of transaction requested, the initiator module unit, and the target module unit. If the target unit identified in a decoded request is ready to accept a command, the decode stage forwards the request to the arbitration stage. A state machine within the arbitration stage arbritrates amoung the present requests asserted by the module units and, in response thereto, alerts the control stage as to which of the initiating module units has won the arbitration. The control stage decodes the request corresponding to the module unit that won the arbitration to determine the transaction type and target unit. Thereafter, the control stage selects within appropriate multiplexers those inputs corresponding to the initiator and target units identified in the request. In this manner, the dedicated buses between the initiator unit and the BIU are effectively coupled to the common bus so as to allow for the transmission of information from the initiator unit to the target unit via the BIU.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a central processing unit (CPU) including a bus system in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram illustrating one embodiment of a bus interface unit and its connections to module units within the CPU according to the embodiment of FIG. 1;

FIG. 3 is a flow chart illustrating a predetermined arbitration sequence according to an embodiment of the present invention;

FIG. 4 depicts a state machine according to an embodiment of the bus interface unit of FIG. 2;

FIG. 5 is a block diagram illustrating address, data, and byte enable data paths employed by the bus interface unit of FIG. 2;

FIGS. 6A-6D are timing diagrams of various signals during Read Begin, Read End, Write Begin burst mode, and Write Begin non-burst mode transactions, respectively, used by the bus interface unit of FIG. 2; and

FIG. 7 is a block diagram illustrating address multiplexing according to one embodiment of the bus interface unit of FIG. 2.

Like reference numerals refer to corresponding parts throughout the drawing figures.

DETAILED DESCRIPTION

Embodiments of the present invention are discussed below in the context of a central processing unit (CPU) 10 within a host microprocessor used, for instance, in a personal computer. Referring to FIG. 1, a CPU 10 constructed in accordance with the present invention includes a bus interface unit (BIU) 11, a first instruction cache unit (ICU0) 12, a first load-store unit (LSUO) 13, a data cache unit (DCU) 14, a second load store unit (LSU1) 15, a second instruction cache unit (ICUL) 16, a geometric decompressor unit (GDC) 17, a peripheral component interconnect (PCI) unit 18, a high speed packet (HSP) protocol unit 19, and an RDRAM control unit (RCU) 20.

The BIU 11 sends address, data, and byte enable signals to module units 12-20 within the CPU 10 via a common address bus 22, a common data bus 23, and a common byte enable bus 24, respectively, collectively shown in FIG. 1 as bus 25. Dedicated buses 12a-20a allow information to be transmitted from respective module units 12-20 directly to the BIU 11 and, conversely, dedicated buses 12b-20b allow information to be transmitted from the BIU 11 directly to each of the respective module units 12-20.

In other embodiments, bidirectional dedicated buses may replace unidirectional buses 12a-20a and 12b-20b. The instruction caches 12 and 16, the load-store units 13 and 15, and the data cache 14 are well known in the art. The PCI unit 18 interfaces between the CPU 10 and a PCI bus of the host microprocessor in a well known manner. The HSP protocol unit 19 interfaces between the CPU 10 and an HSP port (not shown) of the host microprocessor in a known manner. The RCU 20 is of conventional design and interfaces between the CPU 10 and an SDRAM memory (not shown) of the host microprocessor in a well known manner. The PCI unit 18, the HSP unit 19, and the RCU 20 are shared resources which are mapped into CPU memory. Although not shown in FIG. 1, the CPU 10 may include other suitable module units such as, for instance, arithmetic logic units (ALU), multipliers, and so on.

During operation of the host microprocessor, module units 12-20 within the CPU 10 require access to the common address, data, and byte enable buses 22-24 in order to communicate with one another and/or CPU peripheral devices, e.g., the SDRAM memory or the PCI bus. One of units 12-20 requests access to the common buses 22-24 by sending a request signal X.sub.-- BIU.sub.-- REQ to the BIU 11 via its dedicated bus, i.e., buses 12a-20a, where X is the initiator of the request. Some requests are accompanied by a byte enable signal, as explained below. The request identifies the type of transaction requested as well as the respective addresses of the initiator and target units. Requests received by the BIU 11 are decoded to determine the target and transaction type and then gated with a ready signal from the target unit, i.e., Y.sub.-- BIU.sub.-- BRDY, where Y is the target unit.

If the target is ready to accept a command, as indicated by its ready signal provided to the BIU 11, the request is arbitrated among existing requests according to a two level priority scheme. In a preferred embodiment, the first level includes only the RCU 20, and the second level, which is of lower priority than the first level, includes a round robin rotation of units 12-19. A grant is sent to the unit that "wins" the arbitration. The grant is sent as signal BIU.sub.-- X.sub.-- GNT via the appropriate dedicated bus. The BIU 11 also sends a command signal to the target, i.e., BIU.sub.-- Y.sub.-- CMD, thereby alerting the target as to the forthcoming transaction. The command signal is preferably transmitted from the BIU 11 to the target unit via the appropriate dedicated bus. The BIU 11 also enables the appropriate common buses 22-24 and selects appropriate address multiplexers associated therewith to facilitate communication between the initiator and target units.

A preferred embodiment is described below with reference to FIGS. 1-7. As mentioned above, the module units 12-20 are directly connected with the BIU 11 via respective dedicated buses 12a-20a, and are selectively connected to the common address bus 22, the common data bus 23, and the common byte enable bus 24 via address, data, and byte enable ports, respectively, associated with the units 12-20. Specifically, each of the dedicated buses 12a-20a allows for its corresponding module unit to communicate address, data, and transaction-related signals to the BIU 11. The transaction related signals include, for instance, requests, data valid signals, commands, byte enable signals, and ready signals. For instance, when requiring access to one of the common buses 22-24, the initiating unit requests a transaction by asserting a request to the BIU 11, i.e., X.sub.-- BIU.sub.-- REQ. Here, the BIU 11 monitors ready signals (Y.sub.-- BIU.sub.-- BRDY) from each of the units 12-20, where the ready signals indicate whether each of units 12-20 is ready to proceed with a requested transaction.

Referring now to FIG. 2, the request from the initiator, X.sub.-- BIU.sub.-- REQ, is received at an input terminal of the BIU 11 and provided to the decode stage 11a. The request is decoded to identify the initiator and target units, and to determine the transaction type requested. In some embodiments, the request includes four fields: TAG, TARGET, TYPE, and BURST, where the TAG field includes special information relating to the requested transaction, e.g., a cache miss, the TARGET field identifies the initiator and target units, the TYPE field identifies the requested transaction type, e.g., Read Begin, Read End, or Write Begin, and the BURST field indicates whether data transfer is burst mode (32 bytes) or non-burst mode (8 bytes). In preferred embodiments, the TYPE field is a two bit field indicating which of the common buses 22-24 are required for the requested transaction.

For instance, most Read Begin transactions require only the common address bus 22, Read End transactions require only the common data bus 23, and most Write Begin transactions require both the common address 22 and data 23 buses. Read Begin and Write Begin transaction initiated by the PCI 18 or either of the LSUs 13 or 15 also require the byte enable bus 24. Once decoded, the request (X.sub.-- BIU.sub.-- REQ) is gated with the ready signal from the target unit (Y.sub.-- BIU.sub.-- BRDY). If signal Y.sub.-- BIU.sub.-- BRDY is active, thereby indicating that the target is ready to receive a command, the decoded request is forwarded to the arbitration stage 11b. In preferred embodiments, the request and target-ready signals are latched outputs from the initiator and targets units, respectively.

The arbitration stage 11b includes an Arbitration State Machine ASM which arbitrates among present requests and grants a winning request on each clock cycle. The ASM is preferably clocked by the CPU clock and utilizes a two-level priority hierarchy where, as mentioned above, the RCU 20 is assigned to level 0 and the remaining units 12-19 are assigned to level 1, where level 0 is of higher priority than level 0. The RCU 20 is given priority over remaining units 12-19 in order to eliminate access delays when retrieving information from computer memory, e.g., SDRAM. If the RCU 20 has not made a request to the BIU 11, the ASM polls the units 12-19 according to a predetermined sequence. An address indicative of the initiator of the winning request is stored within a latch D1 in the arbitration stage 11b, and also forwarded to the control stage 11c as a pre-grant signal PRE.sub.-- GNT. On the next arbitration which reaches level 1 priority, the ASM again polls units 12-19, beginning with the module unit following, in the predetermined sequence of polling, the previous arbitration winner (the address of which, as mentioned above, is stored in latch D1).

FIG. 3 illustrates one example of the above described two-level priority scheme, where the polling sequence of the level 1 module units, i.e., units 12-19, is LSU1.fwdarw.ICUO.fwdarw.ICU1.fwdarw.GDC.fwdarw.DCU.fwdarw.HSP.fwdarw.22 PCI.fwdarw.LSUO, as indicated in the first column of the flow chart in FIG. 3. Thus, when the decoded request from the decode stage 11a is forwarded to the arbitration stage 11b, the ASM first determines whether there is present request from the RCU 20. If there is, the ASM provides an RCU pre-grant signal, i.e., PRE.sub.-- BIU.sub.-- RCU.sub.-- GNT, to the control stage 11c. If, on the other hand, there is presently not a request from the RCU 20, request arbitration begins in a round-robin fashion according to the predetermined level 1 sequence shown, for instance, in FIG. 3. As used herein, round-robin refers to a predetermined rotating sequence of values corresponding to the module units 12-20.

As mentioned above, the unit address stored in the latch D1 determines at which point in the predetermined sequence the ASM begins polling. For instance, if the BIU 11 issued a grant to the LSU0 13 on the previous clock cycle, present arbitration polling begins with the next unit in the sequence, i.e., the LSU1 15, as indicated in the first column of the flow chart in FIG. 3. Here, if the LSU1 15 is the initiator of the decoded request received from the decode stage 11a, arbitration is awarded to the LSU1 15 and, in response thereto, an LSU1 pre-grant signal, i.e., PRE.sub.-- BIU.sub.-- LSU1.sub.-- GNT, is provided to the control stage 11c and, as mentioned above, the unit address of the LSU1 15 is stored in the latch D1. If, on the other hand, the decoded request is not initiated by the LSU1 15, the next unit in the sequence is polled, i.e., the ICUO 12. This sequential polling of units 12-20 continues until all units 12-20 are polled. Thereafter, if a match is not found, i.e., there are no requests present, the ASM assumes a default value indicative of the RCU 20 and, in response thereto, grants access of the common buses to the RCU 20 by asserting PRE.sub.-- BIU.sub.-- RCU.sub.-- GNT.

The pre-grant signal (PRE.sub.-- GNT) asserted by the arbitration stage 11b is received in the control stage 11c. In a preferred embodiment, the control stage 11c includes a Control State Machine CSM having six states as illustrated, for instance, in FIG. 4: Check New Transaction, Read Begin, Read End, Write Begin, Data Present, and Data Not Present. The CSM is preferably clocked by the CPU clock.

The CSM is initially in the Check New Transaction state, during which the CSM awaits a pre-grant signal from the arbitration stage 11b. The CSM decodes the request corresponding to the received pre-grant signal and determines the transaction type, the initiator unit, and the target unit. The CSM then transitions to the state which corresponds to the decoded transaction type, i.e., either the Read Begin state, the Read End state, or the Write Begin state.

When in the Read Begin state, the CMS asserts a grant BIU.sub.-- X.sub.-- GNT to the initiator unit, a command BIU.sub.-- Y.sub.-- CMD to the target unit, and facilitates the transmission of an address from the initiator unit to the target unit via the BIU 11.

When in either the Read End state or the Write Begin state, the CSM asserts a grant BIU.sub.-- X.sub.-- GNT to the initiator unit, a command BIU.sub.-- Y.sub.-- CMD to the target unit, and a data valid signal BIU.sub.-- Y.sub.-- DVALID to the target unit. Thereafter, the CSM awaits a data valid signal X.sub.-- BIU.sub.-- DVALID from the initiator unit. If this data valid signal is asserted, i.e., X.sub.-- BIU.sub.-- DVALID, the CSM transitions to the Data Present State and thereafter routes data from the initiator unit to the target unit via the BIU 11. If, on the other hand, this data valid signal is not asserted, i.e., X.sub.-- BIU.sub.-- DVALID, the CSM transitions to the Data Not Present state and awaits a data valid signal from the initiator unit. The states of the CSM are discussed in detail below.

Check New Transaction State

Initially, the CSM is in the Check New Transaction state, wherein the signal received from the arbitration stage 11b, PRE.sub.-- BIU.sub.-- X.sub.-- GNT, is decoded to determine the initiator. The request signal corresponding to the initiator, X.sub.-- BIU.sub.-- REQ, is latched from the appropriate one of buses 12a-20a into the control stage 11c. As mentioned above, this request is decoded to determine the initiator, the target, and the transaction type. In response thereto, the CSM latches address (ADDR), data (DATA), and/or byte enable signals (BENABLE) from the initiator unit. In some embodiments, the address, data, and byte enable signals received from the winning initiator are latched into a plurality of conventional D-type flip flops, as shown for instance in FIG. 5. Preferably, incoming data is latched using the data valid signal from the initiator (X.sub.-- BIU.sub.-- DVALID) as a strobe. The CSM then transitions to the state which corresponds to the transaction type requested, i.e., either the Read Begin, Read End, or Write Begin state. If no requests have been asserted, a grant to the RCU 20 is asserted, i.e., PRE.sub.-- BIU.sub.-- RCU.sub.-- GNT, and the CSM remains in the Check New Transaction state.

Read Begin State

The Read Begin state is described with reference to the timing diagram of FIG. 6A. As mentioned above and shown in FIG. 6A, during the Check New Transaction state, the initiator unit provides a request X.sub.-- BIU.sub.-- REQ and an address X.sub.-- BIU.sub.-- ADDR to the BIU 11 between t.sub.0 and t.sub.5. Once in the Read Begin state, the CSM issues a grant to the initiator unit (BIU.sub.-- X.sub.-- GNT) and a command to the target unit (BIU.sub.-- Y.sub.-- CMD) for one clock cycle at t.sub.4. These signals are preferably transmitted to the initiator and target units using appropriate dedicated buses 12b-20b, as illustrated in FIG. 2. The address provided by the initiator unit (X.sub.-- BIU.sub.-- ADDR), which was latched within the BIU 11 during the previous CSM state, is also forwarded to the common address bus 22 as signal BIU.sub.-- ADDR and thereafter latched within the target unit at t.sub.4. On the following clock cycle, the CSM returns to the Check New Transaction state and awaits a new pre-grant from the arbitration stage 11b.

As mentioned above, where the PCI 18 or either of the LSUs 13 or 15 initiate a Read Begin transaction, a byte enable signal X.sub.-- BIU.sub.-- BENABLE is transmitted to the BIU 11 via the appropriate dedicated bus 12a-20a between t.sub.0 and t.sub.5. The byte enable signal specifies which byte(s) within the addressed line the initiator desires. In this case, the CSM forwards the byte enable information BIU.sub.-- BENABLE to the target via the common byte enable bus 24 at t.sub.4.

Read End State

The Read End state is described with reference to the timing diagram of FIG. 6B. As mentioned above and shown in FIG. 6B, during the Check New Transaction state, the initiator unit provides a request X.sub.-- BIU.sub.-- REQ to the BIU 11 between t.sub.0 and t.sub.4 and provides a first data signal X.sub.-- BIU.sub.-- DVALID and first data X.sub.-- BIU.sub.-- DATA to the BIU 11 at t.sub.3. Once in the Read End state, the CSM issues a grant to the initiator unit (BIU.sub.-- X.sub.-- GNT), a command to the target unit(BIU.sub.-- Y.sub.-- CMD), and a data valid signal to the target unit (BIU.sub.-- Y.sub.-- DVALID) for one clock cycle at t.sub.3. The first data provided by the initiator (X.sub.-- BIU.sub.-- DATA), which was latched within the BIU 11 during the previous CSM state, is forwarded to the common data bus 23 as signal BIU.sub.-- DATA and thereafter latched within the target unit at t.sub.4. For a non-burst transaction, the transaction is considered over and the CSM returns to the Check New Transaction state and awaits the next pre-grant from the arbitration stage 11b. If, on the other hand, the X.sub.-- BIU.sub.-- DVALID signal is asserted, the CMS transitions to the Data Present state, a description of which is provided below.

In the event that the transaction involves a cache miss, i.e., where the RCU 20 is requesting a Read End transaction, the ready lines of both the DCU 14 and the initiating LSU (i.e., DCU.sub.-- BIU.sub.-- BRDY and LSUn.sub.-- BIU.sub.-- BRDY) are checked before the RCU request is granted. Here, if both the DCU 14 and the initiating LSUn units are ready, the grant (BIU.sub.-- RCU.sub.-- GNT) is asserted. Data valid signals are transmitted to the DCU 14 and the appropriate LSUn (BIU.sub.-- Y.sub.-- DVALID) contemporaneously with the assertion of the command signal (BIU.sub.-- Y.sub.-- CMD) to the target. Thereafter, the data valid signal from the initiator (X.sub.-- BIU.sub.-- DVALID) is monitored to determine if the initiator is sending additional data bytes. If so, the CSM transitions to the Data Present state. Otherwise, the CSM transitions to the Data Not Present state.

Write Begin State

The Write Begin state is described with reference to the timing diagrams of FIGS. 6C and 6D. As mentioned above and shown in FIGS. 6C and 6D, during the Check New Transaction state, the initiator unit provides a request X.sub.-- BIU.sub.-- REQ and an address X.sub.-- BIU.sub.-- ADDR to the BIU 11 between t.sub.0 and t.sub.4 and begins providing data X.sub.-- BIU.sub.-- DATA to the BIU 11 between t.sub.0 and t.sub.1. Once in the Write Begin state, the CSM asserts a grant (BIU.sub.-- X.sub.-- GNT) to the initiator unit, and asserts the command (BIU.sub.-- Y.sub.-- CMD) and data valid signal (BIU.sub.-- Y.sub.-- DVALID) to the target unit at t.sub.3, as described above. The BIU 11 also routes the address (BIU.sub.-- ADDR) from the initiator to the common address bus 22 (and thereafter to the target unit) at t.sub.3. If the data valid signal from the initiator (X.sub.-- BIU.sub.-- DVALID) is asserted, the CSM transitions to the Data Present State (FIG. 6C). Otherwise, the CSM transitions to the Data Not Present State. In the case of a non-burst transaction, the transaction is considered completed (FIG. 6D), and the CSM transitions to the Check New Transaction state and thereby awaits the next pre-grant signal from the arbitration stage 11b.

As mentioned above, if the PCI 18 or either of the LSUs 13 and 15 request a Write Begin, the initiator sends a byte enable signal to the BIU via the appropriate dedicated bus 12a-20a. Thereafter, the BIU 11 forwards the byte enable signal to the target via the common byte enable bus 24.

If the either of the LSUs initiates a Write Begin, it sends one data byte to either the RCU 20 or the PCI 18 via the BIU 11 in the manner described above. Thereafter, the CSM transitions to the Check New Transaction state. When the DCU 14 requests a Write Begin transaction, the ready lines of the RCU 20 and both ICUs 12 and 16 (i.e., RCU.sub.-- BIU.sub.-- BRDY, ICUO.sub.-- BIU.sub.-- BRDY, and ICUL.sub.-- BIU.sub.-- BRDY) must be asserted before the grant signal (BIU.sub.-- DCU.sub.-- GNT) is asserted by the BIU 11.

Data Present State

As mentioned above, the Data Present state is reached only if the data valid signal from the initiator (X.sub.-- BIU.sub.-- DVALID) is asserted during the previous state. Once in the Data Present state, the data valid signal to the target (BIU.sub.-- Y.sub.-- DVALID) is asserted for one clock cycle, thereby allowing data on the common data bus 23 to be latched into the target unit. This event corresponds with t.sub.3 in FIG. 6B for Read End transactions and with t.sub.3 in FIGS. 6C and 6D for Write Begin transactions. The data valid signal from the initiator is checked on the following clock cycle and, if asserted, the CSM remains in the Data Present State and the next data is forwarded to the common data bus (BIU.sub.-- DATA). This event corresponds with t.sub.4 in FIG. 6B for Read End transactions and t.sub.4 in FIG. 6C for a burst mode Write Begin transaction. Otherwise, the CSM transitions to the Data Not Present state.

A count of the data valid signal from the initiator (X.sub.-- BIU.sub.-- DVALID) is maintained within the BIU 11. When this count reaches a predetermined value, which in a preferred embodiments is three, the CSM transitions to the Check New Transaction state. When the DCU 14 requests a Write Begin transaction, the RCU 20 and both ICUs 12 and 16 receive data valid signals.

Data Not Present State

As noted above, the Data Not Present state is reached only if X.sub.-- BIU.sub.-- DVALID is deasserted during the Data Present state. Here, the data valid signal to target (BIU.sub.-- Y.sub.-- DVALID) is deasserted for one clock cycle, thereby informing the target that data is not presently available on the common data bus 23. The data valid signal from the initiator (X.sub.-- BIU.sub.-- DVALID) is monitored and, if re-asserted, the CSM transitions to the Data Present state. Otherwise, the CSM remains in the Data Not Present state.

Present embodiments may be better understood in light of an example request where, for instance, the LSUO 13 requests data from the RCU 20. Here, the LSUO 13 asserts a request to the BIU 11 as signal LSUO.sub.-- BIU.sub.-- REQ via bus 13a. The LSUO 13 also sends a byte enable signal (LSUO.sub.-- BIU.sub.-- BENABLE) to the BIU via bus 13a. The request is decoded in the decode stage 11a of the BIU 11 to determine the transaction type, i.e., Read Begin, and the target, i.e., the RCU 20. Thereafter, the ready line from the RCU 20 (RCU.sub.-- BIU.sub.-- BRDY) is checked to ensure that the RCU 20 is ready to receive a command. If the ready signal RCU.sub.-- BIU.sub.-- BRDY is asserted, the decoded request is forwarded to the arbitration stage 11b.

The ASM within the arbitration stage 11b arbitrates among the present requests as described above. Thus, if the RCU 20 has not asserted a request, the ASM polls the units 12-19 according to, for instance, the predetermined sequence shown in FIG. 3. Assuming there are no other requests, the ASM provides an LSU0 pre-grant signal (PRE.sub.-- BIU.sub.-- LSUO.sub.-- GNT) to the control stage 11c. As noted above, the CSM is initially in the Check New Transaction state. In response to the received pre-grant signal (PRE.sub.-- BIU.sub.-- LSUO.sub.-- GNT), the request from the LSUO (LSUO.sub.-- BIU.sub.-- REQ) is decoded to determine the transaction type requested (i.e., Read Begin) and the target (i.e., the RCU 20). In response thereto, the CSM transitions to the Read Begin state and asserts a grant to the LSUO 13 (BIU.sub.-- LSU0.sub.-- GNT) via bus 13b and a command to the RCU 20 (BIU.sub.-- RCU.sub.-- CMD) via bus 20b. The CSM enables the address ports connecting the RCU 20 with the common address bus 22 and the common byte enable bus 24, and then provides the address and byte enable specified by the LSUO 13 to the RCU 20 via the common address bus 22 and the common byte enable bus 24, respectively.

Once the address and byte enable signal of the data are forwarded to the RCU 20, the RCU 20 requests a Read End transaction from the BIU 11 in order to provide the requested data to the LSU0 13. Present requests are then arbitrated within the BIU 11 as described above. Simultaneous with granting the request to the RCU 20 via dedicated bus 20b (BIU.sub.-- RCU.sub.-- GNT), the BIU 11 asserts a command to the LSUO 13 (BIU.sub.-- LSUO.sub.-- CMD) via dedicated bus 13b, and also enables the data ports which connect the LSUO 13 with the common data bus 23. The BIU 11 also asserts a data valid signal to the LSUO 13, i.e., BIU.sub.-- LSUO.sub.-- DVALID. Thus, the requested data is routed from the RCU 20 to the BIU 11 via dedicated bus 20a and latched within the BIU 11 using the RCU 20's data valid signal (RCU.sub.-- BIU.sub.-- DVALID) as a strobe. The data is then forwarded to the LSUO 13 via the common data bus 23.

FIG. 5 shows, in a preferred embodiment, specific address, data, and byte enable signals received in the BIU 11 from units 12-20 via respective buses 12a-20a. For instance, the address lines from each of the dedicated unit-to-BIU buses 12a-20a are connected to input terminals of an address multiplexer ADDR MUX within the BIU 11. In response to a select signal asserted by the CSM during its Check New Transaction state, the ADDR MUX provides one of the addresses received from units 12-20 (X.sub.-- BIU.sub.-- ADDR) to the data terminal of a D-type flip flop 30. The flip flop 30 is clocked by the CPU clock and provides the selected address (BIU.sub.-- ADDR) to the common address bus 22. Latching the address within the BIU 11 ensures that there are no critical timing delays associated with driving the address from the initiator to the target through the BIU 11. The data and byte enable signals from units 12-20 are processed within the BIU 11 in a similar manner. Further, although the embodiment of FIG. 5 is shown as allowing only three of units 12-20 to assert byte enable signals (BENABLE), i.e., the LSUO 13, the LSU1 15, and the PCI 18, other embodiments may allow a greater number of units 12-20 to assert byte enable signals, as may be required by particular implementations.

In order to conserve die area, the address, data, and byte enable multiplexers (ADDR MUX, DATA MUX, and BENABLE MUX, respectively) discussed above may be arranged in groups of two or three. FIG. 7 illustrates a possible implementation with respect to the address multiplexers ADDR MUX, where the address lines from the ICUO 12, LSUO 13, and the HSP 19 are multiplexed in a MUX 33 within the ICUO 12, the address lines from the DCU 14, the LSU1 15, and the ICU1 16 are multiplexed in a MUX 34 within the DCU 14, and the address lines from the GDC 17 and the PCI 18 are multiplexed in a MUX 35 within the PCI 18. The output signals from MUXes 33-35 are, in turn, multiplexed in a MUX 36 within the BIU 11 and then latched in, for instance, the flip flop(s) 30 of FIG. 5. Inputs to MUXes 33-36 are selected by the CSM as described above. In this manner, the address indicated in the granted request is provided to the target via the common address bus 22. The data and byte enable signals from the module units 12-20 may be multiplexed in a similar manner.

Present embodiments are advantageous over conventional CPU bus systems in several respects. First, as mentioned above, conventional bus control systems employ tri-state I/O drivers within the CPU module units to control access to the common buses. The time required to switch these drivers between states, which is typically between one and two CPU clock cycles, undesirably limits CPU performance. In contrast, present embodiments do not use such tri-state drivers within the CPU module units 12-20 but rather, as discussed above, employ a bus interface unit 11 to control information flow between the module units 12-20. In present embodiments, address, data, and byte enable signals are transmitted from the module units 12-20 to the BIU 11 via respective dedicated buses 12a-20a, and address, data, and byte enable signals are transmitted from the BIU 11 to the module units 12-20 via respective common buses 22-24. Further, since the dedicated buses 12a-20a and common buses 22-24 are unidirectional, the transmission of information between CPU module units 12-20 in accordance with present embodiments does not require any turn around time, thereby further improving CPU performance.

Second, the BIU 11 arbitrates transactions using a two-level priority scheme, where the first level includes the RCU 20, and the second level, which is of a lower priority than the first level, includes a round-robin rotation of the module units in a predetermine sequence. Further, as mentioned above, when there are no present requests, the ASM defaults to the RCU 20. Since the BIU 11 asserts a grant on every CPU clock cycle, the RCU 20 is given priority access to the common buses 22-24 on every clock cycle, thereby reducing, and in some embodiments even eliminating, the need for time consuming interrupt commands. Further, arbitrating among the level 1 units, i.e., units 12-19, in a predetermined sequence, as well as beginning such arbitration with the unit following the previous arbitration winner in the predetermined sequence, ensures fairness in arbitrating among units 12-19. This novel arbitration system advantageously provides a fair arbitration of requests from module units 12-19 while ensuring that requests from the RDRAM control unit 20 are satisfied within one CPU clock cycle.

While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made without departing from this invention in its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as fall within the true spirit and scope of this invention.

Claims

1. A central processing unit of a computer, comprising:

a common bus;

a plurality of module units each having a first port connected to said common bus;

a plurality of dedicated buses each having a first end coupled to a second port of corresponding ones of said module units; and

a bus interface unit having a first port coupled to said common bus and having a plurality of second ports coupled to second ends of said dedicated buses, said bus interface unit further comprising:

a decode stage having an input port coupled to receive requests from said module units, said requests comprising a transaction type, a first address identifying an initiator module unit of said request, and a second address identifying a target module unit of said request;

an arbitration stage having an input port coupled to an output port of said decode stage; and

a control stage having an input port coupled to an output port of said arbitration stage and having an output port coupled to said first port of said bus interface unit.

2. The apparatus of claim 1, wherein said decode stage comprises combinational logic.

3. The apparatus of claim 2, wherein for each of said requests said combinational logic determines said transaction type requested, said initiator module unit, and said target module unit.

4. The apparatus of claim 1, wherein said arbritration stage comprises a state machine for arbitrating said requests according to a two-level priority scheme.

5. The apparatus of claim 1, wherein said control stage comprises a state machine.

6. The apparatus of claim 5, wherein said state machine comprises a first state during which said control stage awaits said request from said arbitration stage.

7. The apparatus of claim 6, wherein said state machine further comprises a second state during which said control stage asserts a grant to said initiator module unit and a command to said target module unit.

8. The apparatus of claim 7, wherein during said second state said bus interface unit accepts information from said initiator module unit via said dedicated bus and forwards said information to said target module unit via said common bus.

9. The apparatus of claim 8, wherein said information comprises one or more addresses corresponding to one or more of said module units.

10. The apparatus of claim 8, wherein said information comprises data.

11. The apparatus of claim 1, further comprising a plurality of multiplexers each having input terminals coupled to said dedicated buses, an output terminal coupled to said common bus, and a control terminal couped to receive a select signal generated by said control stage of said bus interface unit.

12. The apparatus of claim 11, wherein said multiplexers are internal to said bus interface unit.

13. The apparatus of claim 11, further comprising a plurality of flip-flops coupled between said dedicated buses and said common bus.