Transfer Types Supported

HT supports two types of addressing semantics:

1. legacy PC, address-based semantics

2. messaging semantics common to networking environments

The first part of this book discusses the address-based semantics common to compatible PC implementations . Message-passing semantics are discussed in Chapter 19, entitled "Networking Extensions Overview," on page 443.

Address-Based Semantics

The HT bus was initially implemented as a PC compatible solution that by definition uses Address-based semantics. This includes a 40-bit, or 1 Terabye (TB) address space. Transactions specify locations within this address space that are to be read from or written to. The address space is divided into blocks that are allocated for particular functions, listed in Figure 2-2 on page 23.

Figure 2-2. HT Address Map

HyperTransport does not contain dedicated I/O address space. Instead, CPU I/O space is mapped to high memory address range (FD_FC00_0000h ”FD_FDFF_FFFFh). Each HyperTransport device is configured at initialization time by the boot ROM configuration software to respond to a range of memory address spaces. The devices are assigned addresses via the base address registers contained in the configuration register header. Note that these registers are based on the PCI Configuration registers, and are also mapped to memory space (FD_FE00_0000h ”FD_FFFF_FFFFh. Unlike the PCI bus, there is no dedicated configuration address space.

Read and write request command packets contain a 40-bit address Addr[39:2]. Additional memory address ranges are used for interrupt signaling and system management messages. Details regarding the use of each range of address space is discussed in subsequent chapters that cover the related topic. For example, a detailed discussion of the configuration address space can be found in Chapter 13, entitled "Device Configuration," on page 305.

Data Transfer Type and Transaction Flow

The HT architecture supports several methods of data transfer between devices, including:

• Programmed I/O

• DMA

• Peer-to-peer

Each method is illustrated and described below. An overview of packet types and transactions is discussed later in this chapter.

Programmed I/O Transfers

Transfers that originate as a result of executing code on the host CPU are called programmed I/O transfers. For example, a device driver for a given HT device might execute a read transaction to check its device status. Transactions initiated by the CPU are forwarded to the HT bus via the Host HT Bridge as illustrated in Figure 2-3. The example transaction is a write that is posted by the host bridge; thus no response is returned to from the target device. Non-posted operations of course require a response.

Figure 2-3. Transaction Flow During Programmed I/O Operation

DMA Transfers

HT devices may wish to perform a direct memory access (DMA) by simply initiating a read or write transfer. Figure 2-4 illustrates a master performing a DMA read operation from main DRAM. In this example, a response is required to return data back to the source HT device.

Figure 2-4. Transaction Flow During DMA Operation

Peer-to-Peer Transfers

Figure 2-5 on page 26 illustrates the initial request to read data from the target device residing on the same bus. Note that even though the target device resides on the same bus, it ignores the request moving in the upstream direction (toward the host processor). When the request reaches the upstream bridge, it is turned around and sent in the downstream direction toward the target device. This time the target device detects the request and returns the requested data in a response packet.

Figure 2-5. Peer-to-Peer Transaction Flow

The peer-to-peer transfer does not occur directly between the requesting and responding devices as might be expected. Rather, the upstream bridge is involved in handling both the request and response to ensure that the transaction ordering requirements are managed correctly. This requirement exist to support PCI-compliant ordering. True, or direct, peer-to-peer transfers are supported when PCI ordering is not required as defined by the networking extensions. See Chapter 19, entitled "Networking Extensions Overview," on page 443 for details.