I/O Ordering in HT Technology

Downstream I/O Ordering

Downstream ordering rules in HyperTransport are much the same as the upstream rules previously described, with a few exceptions:

1. While the same virtual channels are used (posted request, non-posted request, and response), downstream I/O streams are determined by the target of the transaction instead of the source.

2. Although UnitID uniquely identifies upstream transaction stream requests, it can't be used for this purpose in downstream requests because the UnitID field is always that of the host bridge (UnitID 0). All downstream request traffic is assumed to be part of the same transaction stream (the host bridge's).

3. The bridge bit is used to help nodes distinguish downstream from upstream response traffic. It also helps devices interpret the UnitID field in responses. Upstream responses carry the UnitID of the sender (the original target), while downstream responses carry the UnitID of the original requester. Interior nodes are only allowed to claim response packets which carry their UnitID and are moving downstream (bridge bit set = 1).

4. A host bridge (this includes the secondary interface of HyperTransport-HyperTransport bridges) which performs a peer-to-peer reflection must preserve strongly ordered sequences (non-zero Sequence ID) when it reissues them downstream. It is allowed to change the Sequence ID tag, but the same tag will be applied to all requests in the sequence.

Double-Hosted Chain Ordering

Upstream traffic and downstream traffic in HyperTransport have no ordering interaction because they are in different transaction streams. A special case arises in sharing double-hosted chains when one of the host bridges must send traffic to the other host bridge. Refer to Figure 6-14 on page 138.

1. Host bridge A sends a posted write targeting host bridge B.

2. At nearly the same time, host bridge B performs a read from host bridge A.

3. The read response/data will be travelling in the same direction as the posted write (towards host bridge B).

4. Although the posted write request is traveling downstream and the read response is traveling upstream (from the perspective of Device B), the producer-consumer ordering model requires that both must be treated as being in the same transaction stream (response will push posted write request if PassPW is clear).

5. Devices in the path can perform ordering tests on upstream responses based only on UnitID (both 0 in the case of two bridges communicating with each other), and by disregarding the direction of the requests.

6. In the event a host has its Act as Slave bit set = 1, then it won't use UnitID 0; for its requests and responses; in this case, conventional ordering based on UnitID will work.