WO2001050216A2

WO2001050216A2 - Communication bus for a multi-processor system

Info

Publication number: WO2001050216A2
Application number: PCT/IB2001/000276
Authority: WO
Inventors: John G. Mathieson
Original assignee: Vm Labs, Inc.
Priority date: 2000-01-03
Filing date: 2001-01-03
Publication date: 2001-07-12
Also published as: AU3401301A; WO2001050216A3; US6732210B1

Abstract

In accordance with the invention, a multi-processing unit system (10) including a plurality of processing units (14-38) in direct communication via a communication bus (12) is presented. The system includes a communication bus arbiter (40) having a communication packet multiplexer. Each of the processing units include a communication bus interface comprising a transmitter interface and a receiver interface. Each of the transmitter interfaces are connected to the communication packet multiplexer of the communication bus arbiter via separate 32-bit interfaces. Each of the receiver interfaces is connected to the communication packet multiplexer of the communication bus arbiter via a single 32-bit bus. The system may further comprise a first control signal connection means for communicating control signals between the transmitter interface and the communication bus arbiter and a second control signal connection means for communicating control signal between the receiver interface and the communication bus arbiter.

Description

COMMUNICATION BUS FOR A MULTI-PROCESSOR SYSTEM

BACKGROUND OF THE INVENTION The present invention relates generally to a multiple processing unit system in which the processing units can communicate directly with each other, and more particularly to a novel- communication bus and bus protocol which facilitates communication between processing units.

Multi-processor or multi-processing unit systems are well known in the art. To fully utilize the benefits of having multiple processing units working in parallel, the processing units should communicate with one another. However, most bus structures connecting multiple processing units are designed to allow the processing units to share memory, not communicate directly. That is, the busses are memory busses, not communication busses. Memory busses are configured to handle bursts of data efficiently, such as cache lines or other data blocks. In designs in which the memory bus is used to connect processing units to DRAM memory, it also is important to perform longer bursts of data transfer for efficiency, as DRAM has a set-up overhead when accessing an address which is not adjacent to a previously accessed address. This burst nature gives the bus higher bandwidth at a cost of higher latencies.

In certain situations, it is important to have low latency transfers. For example, in a multi-media system performing a 3D pixel rendering function, one processing unit may be configured to process a list of geometry coordinates, while another processing unit may be configured to render the scene on a video display. With the current systems, the first processing unit writes the geometry coordinates to memory, and then the second processing unit pulls the coordinates out of memory to render the scene. With this configuration, the memory buffer decouples the two processes, creating latencies caused by writing data to and reading data from the memory. These latencies reduce the true parallel processing benefits from the multi-processing unit system, because the second processing unit is delayed in rendering the 3D scene. To more efficiently process the data, it is preferable for the first processing unit to pass the data directly to the second processing unit to avoid the memory latencies. That way, the second processing unit can perform the rendering process as soon as possible.

Thus, what is needed is a communication bus and associated protocol that facilitates low latency transfers between multiple processing units. SUMMARY OF THE INVENTION In accordance with the invention, a multi-processing unit system including a plurality of processing units in direct communication via a communication bus is presented. The system includes a communication bus arbiter having a communication packet multiplexer. Each of the processing units includes a communication bus interface comprising a transmitter interface and a receiver interface. Each of the transmitter interfaces is connected to the communication packet multiplexer of the communication bus arbiter via separate 32-bit interfaces. Each of the receiver interfaces is connected to the communication packet multiplexer of the communication bus arbiter via a single 32- bit bus.

The system may further comprise a first control signal connection means for communicating control signals between the transmitter interface and the communication bus arbiter and a second control signal connection means for communicating control signal between the receiver interface and the communication bus arbiter. In accordance with one embodiment of the present invention, the first control signal connection means comprises two 1-bit communication connections, one for communicating bus request signals from the transmitter interface to the communication bus arbiter, and the other for communicating bus request acknowledgment signals from the communication bus arbiter to the transmitter interface. Similarly, the second control signal connection means preferably comprises two 1-bit communication connections, one form communicating receiver buffer full signals from the receiver interface to the communication bus arbiter, and the other for communicating receive packet enable signals from the communication bus arbiter to the receiver interface. In accordance with one embodiment of the present invention, the processing units preferably communicate with one another using communication packets comprising a 32-bit header and a 128-bit data packet. The 128-bit data packet preferably is presented as 4 32-bit data packets.

