Packetized Transfers of Hypertransport Technology

Packetized Transfers

Transactions are constructed out of combinations of various packet types and carry the commands, address, and data associated with each transaction. Packets are organized in multiples of 4-byte blocks. If the link uses data paths that are narrower than 32 bits, successive bit-times are added to complete the packet transfer on an aligned 4-byte boundary. The primary packet types include:

• Control Packets — used to manage various HT features, initiate transactions, and respond to transactions

• Data packets — that carry the payload associated with a control packet (maximum payload is 64 bytes).

For every group of 8 bits (or less) within the CAD path, there is a CLK signal. These groups of signals are transmitted source synchronously with the associated CLK signal. Source synchronous clocking requires that CLK and its associated group of CAD signals must all be routed with equal length traces in order to minimize skew between the signals.

Control Packets

Control packets manage various HT features, initiate transactions, and respond to transactions as listed below:

• Information packets

• Request packets

• Response packets

Information packet (4 bytes)

Information packets are exchanged between the two devices on a link. They are used by the two devices to synchronize the link, convey a serious error condition using the Sync Flood mechanism, and to update flow control buffer availability dynamically (using tags in NOP packets). The information packets are:

• NOP

• Sync/Error

Request packet (4 or 8 bytes)

Request packets initiate HT transactions and special functions. The request packets include:

• Sized Write (Posted)

• Broadcast Message

• Sized Write (non-posted)

• Sized Read

• Flush

• Fence

• Atomic Read-Modify-Write

Response packet (4 bytes)

Response packets are used in HT split-transactions to reply to a previous request. The response may be a Read Response with data, or simply a Target Done Response confirming a non-posted write has reached its destination.

Data Packets

Some Request/Response command packets have data associated with them. Data packet structure varies with the command which caused it:

• Sized Dword Read Response or Write data packets are 1-16 dwords (4-64 bytes)

• Sized Byte Read Response data packets are 1 dword (any byte combination valid)

• Sized Byte Write data packets are 0-32 bytes (any byte combination valid)

• Read-Modify-Write.

HyperTransport Protocol Concepts

Channels and Streams

In HyperTransport, as in other protocols, ordering rules are needed for read, posted/non-posted write transactions, and responses returning from earlier requests. In a point-point fabric, all of these occur over the same link. In addition, transactions from different devices are also merging over the same links. HyperTransport implements Virtual Channels and I/O Streams to differentiate a device's posted requests, non-posted requests, and responses from each other and from those originating from different sources.

Virtual Channels

HyperTransport defines a set of three required virtual channels that dictate transaction management and ordering:

• Posted Requests — Posted write transactions belong to this channel.

• Non-Posted Requests — Reads, non-posted writes, and flushes belong to this channel.

• Responses — Read responses and target done packets belong to this channel.

An additional set of Posted, Non-Posted and Response virtual channels is required for isochronous transactions, if supported. This dedicated set of virtual channels assist in guaranteeing the bandwidth required of isochronous transactions.

When packets are sent over a link, they are sent in one of the virtual channels. Attribute bits in the packets tag them as to which channel they should travel. Each device is responsible for maintaining queues and buffers for managing the virtual channels and enforcing ordering rules.

Each device implements separate command/data buffers for each of the 3 required virtual channels.Doing so ensures that transactions moving in one virtual channel do not block transactions moving in another virtual channel. There are I/O ordering rules covering interactions between the three virtual channels of the same I/O stream. Transactions in different I/O streams have no ordering rules (with exception of ordering rules associated with Fence requests). Enforcing ordering rules between transactions in the same I/O stream prevents deadlocks from occurring and guarantees data is transferred correctly. Based on ordering requirements, nodes may not:

• Make accepting a request dependent on the ability of that node to issue an outgoing request.

• Make accepting a request dependent on the receipt of a response due to a request previously issued by that node.

• Make issuing a response dependent on the ability to issue a request.

• Make issuing a response dependent upon receipt of a response due to a previous request.