Packet Routing: Shared Bus vs. Point-Point Topology

Packet Routing: Shared Bus vs. Point-Point Topology Routing information in a shared bus topology such as PCI or PCI-X is somewhat simpler than in a point-point topology such as HyperTransport. Shared Bus Routing Referring to the PCI/PCI-X shared bus example illustrated in , it should be clear that if a transaction appears on the shared bus, all devices "see it" and have an opportunity to decode the address and command and claim the cycle. Devices other than bridges have no responsibilities for routing information to their neighbors. Also note that arbitration on a shared bus is simple because a single arbiter can manage the entire bus. In PCI/PCI-X, the arbiter is typically in the bus Host Bridge; the arbiter considers requests from each master, then grants the bus to each in turn, hopefully applying a reasonable fairness algorithm. HyperTransport Point-Point Routing In contrast to the shared bus approach, the HyperTransport topology distributes responsibility for routing and forwarding packets among all devices, with the exception of single-link end (cave) devices. For example, the tunnel peripheral device in Review Of Packet Types And Formats How a packet is routed depends in large part on the type of packet it is. Each packet in HyperTransport is a multiple of four bytes in size, and the specification divides packets into two types: control and data. All control packets contain a Command Type field in the first byte which identifies which type of control packet it is and the format of the remaining packet fields to follow. It also indicates whether data packets follow immediately (writes), will return later (reads), or are not required. Control Packets Control packets are sent across a link to initiate specific tasks; they contain information fields used for several purposes: address decoding, virtual channel and transaction stream management, error reporting, and routing. Devices perform routing functions by extracting information from key fields in control packets. Control packets are further divided into three groups: information, requests, and responses. Information Packets: No Routing Required Information packets include NOP and Sync/Error. These four-byte packets are used for communication between two ends of a link interface. When issued by a transmitter, they are always accepted by the corresponding receiver; they are never forwarded to another link. This means that are no routing issues associated with them. These two packet types will not be discussed further in this chapter. Request Packet Routing Information Request packets are used to initiate various transactions and control operations. Packet format depends on the request type; four byte request packets are sent when no address field is needed; eight byte requests are sent otherwise. Data Packet Routing Depends On Control Packets Because data packets are always accompanied by a control packet (request or response), they do not contain any routing information of their own. The control packet indicates the size of the data packet payload, the virtual channel it travels in, whether it is bytes or dwords, where it is going, and even whether it is valid or not. For this reason, data packets are not mentioned much in the packet routing discussion that follows; they are assumed to be immediately behind the control packets which accompany them. Directed vs. Broadcast Requests HyperTransport defines two classes of requests: directed and broadcast. Directed requests travel in the posted or non-posted virtual channel, and always target a particular device. The request destination is indicated either by the address field (e.g. RdSIzed and WrSized requests), or is implied in the request type (Flush and Fence commands target the host bridge). Directed requests move through the chain until they reach the target device and are absorbed. Devices in the path of a directed request forward it to the next device in the direction of the target. Broadcast requests are issued by bridges and travel in the posted virtual channel. They are accepted by each node then forwarded downstream on all links. When the broadcast request reaches an end-of-chain device, it is absorbed and dropped.