The present invention further comprises a novel communication protocol for communicating data packets between the processing units over the communication bus. In accordance with one embodiment of the protocol or the present invention, a first processing unit sends a bus request to a bus arbiter. If the communication bus is open for communication, the bus arbiter grants the first processing unit access to the bus. The first processing unit then sends a header packet to the bus arbiter, which includes a target ID. The bus arbiter takes the target ID and determines if a second processing unit associated with the target ID is able to receive data from the first processing unit. If the second processing unit is able to receive data, the first processing unit sends a 128-bit data packet to the bus arbiter, which in turn, sends the data packet to the second processing unit. In accordance with one embodiment of the present invention, the 128-bit data packet is sent in 4 separate 32-bit packets. It typically takes 5 clock cycles to send the 128 bits of data to the second processing unit.

A more complete understanding of the present invention may be derived by referring to the detailed description of preferred embodiments and claims when considered in connection with the figures, wherein like reference numbers refer to similar items throughout the figures.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of a multi-processing unit system utilizing a communication bus in accordance with the present invention;

Fig 2 is a block diagram showing how multiple processing units connect to the communication bus of the present invention;

Fig. 3 is a more detailed block diagram of Fig. 2; Fig. 4 is a clock timing diagram illustrating what happens when data is transmitted from one processing unit to another in accordance with the commumcation protocol of the present invention; and

Fig. 5 is a clock timing diagram illustrating what happens when the receive buffer in a target device is full.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

The present invention relates generally to a multiple processing unit system in which the processing units can communicate directly with each other, and more particularly to a novel communication bus and bus protocol which facilitates communication between processing units. The communication bus and associated protocol of the present invention may be used in any multi-processing unit system. However, in accordance with one embodiment of the invention, and for purposes of example, the communication bus and protocol will be described herein with reference to a particular multi-media processing system comprising a plurality of processing units. Referring now to Fig. 1, a multi-processing unit system 10 comprising a communication bus 12 (hereinafter referred to as "comm bus 12") is shown. In accordance with the illustrated embodiment, a plurality of processing units 14-38 are connected to comm bus 12. In addition, as discussed in more detail below, a comm-bus- arbiter 40 is connected to or is part of comm bus 12, and is configured to facilitate data transfers over comm bus 12.

Comm bus 12 is configured to allow multiple processing units to communicate directly with each other. In accordance with this aspect of the present invention, any number of different processing units can be connected to comm bus 12. For example, processors, ROM and/or RAM interfaces, system bus interfaces, peripheral device interfaces, audio and/or video I O units, ASIC and/or co-processor units may be connected to comm bus 12. As illustrated in Fig. 1, multi-media processing system 10 comprises a variety of different processing units connected to comm bus 12. In accordance with the illustrated embodiment, four media processing elements (MPEs) 14- 20 are connected to comm bus 12. The MPEs are configured to perform the majority of data processing for system 10. In addition, other processing units connected to comm bus 12 include a ROM interface device 22, a peripheral device I/O interface 24, a coded data (i.e. MPEG data) interface 26, an audio I/O unit 28, a video input unit 30, a video display generator 32, a system bus interface 34, an MPEG hardware assist unit 36 and a DRAM interface/DMA unit 38. As discussed in more detail below, processing units 14-38 can communicate directly with each other over comm bus 12 using a suitable comm bus protocol as described herein. For a more detailed discussing of the configuration and operation of systems 10, see U.S. Patent Application No. 09/476,761, filed 3 January 2000 and entitled "A Media Processing System and Method," the entirety of which is incorporated herein by reference for all purposes. In addition, while Fig. 1 illustrates one embodiment of a system having a number of different types of processing units connected to comm bus 12, one skilled in the art will appreciate that comm bus 12 can be configured within any number of different systems, for connecting a variety of different processing units and unit types. Therefore, the present invention is not limited to the illustrated embodiment.

Referring now to Fig. 2, a diagram of how processing units are connected to comm bus 12, and more particularly to comm bus arbiter 40 is shown. For illustration purposes only, Fig 2 shows MPE0 14, MPE1 16, MPE2 18, MPE3 20, video unit 30 and audio unit 28 connected to comm bus arbiter 40. However, as one skilled in the art will appreciate, all processing units connected to comm bus 12 will be connected similarly. Each processing unit includes a 32-bit write bus connection 42 and a 32-bit read bus connection 44 to comm bus arbiter 40. The 32-bit write bus connections 42 are separate for each processing unit, but the 32-bit read bus connections 44 are multiplexed together,

