7.1 The System Bus

 

An external bus is a communication path between the major components of a computer system such as the CPU and the PM. A bus within the CPU is called an internal bus. Many systems have multiple external buses. Here we limit our discussion to a single external bus, which we call the system bus (or just the bus), that connects the CPU to all the other components of a simple computer system.

 

 

7.1 The System Bus

 

An external bus is a communication path between the major components of a computer system such as the CPU and the PM. A bus within the CPU is called an internal bus. Many systems have multiple external buses. Here we limit our discussion to a single external bus, which we call the system bus (or just the bus), that connects the CPU to all the other components of a simple computer system.

 

 

 

 

The bus is not directly connected to the CPU, the PM, the secondary storage units, and the IO devices. Instead it is connected to each of these unit's controller. The DMA is not a device, but a special kind of control unit that participates in transfers to and from secondary storage units such as the disk and the CD. A bus transaction consists of a two-way communication between two components, during which the bus is normally unavailable for any other communication. The component that initiates a bus transaction is called the initiator, the bus master, or just the master. The master issues a request, such as a read or write, to some other component, which is called the responder or the slave. Common master-slave pairs are BIU-PMC, BIU-IOC, and DMA-PMC. A transaction begins when the master issues a request and ends when the requested action has finished. A particular bus always uses same set of rules for communication between the master and the slave. This set of rules is called the bus protocol and every device attached to the bus must follow these rules. SCSI (small computer system interface), PCI (peripheral component interconnect), and EISA (extended ISA; ISA was the original IBM AT bus) are common protocols found in PCs.

 

The bus consists of three types of wires, called lines. The control lines, which are collectively called the control bus, transmit the kind of bus transaction (e.g., READ, WRITE) and other information from the master to the slave. In addition the control bus transmits return signals from the slave to the master (e.g., MRC). The address lines, collectively called the address bus, transmit the address of the location within the slave of the data that is to be read (read transaction) or the location into which the data is to be written (write transaction). The data lines, which are collectively called the data bus, transmit the data that is being read or written. Note that even though each of these three sets of lines is called a bus, all of these lines are actually part of the same single bus (the system bus).

 

A bus has a clock and one period of that clock constitutes a bus cycle, or a bus clock (BCLK) as opposed to a processor (CPU) clock (PCLK). A BCLK is much longer than PCLK. High performance PCs may have a 100 MHz, or slightly higher, bus coupled with a 700 MHz to 1 GHz processor. Normally, the minimum time to transfer a request from the master to a slave or to transfer a response from the slave to the master is one BCLK.

 

7.2 Bus Arbitration

 

During one BCLK, one and only one of the components connected the bus is the bus master, each of the other devices is either a slave or inactive. The bus master initiates a bus transfer, while the slave is passive because it can only wait for a request from the bus master. This relationship is not always fixed, for example, either the BIU or the DMA can be a master with the PMC as a slave. The bus arbiter resolves simultaneous requests for use of bus. The two major types of arbiters are centralized and distributed.

 

A centralized arbiter is a single component that always makes the decision. As shown in the figure below, all the devices are connected in parallel to both the bus request line (BR') and the bus busy line (BBSY'), and in series to the bus grant line (BG). If a device wants the bus, it asserts BR' and then waits. When it sees its BGi asserted, it checks BBSY'. If BBSY' is asserted, it waits until it is deasserted and then it starts its bus transaction. The serial connection of all the devices to the bus grant line is called a daisy chain. Each device in the chain passes the BG signal on to the next device in the chain unless it has requested the bus, in which case it does not pass the signal. In a daisy chain, if more than one device has requested the bus at the same time, the one that is closest to the arbiter on the chain has the highest priority and will get the bus.

 

 

In a distributed arbiter all devices are connected to a common set of request lines. Each device knows its own priority. When a device wants the bus, it outputs its priority onto the request lines and then reads the request lines. If the request lines contain that device's priority code then it is the highest priority requester, so it gets the bus. All other devices will see a code higher than their priority and will defer use of bus.

 

7.3 Synchronous and Asynchronous Buses

 

Buses come in two flavors synchronous and asynchronous. Every device attached to a synchronous bus, including the BIU, derives its timing information from a common clock, Bclk, for example. After the master acquires the bus, it can begin a transaction on the next positive edge of Bclk. The master puts the slave's address on the address bus. A short time later, it puts the request type (e.g. READ) and other control information on the control bus. This slight delay before sending control information is necessary to insure that by the time it reaches the slave, the address will have already arrived at the slave. The folloing timing diagram shows the sequence in which the various signals are put onto a bus during a transaction in which the CPU reads a word from memory.

 

 

