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 . Figure 11-2 on page 260 depicts a generic eight byte RdSized or WrSized request packet and the key fields used in request packet routing.

Figure 11-2. Generic WrSized Or RdSized Request Packet: Key Routing Fields

graphics/11fig02.jpg

Table 11-1. Definitions Of Request Packet Fields Used In Routing

Byte

Bit

Function

5:0

Command Type Code . This code indicates the request type.

1

4:0

UnitID. This is the UnitID (0-31d) of the requester

2

5

Compat. This bit is set by bridges in downstream request packets targeting the system subtractive decode device (e.g. compatibility bridge) residing on the system "compatibility chain."

3

4-7

7:2

7:0

Start Address[39:2] The dword-aligned, 40 bit target start address.

Refer to the HyperTransport address map for address use.

Six Request Types

HyperTransport supports six request command types. Most have a number of variants. The following table summarizes each request, the number of bytes in the packet, the Command Code (Byte 0, Bits 5:0 of the request packet), and notes about its use.

Table 11-2. Request Packet Command Code Summary

Command Name

Packet Size

CMD Code

Comments

Broadcast Message

[Always Posted]

4 Bytes

111010b

Originate at host bridges and travel downstream. All devices accept them and propagate them downstream onto all links. EOC device accepts message and drops it.

Sized Read (RdSized)

[Always non-posted ]

8 Bytes

01xxxxb

May be issued by any device. Read response is returned. Use of "xxxx" option bits:

[3] = response may pass (if 1)

[2] = dword/byte (1 = dword)

[1] = Isoc channel (1 = Isoc)

[0] = Coherency (1 = Req'd)

Sized Write (WrSized)

[Posted or Non-posted]

8 Bytes

x01xxxb

May be issued by any device. Use of "xxxx" option bits:

[5] = posted req (1 = posted)

[2] = dword/byte (1 = dword)

[1] = Isoc channel (1 = Isoc)

[0] = Coherency (1 = Req'd)

Flush

[Always non-posted]

4 Bytes

000010b

Forces all preceding posted writes in same transaction stream to host bridge.

Fence

[Always posted]

4 Bytes

111100b

Barrier to subsequent posted writes from all streams (except Isoc) until all previous posted writes complete.

Atomic Read-Modify-Write

[Always non-posted]

8 Bytes

111101b

Hybrid read and write command for modifying a memory location atomically.

Response Packet Routing Information

Response packets are used in the completion of non-posted transactions. There are two types, Read response and Target Done response. Read responses are returned by the target of an earlier read or Atomic RMW request to indicate which transaction has been serviced, how much data immediately follows , and whether an error occurred in fetching the data.

The Target Done response is returned by the target of an earlier non-posted write or Flush request. No data accompanies this response; it is returned simply to report if the requested operation completed successfully or not.

The four byte packet format is different for a Read vs. Target Done response. Figure 11-3 on page 262 shows a generic Read/Target Done response packet and the key fields used in response packet routing.

Figure 11-3. Generic Read/Target Done Response Packet: Key Routing Fields

graphics/11fig03.jpg

Table 11-3. Definitions Of Response Packet Fields Used In Routing

Byte

Bit

Function

5:0

Command Type Code . This code indicates the response type.

1

5

UnitID. In downstream responses, this field is UnitID of the original requester. In upstream responses, this is the UnitID of the bridge (0).

1

6

Bridge. This bit is set by bridges to indicate a response is traveling downstream. Non-bridges may only claim responses with this bit set.

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.



HyperTransport System Architecture
HyperTransportв„ў System Architecture
ISBN: 0321168453
EAN: 2147483647
Year: 2003
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net