5 as shown in Fig. 2. That is, a single 32-bit read bus connection 44 connects all processing units to comm bus arbiter 40. In addition, each processing unit preferably includes 4 1-bit control signal connections 46, 48, 50 and 52. In accordance with one embodiment of the present invention, connection 46 corresponds to a comm_bus_req signal connection, connection 50 corresponds to a comm_bus_ack signal connection, connection 48

10. corresponds to a rec_buff_full signal connection, and connection 52 corresponds to a rec_en signal connection. The function of each control signal 46-52 will be discussed in more detail below.

Referring now to Fig. 3, a more detailed diagram of how each processing unit is connected to comm bus arbiter 40 is shown. In accordance with the illustrated

15 embodiment, each processing unit (referred to generically as processing unit 54 in Fig. 3) further comprises comm bus interface 56 which includes a transmitter interface 58 and a receiver interface 60. In addition, comm bus arbiter 40 includes a multiplexer (MUX) 62. Preferably, each of the 32-bit write bus connections 42 are connected between transmitter interface 58 of each processing unit 54 and MUX 62 of comm bus arbiter 40. In this

20 regard, MUX 62 comprises a plurality of 32-bit inputs; one for each processing unit 54 connected to the comm bus. The output of MUX 62 is a single 32-bit read bus 44 connected to receiver interfaces 60 of each processing unit 54. Thus, MUX 62 is configured to receive a plurality of data write or transmit requests from one or more processing units 54, but only will process one at a time due to the single read bus

25 connection 44.

As illustrated in Fig. 3, each transmitter interface 58 of processing units 54 includes 2 1-bit control signal connections to comm bus interface 40: (1) comm_bus_req control signal connection 46 from transmitter interface 58 to comm bus interface 40; and (2) comm_bus_ack control signal connection 50 from comm bus interface 40 to

30 transmitter interface 58. Similarly, each receiver interface 60 of processing units 54 also includes 2 1-bit control signal connections to comm bus interface 40: (1) rec_buff_full control signal connection 48 from receiver interface 60 to comm bus interface 40; and (2) rec en control siεmal connection 52 from comm bus interface 40 to receiver interface 60. Referring now to Tables 1 and 2, the protocol for sending data packets over the commumcation bus will be discussed. The protocol starts when a transmitter interface 58 of a processing unit 54 sends a bus request to comm bus arbiter 40. Transmitter interface issues a bus request by setting comm_bus_req control signal 46 active. If multiple processing units 54 submit bus requests to arbiter 40 at or near the same time, arbiter 40 will arbitrate access to the bus by some predetermined protocol. For example, round-robin arbitration, or a priority scheme.

After transmitter interface 58 sends the bus request, processing unit 54 waits until it is granted access to the bus. As illustrated in Tables 1 and 2, processing unit 54 may wait from 0 to L_{π x} clock cycles before it is granted access to the bus; where _mu, is 5 clock cycles time the maximum number of simultaneously requesting units. As discussed in more detail below, the significance of 5 clock cycles is that it takes 5 clock cycles to fully transmit a communication packet (1 clock cycle for the 32-bit header and 4 clock cycles for the 128-bit data packet). At the end of a previous data transfer, but while some of the data of the previous transfer is still on the bus, comm bus arbiter 40 will send a bus acknowledge signal to the processing unit requesting the bus (see Tables 1 and 2). Comm bus arbiter 40 sends the bus acknowledge signal by setting comm_bus_ack control signal 50 active.

After comm bus arbiter 40 has granted the processing unit access to the bus, transmitter interface 58 sends a header packet, which includes a Target ID and a

Sender ID, to comm bus arbiter 40. Upon receiving the header packet, comm bus arbiter 40 uses the Target ID to check whether the target processing unit can receive a data packet. That is, comm bus arbiter 40 checks rec_buff_full control signal 48 from the target processing unit. If rec_buff_full control signal 48 is not active, then the receive buffer in receiver interface 60 of the target processing unit is not full, and the target processing unit can receive the data packet. At this point, comm bus arbiter 40 keeps comm_bus_ack control signal 50 active and sets rec_en control signal 52 active. By keeping comm_bus_ack control signal 50 active, transmitter interface 58 of the transmitting processing unit will begin sending data packets to comm bus arbiter 40. Also, by activating rec_en control signal 52, comm bus arbiter 40 is instructing receiver interface 60 of the target processing unit to begin receiving data. As comm bus arbiter 40 receives data packets from the transmitting processing unit, it passes the data packets throughout to the target unit. To transmit a full 128-bit data packet, four separate 32-bit data packets are transmitted. Table 1 below illustrates the process of sending a data packet over the comm bus.

