HyperTransportв„ў System Architecture

2017-07-07 02:10:07

A HyperTransport chain consists of a host bridge at one end and some collection of devices connected to it in a daisy-chain arrangement. At the end of the chain, there is a device with a single-link connection. This could either be an end (I/O hub) device, or a multi-link device (e.g. tunnel) which has its downstream link disabled.

By contrast, a double-hosted chain has a host bridge at either end and some collection of multi-link devices between them. Figure 17-1 on page 428 illustrates a double-hosted chain. Note that there are no end (I/O hub) devices in a double-hosted chain.

Figure 17-1. HyperTransport Double-Hosted Chain Configuration

Reasons For Implementing A Double-Hosted Chain

A double hosted-chain can be useful in fault-tolerant applications where a backup host interface takes over in the event of a failure of the primary interface. It also permits the sharing of a single set of resources and inter-processor communications by two CPUs in a clustering arrangement. Note: the HyperTransport I/O Link Specification Network Extensions allow extending the multiple-host concept to broader topologies using switch and router components . Refer to Chapter 19, entitled "Networking Extensions Overview," on page 443.

PCI Configuration Plays Key Role In Chain Setup

PCI configuration cycles are used to program bridges, tunnels, and end devices in each HyperTransport all chain. Two key registers used in setting up double-hosted chain (DHC) parameters are the HyperTransport Host Command CSR for host bridges and the HyperTransport Slave Command CSR for interior devices such as tunnels. These two registers and the key fields pertaining to double-hosted chains are described below. Refer to Chapter 13, entitled "Device Configuration," on page 305 for a more complete description of PCI device configuration.

Slave Command CSR

Figure 17-2 and Table 17-1 on page 429 show the format of the Slave Command Register used by all non-host interfaces; key fields used in double-hosted chain configuration are highlighted.

Figure 17-2. Slave Command CSR: Key Fields In DHC Configuration

Table 17-1. Slave Command CSR: Definitions Of Key Fields In DHC Configuration

Bit	Function
10	Master Host . This read-write bit is set by hardware automatically to indicate which link is attached to the host. Any write to the Command register will cause this bit to be set to indicate which link the write arrived on. Warm Reset = 0.
11	Default Direction . This read-write bit determines the default direction requests should be sent when originating with this device. A "0" in this register indicates requests should be sent in the direction of the master host (see previous bit). A "1" indicates requests should be sent in the other direction. Bit has no meaning for a single-link device. Warm Reset = 0.

Host Command CSR

Figure 17-3 and Table 17-2 show the format of the Host Command Register used by all host interfaces; key fields used in double-hosted chain configuration are highlighted.

Figure 17-3. Host Command CSR: Key Fields In DHC Configuration

Table 17-2. Host Interface Block Host Command CSR Bit Assignment

Bit	Function
1	Double Ended . If this read-write bit is set = 1, there is another bridge at the other end of the chain (double-hosted chain). This bit does not affect hardware and can be used by software during initialization. If not implemented, hardwire this bit = 0. Cold reset = 0.
7	Chain Side . This bit is set to indicate which side of the host bridge is being accessed. A "0" in this field indicates the read is coming from within; a "1" indicates the read is coming from the chain attached to the host interface. If double-hosted chains are not supported, this bit is hardwired = 0.
8	Host Hide . This read-write bit is used to hide a bridge's configuration space from accesses coming from the chain side. If the bit is set = 1, the host will behave as an end-of-chain device during configuration cycles; if it is clear, configuration accesses from the chain are allowed by the device. For hosts which support DHCs, this bit is cleared on warm reset. If a host does not support double-hosted chains, this bit is hardwired = 1.
10	Act As Slave. This bit, when set, causes host to act as a slave, using the device number programmed in bits 6:2 as the base UnitID for requests and responses it sources. In this mode, the host also won't set the Bridge bit in its responses. If this bit is clear, interface behaves as a host ” using UnitID 0, setting the Bridge bit on responses it sends, etc. If host doesn't support double-hosted chains, this bit is hardwired = 0. Cold reset = 0.