Managing the Links of Hypertransport Technology

This section introduces a collection of miscellaneous topics that we have labeled Link Management. They include:

• Flow Control

• Initialization and Reset

• Configuration

• Error Detection and Handling

Each of these topics is discussed in the following sections.

Flow Control

Other than information packets, all packets are transmitted from a transmitter to a buffer in the receiver. The receiver buffer will overflow if the transmitter sends too many packets. Flow control ensures that the transmitter only sends as many packets to the receiver device as buffer space allows.

Information packets are not subject to flow control. They are not transmitted to buffers within a device. Devices are always ready to accept information packets (e.g. NOP packets). Only request packets, response packets and data packets are subject to flow control.

Flow control occurs across each link between the source and the ultimate target device. HyperTransport devices must implement the six types of buffers listed above as part of its receiver state-machine. A designer implements buffers of appropriate size to meet bandwidth/performance requirements. The size of each buffer is conveyed to the transmitter during initialization, and available space is updated dynamically through NOP transmission.

HyperTransport requires transmitters on each link to accept NOP packets from receivers at reset indicating virtual channel buffering capacity, then establish a packet coupon scheme that:

• Guarantees no transmitter will send a packet that the receiver can't accept

• Eliminates the need for inefficient disconnects and retries on the link.

• Requires each receiver to dynamically inform the transmitter (via NOP packets) as buffer space becomes available.

With three virtual channels, there are three pairs of buffers in each receiver to handle request/responses and the data:

• Posted Request Buffer

• Posted Request Data Buffer

• Non-Posted Request Buffer

• Non-Posted Request Data Buffer

• Response Buffer

• Response Data Buffer

Buffer entries are sized according to what will be contained in them.

If A Device Supports the optional Isochronous Channel, it must implement additional flow control buffers to support them. An "ISOC" bit is set in request and response packets indicating routing. If the "ISOC" bit is set, all link devices that support it will use these channels; others will pass Isochronous pacekts along in regular channels.

ISOC traffic is exempt from the fairness algorithm implemented for non-ISOC traffic, resulting in higher performance. Isochronous transactions are serviced by devices before non-isochronous traffic. Theoretically, isochronous traffic may result in starving non-isochronous traffic. Applications must guarantee that isochronous bandwidth does not exceed overall available bandwidth.

Initialization and Reset

HyperTransport defines two classes of reset events:

Cold Reset. This occurs on boot and starts when the PWROK and RESET# signals are both seen low. When this happens:

• All devices and links return to default inactive state

• Previously assigned UnitID numbers are "forgotten" and all return to default UnitID of 0.

• All Configuration Space registers return to default state

• All error bits and dynamic status bits are cleared

Warm Reset. This occurs when PWROK is high and RESET is seen low.

• All devices and links return to default inactive state

• Previously assigned UnitID numbers are "forgotten", and all return to default UnitID of 0.

• All Configuration Space registers defined as persistent retain previous values. The same is true for Status and error bits defined as persistent.

• All other error bits and dynamic status bits are cleared

Because HyperTransport supports scalable link width and clock speed, a set of default minimum link capabilities are in effect following cold reset.

• Initial link width is conveyed when both devices sample CAD signal inputs from the other at the end of reset. Initial link clock speed is 200MHz.

• Later, Configuration of devices allows optimizing CAD width and clock speeds for each link.

• Refer to the core topic section on Reset and Initialization for details on this process.

It is a motherboard's responsibility to tie upper CAD inputs to 0 if a device receiver is attached to a narrower transmitter CAD interface.

Configuration

At boot time, PCI configuration is used to set-up HyperTransport devices:

• Read in configuration information about device requirements and capabilities.

• Program the device with address range, error handling policy, etc.

Basic configuration of a device is similar to that of PCI devices; however, specific HyperTransport-specific features are handled via the advanced capability registers.

Error Detection and Handling

HyperTransport defines required and optional error detection and handling. Key areas of error handling:

• Cycle Redundancy Check (CRC) generation and checking on each link.

• Protocol (violation) errors

• Receive buffer overflow errors

• End-Of-Chain errors

• Chain Down errors

• Response errors

Signals on each HyperTransport link fall into two groups: high speed signals associated with the sending and receiving of control and data packets, and miscellaneous low-speed signals required for such things as reset and power management. Whereas the low speed signals are not scalable and employ conventional low voltage CMOS signalling, the high speed signal group is scalable in terms of both bus width and clock rate, and each signal is actually a low-voltage differential signal pair.

While device pin count varies with scaling, signal group functions remain the same; the only real difference in signaling over a 32-bit link vs. a 2-bit link is the number of bit times required to shift information onto the bus.