Table 1

Referring now to Table 2, the processing protocol for when a receive buffer is full will now be described. If after comm bus arbiter 40 checks rec_buff_full control signal 48, the rec_buff_full control signal 48 is active, then the receive buffer in receiver interface 60 of the target processing unit is full or being filled, and thus cannot receive any more data. Since the target processing unit cannot receive the data from the transmitting unit, comm bus arbiter 40 will deactivate comm_bus_ack control signal 50, thus telling transmitter interface 58 of the transmitting processing unit not to send the data. In addition, comm bus arbiter 40 will not set rec_en control signal 52 active. Comm bus arbiter 40 then will begin processing the next communication bus request.

Table 2 Referring now to Figs. 4 and 5, the protocol for transmitting data over the communication bus in accordance with the present invention will be discussed with reference to the timing diagrams. Fig. 4 is a timing diagram 100 showing the timing of the control signals and data transfers when data transmission occurs. Clock cycles 102 are shown at the top of timing diagram 100. First, in order to transmit data, the transmitting processing unit sends a bus request by activating comm_bus_req control signal 104 at clock cycle 0. Control signal 104 stays active until comm bus arbiter 40 sends a comm_bus_ack control signal 106 at clock cycle L. As discussed above, L can be any number of clock cycles up to Lmax; where Lmax is 5 clock cycles times the maximum number of simultaneously requesting units. Upon receiving the comm_bus_ack control signal 106, transmitter interface 58 of the transmitting unit sends a Target ID and Sender ID to comm bus arbiter 40 (clock cycle L+l). Comm bus arbiter 40 then uses the Target ED to determine whether the target processing unit is able to receive the data. To do this, comm bus arbiter 40 checks the rec_buff_full control signal 118 at clock cycle position L+2.

As illustrated in Fig. 4, control signal 118 at clock cycle position L+2 is low or inactive, so the target device is able to receive data. The cross-hatched area 120 of control signal 118 is to illustrate that comm bus arbiter 40 does not care what the state of rec_buff_full signal 118 is after clock cycle position L+2. That is, once comm bus arbiter 40 has determined that the target unit can receive data, it does not care about the state of signal 118. Similarly, after comm bus arbiter 40 has determined that it can send the data, it is not concerned with the status of the comm_bus_req signal 104. This is illustrated by cross-hatched area 105. Also, if rec_buff_full signal 118 is inactive at clock cycle L+2, comm bus arbiter will activate rec_en signal 122 at or shortly after clock cycle position L+2. Signal 122 tells the target unit to begin receiving data.

If the target unit is able to receive data, comm bus arbiter 40 keeps comm_bus_ack signal 106 active, signaling transmitter interface 58 of the transmitting unit to send data packets. As illustrated in Fig. 4, data packets 110-116 are sent to comm bus arbiter 40 in 4 clock cycles; L+2 - L+3, L+3 - L+4, L+4 - L+5, and L+5 - L+6, respectively. Thus 4 32-bit data packets are sent in 4 clock cycles, for a total of 128 bits. Upon receiving data packets 110-116, comm bus arbiter 40 forwards the data packets to receiver interface 60 of the target unit. Transmission from arbiter 40 to the target unit begins as soon as arbiter 40 receives the first data packet. Given that it takes 1 clock cycle to transmit the first data packet from the transmitting unit to arbiter 40, transmission of the data packets to^* the target unit begins at L+3 and continues until L+7. As shown in Fig. 4, once arbiter 40 begins receiving the final data packet 116, arbiter 40 deactivates comm_bus_ack signal 106, so that the arbiter can begin processing the next comm bus request. Referring now to Fig. 5, timing diagram 130 is shown illustrating the timing of the control signals and data transfers when the receive buffer in the target processing unit is full. Clock cycles 132 are shown at the top of timing diagram 130. As discussed above with reference to timing diagram 100, in order to transmit data, the transmitting processing unit sends a bus request by activating comm_bus_req control signal 134 at clock cycle 0. Control signal 104 stays active until comm bus arbiter 40 sends a comm_bus_ack control signal 136 at clock cycle L. Upon receiving the comm_bus_ack control signal 136, transmitter interface 58 of the transmitting unit sends a Target ID and Sender ID to comm bus arbiter 40 (clock cycle L+l - L+2). Comm bus arbiter 40 then uses the Target ED to determine whether the target processing unit is able to receive the data. To do this, comm bus arbiter 40 checks the rec_buff_full control signal 140 at clock cycle position L+2. In this case, rec_buff_full signal 140 is active at clock cycle position L+2, signaling that the receive buffer is full or being filled, and thus, the target processing unit cannot receive data. Accordingly, comm bus arbiter 40 deactivates comm_bus_ack signal 136 at clock cycle position L+2, which instructs the transmitting device to not send data. In addition, arbiter 40 does not active rec_en signal 142. By deactivating comm_bus_ack signal 136, arbiter 40 is able to receive the next communication bus request from another device or from the same device.

