Host Bridge Behavior
Host bridges always reside at the ends of HyperTransport chains. They never forward packets, but will have occasion to accept and reject packets. There is additional complexity caused by the responsibilities host bridges may have in supporting
chains (this is optional) and peer-to-peer transfers (required). The following sections describe host bridge behavior in accepting and rejecting packets they receive.
Directed Request With UnitID = 0
with a UnitID = 0
by the HyperTransport interface of a host bridge are inbound from the host at the other end of a double-hosted chain.
If the host bridge recipient of the request has implemented internal memory or I/O space and owns the address range
in the request, it will respond to the request as an interior node would: accepting posted requests and returning Target Done or Read responses/data for
The host bridge will similarly accept Type 0 configuration cycles carrying the proper fields if two conditions are met:
The host bridge supports double-hosted chains
The Host/Secondary Interface Command Register
bit is clear
If the host bridge does not support double-hosted chains or doesn't own the address range contained in the request, it will be rejected in a similiar way to any other end-of-chain device. Posted requests are dropped (they may be
as end-of-chain errors); non-posted requests cause the return of a Target Done or Read response with Error and NXA error bits set; for read requests, all
data is also returned with the response (driven to value of FFh).
Response UnitID And Bridge Fields
A host bridge receiving a non-posted, directed request with UnitID = 0 would also set the response Unit ID field = 0 unless it is programmed to act as the slave bridge in a double-hosted chain. If this is the case, the Host/Secondary Interface Command Register
Act As Slave
bit would be set = 1, and the bridge would set the UnitID in the response to the value programmed into its Host/Secondary Interface
Broadcast requests detected by a host bridge could only be coming from another host bridge on the other end of a double-hosted chain.
If a broadcast message is seen by a host bridge, it has already been seen throughout the chain. The host bridge accepts it, and silently
it. The specification indicates that a host bridge could
implement an internal space addressable with a broadcast message; if it does this, the message would be accepted and routed to the internal target.
Directed Request With
Directed requests with a non-zero UnitID are sourced by interior nodes and may be destined either for internal space within the host bridge (e.g. main memory) or for another device downstream (a peer-to-peer request). The host bridge
the command type and address contained in the request and routes it
. It is also possible that the request packet does not map to any internal space or device on the chain; in that case it will be rejected.
If the host bridge recipient of the request has implemented internal memory or I/O space and owns the address range targeted in the request, it will respond to the request as an interior node would: accepting posted requests and returning Target Done or Read responses/data for non-posted requests. This would be the typical behavior during DMA transfers from HyperTransport peripherals to and from main memory via the host bridge.
It is also possible that a host bridge examines the request packet address and determines that the address range is actually downstream in the HyperTransport topology. The target could either be on the same chain as the requester or on another chain if the host supports more than one. Hypertransport doesn't support direct peer-to-peer transfers and requires bridges to handle them as two separate requests (followed by two separate responses if non-posted). The sequence of events in accepting a peer-to-peer transactions include: (assume a non-posted peer-to-peer request)
An interior node issues a non-posted request. The UnitID is that of the requester; the Source tag field and Sequence ID fields are assigned by the requester from its pool of available tags.
The host bridge examines the request and determines it is peer-to-peer. It reissues the request downstream on the appropriate chain. When it does this, it changes the UnitID to 0 (its own) and changes the Source Tag and Sequence ID fields to values from its own pool of available tags. All other fields are passed through unchanged.
The host bridge
track outstanding transactions so that when the response is returned, the original UnitID and Source Tag values can be restored when the response is reissued downstream to the original requester.
Upon return of a response from the target (bridge bit is clear), the bridge sends the response downstream on the chain containing the requester with the bridge bit set = 1, and UnitID and Source Tag restored. The bridge may then retire the transaction from its outstanding request queue.
The response (and data, if any) is claimed by the original requester based on the UnitID field and the fact the bridge bit = 1. It uses the Source Tag to determine the specific transaction which has been serviced.
Compatibility Chain Requests
Another peer-to-peer possibility is that an inbound directed request from an interior node (non-zero UnitID) targets a legacy device on the compatibility chain. If the host bridge supports a compatibility chain, it may
requests that don't target any other address space to that chain. Again, it
the UnitID, Source Tag (for non-posted requests), and Sequence ID field (if non-zero) with its own values. It also sets the Compat bit in the request it sends onto the compatibility chain. This informs all devices which see it that it should be forwarded downstream to the
decoder (compatibility bridge).
If the original request was non-posted, the host bridge will again track the outstanding request so it can restore the original UnitID and Source Tag information in the response packet it sends to the original requester.
If the host bridge does not recognize the address carried by an inbound directed request from an interior node and doesn't support a compatibility chain, the packet will be rejected in a similiar way to any other end-of-chain error. Posted requests are dropped (they may be reported as end-of-chain errors); non-posted requests cause the return of a Target Done or Read response with Error and NXA error bits set; for read requests, all requested data is returned (driven to value of FFh).
Responses Received By The Host Bridge
When a response is received by a host bridge, either the bridge bit is set or it is not.
Response With Bridge Bit = 1
A response with the bridge bit set always originates at a host bridge. If one is
by a host bridge, it means that another host bridge in a double-hosted chain attempted to respond to an interior node and the node failed to claim it. In this case, it
to the end of the chain where it will be handled as an end-of-chain error by the other host bridge. The response is dropped, and the receiving host bridge may log it as an end-of-chain error. Refer to Chapter 10, entitled "Error Detection And Handling," on page 229 for a discussion of error handling.
Response With Bridge Bit = 0
Responses arriving at a host bridge with the bridge bit cleared belong to the host bridge. The Target Done or Read response/data is being returned in response to a non-posted request issued by this host. Devices are required to track all of their outstanding requests (those requiring responses), so the bridge simply uses the Source Tag field in the response to determine which transaction is being serviced. In the event a response returns with the bridge bit clear, but the response Source Tag doesn't match any outstanding transactions, the node may log the error and report it.