Example 3: Posted Byte Write Request

Example 3: PostedByte Write Request

The Host Bridge in Figure 7-5 on page 157 is targeting I/O address space in Device 2 (UnitID2) with a posted, sized (byte) write of three bytes.

Figure 7-5. Posted WrSized (Byte) Write Targeting A Downstream Device

Example 3: WrSized (Byte) Request Packet Setup

(Refer to [1] in Figure 7-5 on page 157 )

Command[5:0] Field (Byte 0, Bit 5:0)

This is the sized write (WrSized) control packet command code. The option bits within this field: the posted (bit 5), dword (bit 2), Isoc (Bit 1), and coherency (bit 0) are all (cleared = 0), meaning the request is non-posted , uses byte data size, travels in the standard virtual channels, and coherence is not required. For this example, field = 10 000 b.

SeqID[3:0] Field (Byte 0, Bit 7:6) and (Byte 1, Bit 6:5)

This field tags groups of requests that were issued as part of an ordered sequence. This field is cleared to indicate a request is not part of a sequence. For this example, field = 0000b.

UnitID[4:0] Field (Byte 1, Bits 4:0)

For all requests, this field is programed with the UnitID of the requester. In this example, the request originates at the Host Bridge (UnitID 0) For this example, field = 00000b.

PassPW Bit Field (Byte 1, Bit 7)

This bit indicates whether this packet may pass packets in the posted request channel (for same transaction stream). For full producer/consumer ordering model, this bit is cleared. For this example, field = 0b.

SrcTag[4:0] Field (Byte 2, Bits 4:0)

This field tags the 32 outstanding non-posted transactions allowed to each UnitID. This field is reserved and set = 0 for posted requests. For this example, field = 00000b.

Compat Bit Field (Byte 2, Bit 5)

Used by bridges to tag downstream requests targeting the compatibility chain (where a subtractive decoder may be found). Cleared in this case because target is not on the compatibility chain. For this example, field = 0b.

Mask/Count[3:0] Field (Byte 2, Bits 7:6 and Byte 3, Bits 1:0)

The sized (byte) write command can transfer any combination of bytes within the 32-byte address aligned group which contains the starting address. The value programmed in the Mask/Count field represents the dwords actually sent in the data packet; the value is "the span of dwords in a 32-byte address aligned group from the first one containing a valid byte to the last dword in the group containing a valid byte". This value ranges from 1 (1 dword data plus the 1 dword mask) to 8 (8 dwords plus the 1 dword mask). In our example, all three valid bytes reside in the same dword, the Mask/Count[3:0] is set = 1 (1 dword plus the dword mask). For this example, field = 0001b.

Start Address Field (Bytes 4-7, Bit 7:0) and Byte 3, Bit 7:2)

This field sets up the 40-bit target start address of the dword containing the first byte to be written. Note that the lower bits [1:0] are not in the field, and are assumed to be = 00b. For this example, the target address is in the I/O address portion of the system memory map. For this example, the 40-bit start address = FDFC0A0104h. The specific addresses bytes to be written are: FDFC0A0104h, FDFC0A0105h and FDFC0A0107h (note the skipped byte).

Example 3: Sized (Byte) Write Data Packet And Mask

(Refer to [2] and [3] in Figure 7-5 on page 157)

All Sized (Byte) Writes include a 32 bit (1 dword) mask which precedes the data packet and qualifies each of the 32 bytes (contained in 8 dwords) allowed to be written in one of these transactions. There is a one-to-one correspondence between the dword mask bits and the 32 bytes which may be transferred (mask bit 0 qualifies byte 0, etc.). In the event that less than 32 bytes are to be written, it isn't necessary to send dwords below the first dword with a valid byte or above the last dword with a valid byte. This eliminates the need to send 31 bytes of "don't care" data to send one valid byte. The start address, transfer count (in dwords), and the byte mask are used by the target of the request to determine the bytes of interest within the address-aligned, 32 byte group.

In this example, the WrSized (byte) write is updating three bytes within a single dword. Because of this, only one dword of data (plus the dword mask) must be sent. The starting address bits 4:2 determine the dword containing the three valid bytes (dword 1 in this example). Mask bits 7:4 qualify the bytes within dword 1, and the three mask bits corresponding to the target addresses are enabled: bits 4, 5, and 7. The mask bit for the one invalid byte in dword 1 and the mask bits for all of the unsent dwords are all cleared. (Refer to [2] in Figure 7-5 on page 157). Note: Because the start address does not contain bits 1:0 (is always dword aligned), it is only the mask bits which provide the byte resolution needed. Basically, the two least significant address bits(1:0) are represented by the first valid mask bit in the target dword. The data values written to the three target addresses in this example transaction are: FDFC0A0104h = AAh; FDFC0A0105h = 55h; FDFC0A0107h = D4h.

Example 3: WrSized (Byte) Request, Sequence Of Events

(Refer to Figure 7-5 on page 157)

1. The Host Bridge checks its transmitter posted request (CMD ) and posted request (Data) flow control counters to make sure it has "credits" before issuing the request.

2. The Host Bridge transmitter sends the request packet information. On this eight bit interface, the transmitter sends one byte of request packet info during each successive bit time and the CTL signal is asserted during the request transfer. After 8 bit times, it deasserts CTL and commences sending the dword byte mask over the next 4 bit times, followed by the single dword of data (containing three valid bytes) during the final 4 bit times.

3. When the tunnel receives this request and mask/data, it will first decode the request to make sure it is not the intended target. In this case, the address does not match its own and it will prepare to reissue the packets downstream, unchanged.

4. When UnitID2 receives the request and mask/data, it will decode the command and target address in the request. It then uses the byte mask information and the start address it received to determine the actual three bytes it should update internally.

A Couple Of Notes About WrSized (Byte)

The main use of the WrSized (byte) command is to provide compatibility with PCI write cycle byte enables which allows:

• writes to individual bytes in the system address map

• burst writes to discontinuous memory mapped I/O locations.

The HyperTransport WrSized (Byte) byte mask permits writing any combination of bytes within a 32 byte address-aligned group.

Most of the bulk write transfers in HyperTransport would be done using the WrSized (dword) commands instead of this one because larger transfers are possible (16 dwords) and because most writes can be done in blocks with all target addresses in the block being valid. This eliminates the need for a "write mask" such as the sized (byte) write transaction uses, but is restricted to dword data objects and to writing all locations in the block which is sent.