As illustrated in Table 3, each comm bus interface 56 of processing units 54 connected to comm bus arbiter 40 include various control fields used to facilitate communication with the bus. The configuration and function of each of the control fields is described in Table 3.

Bits Read/ Description Write

0-7 RW Transmit target ED. This will be used for the next data to be written into the transmit data buffer.

12 RW Transmit bus lock flag. When a transmitter sets this bit, the communication bus will be locked to this transmitter until this bit is cleared. This allows one transmitter to have the maximum possible communication bus bandwidth available to it. (Only the MPEs have this bit.)

Table 3

In conclusion, the present invention provides a novel communication bus and bus protocol for connecting multiple processing units in a multi-processing unit system. While a detailed description of presently preferred embodiments of the invention has been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art. For example, while the communication bus is disclosed herein with reference to a particular media processing system, one skilled in the art will appreciate that the communication bus of the present invention can be used with any multi-processing unit system without varying from the spirit of the invention. Therefore, the above description should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Claims

1. A multi-processing unit system including a plurality of processing units in direct communication via a communication bus, comprising: a communication bus arbiter having a communication packet multiplexer; each of said processing units including a communication bus interface comprising a transmitter interface and a receiver interface, each of said transmitter interfaces being connected to said communication packet multiplexer of said communication bus arbiter via separate 32-bit interfaces, and each of said receiver interfaces being connected to said communication packet multiplexer of said communication bus arbiter via a single 32-bit bus.

2. The system as recited in claim 1 , further comprising: first control signal connection means for communicating control signals between said transmitter interface and said communication bus arbiter, and second control signal connection means for communicating control signals between said receiver interface and said communication bus arbiter.

3. The system as recited in claim 2, wherein said first control signal connection means communicates bus request signals from said transmitter interface to said communication bus arbiter and bus request acknowledgment signals from said communication bus arbiter to said transmitter interface, and said second control signal connection communicates receiver buffer full signals from said receiver interface to said communication bus arbiter and receive packet enable signals from said communication bus arbiter to said receiver interface.

4. The system as recited in claim 2, wherein said first control signal connection means comprises two 1-bit commumcation connections between said communication bus arbiter and said transmitter interface, and said second control signal connection means comprises two 1-bit communication connections between said communication bus arbiter and said receiver interface.

5. The system as recited in claim 1 , wherein said plurality of processing units may comprise processing units selected from the group of processing units comprising processors, ROM interfaces, DMA controllers, system bus interfaces, co-processors; multi-media hardware assist units, audio and video input and output interfaces, and peripheral devices.

6. The system as recited in claim 1, wherein said processing units communicate with each other over said communication bus using communication packets comprising a 32-bit header and a 128-bit data packet.

7. A protocol for communicating over a communication bus connecting a plurality of processing units, said protocol comprising the steps of: a first processing unit sending a bus request to a bus arbiter, said bus arbiter granting said first processing units access to said communication bus; said first processing unit sending a header packet to said bus arbiter, said header packet including a target ID; said bus arbiter determining whether a second processing unit associated with said target ID is able to receive data; if said second processing unit is able to receive data, said first processing device sending a 128-bit data packet to said bus arbiter, and said bus arbiter receiving said 128-bit data packet and sending said 128-bit data packet to said second processing device.

8. The protocol as recited in claim 7, wherein said 128-bit data packet is transmitted from said first processing unit to said second processing unit in 5 clock cycles.

9. The protocol as recited in claim 7, wherein if said second processing unit is not able to receive data, said first processing device does not send data to said bus arbiter.

10. The protocol as recited in claim 7, where in said first processing unit comprises a transmitter interface, and wherein said transmitter interface performs said step of sending a bus request to a bus arbiter.

11. The protocol as recited in claim 7, wherein said second processing unit comprises a receiver interface, and wherein said step of said bus arbiter determining whether a second processing unit is able to receive data comprises determining whether said receiver interface has set a receive buffer full signal active.