| A packet is accepted by a device if certain fields indicate it is the intended recipient. For directed requests or responses, this will be the end of packet travel. For broadcast requests , the packet is consumed and passed downstream to the next device. Rules For Acceptance A node will accept ( consume ) an incoming packet if any of the following conditions are met. -
The packet is a broadcast request (determined from the command type) -
The packet is a directed request which carries a UnitID = 0 (coming from a bridge), the compatibility bit is clear (only subtractive decoders may claim a request if compatibility bit is set), and the address is owned by this node. -
The packet is a directed request which carries a UnitID = 0 (coming from a bridge), the compatibility bit is set (only the subtractive decoder may claim this request), and this node is the subtractive decoder or a bridge to it. -
The packet is a response with the bridge bit set (traveling downstream from a bridge), and the UnitID field matches that of the node. -
Because of double-hosted chain topologies, tunnels must be able to accept downstream packets from either link. A Note About TheSubtractive Decoder In the rules for packet acceptance, an allowance is made in HyperTransport for a "compatibility chain". If implemented, this chain would host the system subtractive decode device (e.g. compatibility bridge) which is responsible for handling transactions to legacy devices. Often, these devices do not support plug and play addressing and the system may not be aware of the address ranges they are using. When the host bridge targets such devices, it sets the Compat bit in the request which indicates that: -
No device, other than the subtractive decoder, is allowed to claim the request packet ” regardless of the address it carries. -
Bridges in the path to the subtractive decoder must reissue the request onto the proper downstream link. -
The subtractive decode device must accept the request on behalf of the legacy devices it supports.  |
