HyperTransport Uses PCI Configuration

Many current generation computers use the PCI configuration method and the 256 byte PCI configuration space memory required of all PCI-compliant devices to help set up and manage system chipsets and I/O peripherals. Using PCI configuration for a bus protocol such as HyperTransport goes a long way toward promoting software compatibility with the millions of systems already supporting buses employing PCI-based configuration, including PCI, AGP, PCI-X, USB, etc. HyperTransport is designed for PCI plug-and-play configuration and to minimize impact on existing BIOS and driver software.

What PCI Configuration Accomplishes

During system initialization, low level BIOS or other system software uses configuration transaction cycles to "walk" each PCI-compatible bus (PCI, PCI-X, HyperTransport, AGP, etc.) and read the PCI configuration space of each device function it finds. Once discovered, basic and advanced capability features of each device are set up as appropriate. Collectively, PCI configuration cycles may be used for many aspects of device management, including:

• Assignment of system resources. Unlike earlier bus protocols, including the Industry Standard Architecture (ISA), PCI compatible plug-and-play devices are not allowed to establish their own base addresses and interrupt levels using fixed schemes or through user manipulation of jumpers and switches. Instead, the designer of a PCI compatible device "hard codes" information in selected PCI Configuration Space fields describing the fixed requirements of the device with respect to memory and I/O addresses needed, whether system interrupt support is required, arbitration needs, etc. Once the system address maps and interrupt routing are determined, software then returns to programmable fields in the PCI Configuration Space of each device and programs address ranges, interrupt routing, etc.

• Enabling of device capabilities and options. In addition to assignment of system resources to PCI compatible devices, software also uses the PCI Configuration Space to select device options, enable bus mastering and target decoding of memory and I/O transactions, program error response strategy, and set up other basic PCI and advanced capability protocol features.

• Checking of dynamic (error) status. Finally, the PCI configuration space is used to log errors resulting from attempted transactions. These logged errors, if checked by software, provide a picture of the nature of the error, which device(s) detected it, etc. The Status register in the configuration space header is used for generic PCI-type error logging; in addition, advanced capability register blocks also contain logging fields for errors related to a specific capability (e.g. HyperTransport CRC errors, buffer overflow errors, etc.).

HyperTransport System Limits

HyperTransport shares PCI terminology in describing a system in terms of the number of buses, devices, functions, and configuration space.

256 Buses In A System

PCI permits 256 buses in a system and each PCI host bridge or PCI-to-PCI bridge secondary interface is host to a new bus with a unique bus number. Unlike PCI, a HyperTransport bus may not end with a single electrical connection. Tunnel devices enable the construction of device chains which are still viewed as a single logical bus. The 256 bus limit in HyperTransport, then, is actually 256 chains.

32 UnitIDs Per Bus

PCI permits a maximum of 32 physical devices per bus. In HyperTransport, each functional device can request multiple device numbers, called UnitIDs. The reason for this is because HyperTransport ordering rules consider the transactions from each UnitID to be a unique transaction stream; owning multiple UnitIDs enables a device to source more than one transaction stream (e.g. a standard transaction stream and an isochronous transaction stream for its high priority traffic). The 32 device per bus limit in PCI is a 32 UnitID per bus limit in HyperTransport.

One To Eight Functions Per Device

As in PCI, HyperTransport allows 1-8 logical functions in a physical device package. Each function has its own 256 byte configuration space, and will be assigned unique UnitID(s).

256 Bytes Of Configuration Space

Just as in other PCI devices, each function of a HyperTransport device must implement a 256 byte configuration space memory. The first one-fourth of the configuration space is the header. In addition to the header, devices also must implement at least one set of HyperTransport advanced capability registers.

Configuration Accesses: Reaching All Devices

The process of HyperTransport device configuration depends on software being able to access the 256 byte configuration space of each function in each device on each bus in the system. Configuration cycles originate at the CPU that executes the configuration software; the cycles then move in the direction of the target. This section compares the PCI and HyperTransport methods used to reach the configuration space of a device which may reside on a bus many levels deep in the topology.

Implied in plug-and-play address assignment on buses such as PCI and HyperTransport is the fact that until it is discovered and assigned an address range by low-level software, a device can't claim normal memory or I/O transactions. Furthermore, whenever a bus reset occurs, each device "forgets" its address ranges and other information programmed in configuration space and can no longer be targeted with transactions which depend on assigned addresses. So, how can a device's configuration space be set up if it doesn't know its target address?

In addition to the problem of simple devices recognizing their own configuration cycles in an uninitialized system, the complex topologies permitted in PCI, PCI-X, and HyperTransport require that bridges be programmed to forward configuration transactions to the proper bus before a device can even consider claiming it.

Before looking at how HyperTransport differs from PCI in its handling of system-wide configuration accesses, here is a quick review of how PCI handles them.