Trodden J., Anderson D. HyperTransport System Architecture / Chapter 7. Transaction Examples

Computers & Technology
Education & Reference
Business & Investing
Science & Math

HyperTransport System Architecture
Authors: Trodden J., Anderson D.
Published year: 2003
Pages: 56-57/182

<< Previous page
Table of contents
Next page >>

Chapter 7. Transaction Examples

The Previous Chapter

The previous chapter described the ordering rules which apply to packets associated with the three types of HyperTransport I/O traffic: PIO, DMA, and Peer-to-Peer. Depending on whether compatibility with the full producer-consumer ordering model used in PCI is required or relaxed ordering is permissible, attribute bits in request and response packets may be set or cleared. These bits are defined by the requester and are used by devices in the path to the target, and within the target, to enforce proper ordering. HyperTransport applies dedicated sets of ordering rules for upstream I/O traffic, downstream I/O traffic, and the special ordering required of host bridges and in double-hosted chains. Refer to Chapter 20, entitled "I/O Compatibility," on page 457 for a description of the additional ordering requirements when interfacing HyperTransport to other compatible protocols (e.g. PCI, PCI-X, and AGP).

This Chapter

In this chapter, examples are presented which apply the packet principles in the preceding chapters and includes more complex system transactions, not previously discussed. The examples include reads, posted and non-posted writes , and atomic read-modify-write.

The Next Chapter

HT uses an interrupt signaling scheme very similar to PCI's Message Signaled Interrupts. The next chapter defines how HT delivers interrupts to the Host Bridge via posted memory writes. This chapter also defines an End of Interrupt message and details the mechanism that HT uses for configuring and setting up interrupt transactions (which is different from the PCI-defined mechanisms).

Packets As Transaction Building Blocks

HyperTransport c ontrol packet types ” information, request, and response are used in various combinations to accomplish transactions. In many transactions, data packets are also used with the control packets to carry a data payload ranging from 0-64 valid bytes. Transactions start when the transmit interface of a device sends an information or request control packet. Any bridges or tunnels in the path between a requester and the ultimate target have responsibilities for forwarding any request, response, and data packets associated with the transfer in the proper direction. Note: This chapter highlights key packet fields used in the construction of HyperTransport transactions; refer to Chapter 4, entitled "Packet Protocol," on page 59 for a more complete description of HyperTransport packets and the bit fields associated with them.

Table 7-1 on page 140 summarizes the interaction between a request agent and the ultimate target of a HyperTransport transaction following the sending of various types of information and request control packets.

Table 7-1. Implications Of Sending Information And Request Control Packets

Packet Type	Command Name	Comments
Information	NOP	Used by each node transmitter to indicate the idle condition, report receiver flow control updates, and send other miscellaneous information to its corresponding receiver. These packets are not forwarded by the receiver and no response or data is associated with them.
Information	Sync/Error	Sent by each node transmitter during link synchronization or by a device enabled to report errors using the Sync flood mechanism to indicate the need for link reset and re-synchronization. During a Sync flood, each recipient re-issues the Sync packets onto all outgoing links on the chain until reset is detected . There are no response or data packets associated with a Sync packet.
Request	Sized Write (Posted) dword or byte transfers OK	A posted sized write is used to initiate a write transfer of dwords or bytes of data to a target. For dword writes , the 1-16 dword data packet immediately follows the write request. For byte writes, a single dword "byte mask" precedes a data packet of 1-8 dwords (containing up to 32 valid bytes). No response is ever returned to a posted write and devices in the target path may deallocate buffers as soon as the request and data are forwarded.
Request	Sized Write ( Non-Posted ) dword or byte transfers OK	A non-posted sized write is also used to initiate a write transfer of dwords or bytes of data to a target. For dword writes, the 1-16 dword data packet immediately follows the write request. For byte writes, a single dword "byte mask" precedes a data packet of 1-8 dwords (containing up to 32 valid bytes). The Target Done response will be sent when the write completes (either by the target or by an EOC device). Bridges in the target path must track outstanding non-posted write requests until the target done response is returned.
Request	Broadcast Message	Broadcast messages originate at the host bridge, and are accepted and propagated downstream on all links by each device which sees them. As they are posted requests, there is no response and devices in the target path may deallocate buffers as soon as the broadcast message request is forwarded.
Request	Sized Read dword or byte transfers OK	A sized read is used to initiate a read transfer of dwords or bytes from a target. For byte reads, a single dword of data is returned immediately after the read response. For dword reads, 1-16 dwords are returned immediately after the read response. Bridges in the target path must track all outstanding read requests until the read response and data are returned.
Request	Flush	Issued by a requester to force its preceding posted writes in the same transaction stream to the Host Bridge. This is a non-posted request and the Host Bridge returns a Target Done Response when the flush of all previous posted writes for this source is completed to memory (or to the destination chain in a peer-to-peer transaction). Bridges in the target path must track outstanding Flush requests until the Target Done Response is returned. There is no data packet associated with the Flush.
Request	Fence	Issued to force the host bridge to place a barrier between previous and subsequent posted writes in all transaction streams. The Host Bridge will push previous writes for all streams to memory before allowing any subsequent posted writes with( PassPW clear) to be processed . Unlike Flush, this command is posted. There will be no response; devices in the target path may deallocate buffers as soon as Fence request is forwarded. There is no data packet associated with the Fence.
Request	Atomic RMW	Issued by a requester seeking to perform a read-modify-write of a memory location in a single transaction. This hybrid request causes a transaction made up of a non-posted write operation followed by a read response with data. There are two variants of Atomic RMW (Fetch & Add and Compare & Swap.) Because Atomic RMW requests are always non-posted, bridges in the path must track outstanding Atomic RMW requests until the response/data are returned.
Response	Read Response	Issued by a target when it is ready to either return previously requested read data (see Sized Read and Atomic RMW requests) or an error indication that the request did not complete properly. The read response immediately precedes read data being returned by the target. If an error occurred, the requested amount of data is returned anyway; response error bits will indicate that it is not valid and whether the response was sourced by the original target or an end-of-chain device.
Response	Target Done Response	Issued by a target to confirm the completion of an earlier non-posted write or Flush request. There is no data packet associated with a Target Done response. If an error occurred in completing the original request, the target done response error bits indicate the failure and whether it occurred at the original target or the request was inadvertently sent to an end-of-chain device.