The number of Bclks for a transaction is fixed in the hardware for each particular synchronous bus protocol. Every transaction uses the same number of Bclks, regardless of the type of transaction. The length of T1 must be long enough so that every potential slave on the bus can see stable address and control signals by the beginning of T2. Once the slave sees the READ signal, it must put the requested data on the data bus enough before the start of T3 that the data will be stable on the data bus. The master assumes that the requested data will be stable on the data bus during T3 so that it can latch the data into its data input buffer before the end of T3. We see that the length of a Bclk must be at least as long as the maximum of the following:

1)          1)        [T1] The maximum time it takes any master to put address, data , and control signals on the bus plus the maximum propagation delay between any master-slave pair that can be connected to the bus.

2)          2)        [T2] The maximum time for any slave to decode any request and respond to that request (e.g. put data on the bus or take data off the bus), including any control or status returned to the master.

3)          3)        [T3] The maximum propagation delay between any slave-master pair that can be connected to the bus plus the maximum time any master requires to latch data, control, and status signals.

 

A synchronous bus is simple and cheap. Its big disadvantage is that the clock must be slow enough to accommodate the slowest device that will ever be connected to the bus since there is no way for the BIU to tell if a device has responded and therefore must assume that the device has responded by the end of one bus cycle. In the above example, the master assumes that the slave has responded by the end of T2 and completes the end of transaction actions during T3. If the slave has not responded by the end of T2, the master will latch garbage into its data input buffer and accept it as valid data.

 

An asynchronous bus has no common clock, instead it uses handshaking to synchronize the actions of the device and the BIU. There are two timing control lines, Ready and Accept, as shown in the figure below. For example, to do a read from PM, the BIU puts the address and a READ signal on the bus. After a delay for the maximum skew (the maximum skew is the time for all the bus lines to settle into a stable state), the BIU asserts Ready. By the time the PMC has received the Ready signal, it has already decoded the address and mode information. Once the Ready signal is received, the PMC puts the data on the bus and asserts Accept. (The arrows in the diagram point at the responses to various events). After the BIU receives the Accept signal, it delays for the maximum skew and then strobes the data into MBR. Then it drops the Ready signal. After a short delay, so that the change in Ready reaches the PMC before the PM sees the address and the Read signal drop, the BIU drops the address and the Read signal. The PMC sees the Ready signal drop and then removes the data and the Accept signal.

 

 

The sequence

1)    1)     master asserts ready

2)    2)     slave asserts accept

3)    3)     master de-asserts ready

4)    4)     slave de-asserts

are the four steps in the handshaking. Since the actions of the master and the slave are not tied to a clock, an asynchronous bus can accommodate devices that have greatly different response times. A fixed time interval that is long enough to accommodate a slow CU is not needed. Thus, transactions between CUs with short response times will be short and transactions between CUs with long response times will be long.

 

Adapted from Copyright 2000 Robert M. Graham

 

 

 

 

The bus is not directly connected to the CPU, the PM, the secondary storage units, and the IO devices. Instead it is connected to each of these unit's controller. The DMA is not a device, but a special kind of control unit that participates in transfers to and from secondary storage units such as the disk and the CD. A bus transaction consists of a two-way communication between two components, during which the bus is normally unavailable for any other communication. The component that initiates a bus transaction is called the initiator, the bus master, or just the master. The master issues a request, such as a read or write, to some other component, which is called the responder or the slave. Common master-slave pairs are BIU-PMC, BIU-IOC, and DMA-PMC. A transaction begins when the master issues a request and ends when the requested action has finished. A particular bus always uses same set of rules for communication between the master and the slave. This set of rules is called the bus protocol and every device attached to the bus must follow these rules. SCSI (small computer system interface), PCI (peripheral component interconnect), and EISA (extended ISA; ISA was the original IBM AT bus) are common protocols found in PCs.

 

The bus consists of three types of wires, called lines. The control lines, which are collectively called the control bus, transmit the kind of bus transaction (e.g., READ, WRITE) and other information from the master to the slave. In addition the control bus transmits return signals from the slave to the master (e.g., MRC). The address lines, collectively called the address bus, transmit the address of the location within the slave of the data that is to be read (read transaction) or the location into which the data is to be written (write transaction). The data lines, which are collectively called the data bus, transmit the data that is being read or written. Note that even though each of these three sets of lines is called a bus, all of these lines are actually part of the same single bus (the system bus).

 

A bus has a clock and one period of that clock constitutes a bus cycle, or a bus clock (BCLK) as opposed to a processor (CPU) clock (PCLK). A BCLK is much longer than PCLK. High performance PCs may have a 100 MHz, or slightly higher, bus coupled with a 700 MHz to 1 GHz processor. Normally, the minimum time to transfer a request from the master to a slave or to transfer a response from the slave to the master is one BCLK.

 

7.2 Bus Arbitration

 

During one BCLK, one and only one of the components connected the bus is the bus master, each of the other devices is either a slave or inactive. The bus master initiates a bus transfer, while the slave is passive because it can only wait for a request from the bus master. This relationship is not always fixed, for example, either the BIU or the DMA can be a master with the PMC as a slave. The bus arbiter resolves simultaneous requests for use of bus. The two major types of arbiters are centralized and distributed.

 

A centralized arbiter is a single component that always makes the decision. As shown in the figure below, all the devices are connected in parallel to both the bus request line (BR') and the bus busy line (BBSY'), and in series to the bus grant line (BG). If a device wants the bus, it asserts BR' and then waits. When it sees its BGi asserted, it checks BBSY'. If BBSY' is asserted, it waits until it is deasserted and then it starts its bus transaction. The serial connection of all the devices to the bus grant line is called a daisy chain. Each device in the chain passes the BG signal on to the next device in the chain unless it has requested the bus, in which case it does not pass the signal. In a daisy chain, if more than one device has requested the bus at the same time, the one that is closest to the arbiter on the chain has the highest priority and will get the bus.

 

 

 

In a distributed arbiter all devices are connected to a common set of request lines. Each device knows its own priority. When a device wants the bus, it outputs its priority onto the request lines and then reads the request lines. If the request lines contain that device's priority code then it is the highest priority requester, so it gets the bus. All other devices will see a code higher than their priority and will defer use of bus.

 

7.3 Synchronous and Asynchronous Buses

 

Buses come in two flavors synchronous and asynchronous. Every device attached to a synchronous bus, including the BIU, derives its timing information from a common clock, Bclk, for example. After the master acquires the bus, it can begin a transaction on the next positive edge of Bclk. The master puts the slave's address on the address bus. A short time later, it puts the request type (e.g. READ) and other control information on the control bus. This slight delay before sending control information is necessary to insure that by the time it reaches the slave, the address will have already arrived at the slave. The folloing timing diagram shows the sequence in which the various signals are put onto a bus during a transaction in which the CPU reads a word from memory.

 

 

The number of Bclks for a transaction is fixed in the hardware for each particular synchronous bus protocol. Every transaction uses the same number of Bclks, regardless of the type of transaction. The length of T1 must be long enough so that every potential slave on the bus can see stable address and control signals by the beginning of T2. Once the slave sees the READ signal, it must put the requested data on the data bus enough before the start of T3 that the data will be stable on the data bus. The master assumes that the requested data will be stable on the data bus during T3 so that it can latch the data into its data input buffer before the end of T3. We see that the length of a Bclk must be at least as long as the maximum of the following:

1)        [T1] The maximum time it takes any master to put address, data , and control signals on the bus plus the maximum propagation delay between any master-slave pair that can be connected to the bus.

2)        [T2] The maximum time for any slave to decode any request and respond to that request (e.g. put data on the bus or take data off the bus), including any control or status returned to the master.

3)        [T3] The maximum propagation delay between any slave-master pair that can be connected to the bus plus the maximum time any master requires to latch data, control, and status signals.

 

A synchronous bus is simple and cheap. Its big disadvantage is that the clock must be slow enough to accommodate the slowest device that will ever be connected to the bus since there is no way for the BIU to tell if a device has responded and therefore must assume that the device has responded by the end of one bus cycle. In the above example, the master assumes that the slave has responded by the end of T2 and completes the end of transaction actions during T3. If the slave has not responded by the end of T2, the master will latch garbage into its data input buffer and accept it as valid data.

 

An asynchronous bus has no common clock, instead it uses handshaking to synchronize the actions of the device and the BIU. There are two timing control lines, Ready and Accept, as shown in the figure below. For example, to do a read from PM, the BIU puts the address and a READ signal on the bus. After a delay for the maximum skew (the maximum skew is the time for all the bus lines to settle into a stable state), the BIU asserts Ready. By the time the PMC has received the Ready signal, it has already decoded the address and mode information. Once the Ready signal is received, the PMC puts the data on the bus and asserts Accept. (The arrows in the diagram point at the responses to various events). After the BIU receives the Accept signal, it delays for the maximum skew and then strobes the data into MBR. Then it drops the Ready signal. After a short delay, so that the change in Ready reaches the PMC before the PM sees the address and the Read signal drop, the BIU drops the address and the Read signal. The PMC sees the Ready signal drop and then removes the data and the Accept signal.

 

 

The sequence

1)     master asserts ready

2)     slave asserts accept

3)     master de-asserts ready

4)     slave de-asserts

are the four steps in the handshaking. Since the actions of the master and the slave are not tied to a clock, an asynchronous bus can accommodate devices that have greatly different response times. A fixed time interval that is long enough to accommodate a slow CU is not needed. Thus, transactions between CUs with short response times will be short and transactions between CUs with long response times will be long.

 

Adapted from Copyright 2000 Robert M. Graham