Example 2: Non-Posted WrSized (Dword) Transaction

Problem: Device 2 (UnitID2) in Figure 7-4 on page 150 targets main memory with a non-posted, isochronous, sized (dword) write of two dwords.

Figure 7-4. DMA Non-Posted Write Targeting Main Memory

graphics/07fig04.jpg

Example 2: WrSized (Dword) Request Packet Setup

(Refer to [1] in Figure 7-4 on page 150)

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

This is the sized write (WrSized) command code. There are several option bits within this field (see underlined bits below). Assume dword (bit 2) and Isoc bits (bit 1) are enabled; the posted (bit 5) and coherency (bit 0) bits are disabled (cleared = 0). This indicates an isochronous, non-posted sized (dword) write with no cache coherency requirement. For this example, field = 10 110 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 from a single UnitID. 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 both upstream and downstream requests, this field is programmed with the UnitID of the requester. UnitID is assigned during initialization by configuration software; a device may consume more than one UnitID ” meaning it can own more than one transaction stream. In this example, the request originates at Device 2 (UnitID2). For this example, field = 00010b.

PassPW Bit Field (Byte 1, Bit 7)

This bit indicates whether this packet may pass packets in the posted request channel. Cleared for full producer/consumer ordering model. 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. All reads, non-posted writes , Atomic RMW, and Flush requests in a particular transaction stream must have a unique source tag; the value is assigned by the requester from a pool of available tags. Assume that tag 5 is the one to be used for this request. For this example, field = 00101b.

Compat Bit Field (Byte 2, Bit 5)

Used by bridges to tag downstream requests targeting the compatibility chain (where subtractive decoder is found). Reserved field for upstream requests. For this example, field = 0b.

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

Interpretation of this field depends on whether byte or dword data size option was selected in Command field (bit 2). In this case, a two dword transfer is being done and the value programed into this field should be dword count -1. For this example, field = 0001b.

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

This field sets up the 40-bit target start address. Note that the lower bits [1:0] are not in the field, and are assumed to be = 00b. This means that the start address is dword-aligned. For this example, the target address is in the main memory portion of the system memory map. For this example, the 40-bit address = 00030A0910h.

Example 2: WrSized (Dword) Transaction Data

(Refer to [2] in Figure 7-4 on page 150)

Because this is a WrSized (dword) command, 1-16 dwords may be transferred. In this example, two dwords are to be written to memory. This is reflected in the transfer count in the Mask/Count[3:0] field above. In a sized (dword) write transaction, data transfer immediately follows the request, starting with least significant dword. Two restrictions on dword data packets:

All transfers must be multiples of whole dwords (1-16).
All addresses within the range defined by the start address to the start address plus the transfer count are considered valid for the transfer, so there is no byte mask with a sized (dword) write data packet.

For this example, assume the following dword values are to be written:

Dword 0 = D4C3B2A1h
Dword 1 = 12345678h

Example 2: WrSized (Dword) Request Sequence Of Events

(Refer to Figure 7-4 on page 150 )

UnitID2 checks its transmitter Isochronous Non - Posted Request (CMD ) and Isochronous Non-Posted Request (Data) flow control counters to make sure it has "credits" in both before issuing the request.
The transmitter starts sending out the request packet information (see [1] in Figure 7-4). On this eight bit interface, the transmitter sends one byte of request packet info during each successive bit time (there are two bit times per clock). During the request packet transmission, the CTL signal is asserted and the least significant bytes are sent first. After 8 bit times, it has finished sending the request and commences sending the data packet (see [2] in Figure 7-4). It will take 8 bit times to send the 2 dwords of data over this 8 bit interface, and CTL will be deasserted during this time.
When the tunnel receives this request and data, it will check its own transmitter flow control counters for the upstream link and prepare to reissue the request towards the host bridge. If the tunnel supports isochronous traffic, it will give the transaction priority and use the isochronous non-posted virtual channels for both the request and data as well as the subsequent response; if not, it uses the standard virtual channels. The packet formats will remain the same in either case.
When the host bridge receives the request and data, it will check the target address and command in the request. Because the coherency bit (Command field, bit 0) is not set, the bridge is allowed to schedule the write to main memory without checking for coherency with caches located in the CPU or elsewhere. If the host supports isochronous traffic, it will give this traffic priority over other HyperTransport traffic it may be processing.
Once the write is complete to memory, the host bridge prepares to initiate a Target Done response to the original requester (UnitID2).

Example 2: The WrSized (Dword) Response Packet

(Refer to [3] in Figure 7-4 on page 150)

Because this is a non-posted sized (dword) write transaction, the target owes the original requester a confirmation response indicating the transfer is complete. This information is returned in a four-byte Target Done response packet initiated by the original target if the request arrived properly. In the event the request was not claimed by the original target, the Target Done response will be sourced by the end-of-chain device which unexpectedly decodes the unclaimed request. Two bits in the response packet described below, Error and NXA, are used to indicate whether an error occurred and if it is being reported by the original target or the end-of-chain device. In setting up a response packet, the sender uses several of the fields which were encoded in the original request; this is mainly to assure that the response finds its way back to the original requester and travels in the proper virtual channel and transaction stream as it returns.

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

This is the command code for the Target Done response. There are no option bits in this field. For this example, field = 110011b.

Isoc Bit Field (Byte 0, Bit 7)

This bit indicates whether this response should travel in the isochronous response virtual channel as it moves back to the original requester. Because the request which caused this response was isochronous, this bit will automatically be set in the response. Any devices in the path of the response which support isochronous traffic will give this packet priority; any that don't support isochronous traffic will route it through standard virtual channels. For this example, field = 1b.

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

For responses, there are two ways this field is handled. If the response is traveling upstream, it is always programmed with the UnitID of the bridge (UnitID0). If the response is traveling downstream (as this one is), the UnitID field contains the Unit ID of the original Requester and is used much like an address to help route the response to the proper device. For this example, field = 00010b.

Bridge Bit Field (Byte 1, Bit 6)

Set by host bridges in responses they issue downstream (such as this example). Devices use this information to decide if they may attempt to decode and claim a response; only downstream responses may be claimed by non-bridges. Upstream responses must be forwarded by tunnels in the direction they are already moving. For this example, field = 1b.

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). Because the PassPW bit was not set in the original request, it won't be set here either. For this example, field = 0b.

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

Used to tag the 32 outstanding non-posted transactions allowed to each requester UnitID. Whatever tag was assigned in the original request will also be inserted in this response field. In our example, the Source Tag was 5. For this example, field = 00101b.

Error Bit Field (Byte 2, Bit 5)

In a non-posted write transaction, this bit in the response will be set to indicate an error was encountered in the delivery of data. When the response finds its way back to the original requester, this bit means that the data was not delivered; action taken by the requester is design-specific, but may range from an interrupt to a sync flood. Refer to "Response Errors" on page 248 for a discussion of how response errors are handled in HyperTransport. For this example, field = 0b.

NXA Bit Field (Byte 3, Bit 5)

This response bit is only valid if the Error bit (Byte 2, Bit 5) is set. IF NXA and Error are both set, the original request did not find the proper target at all, and the response is being returned by a device at the end of the chain. If NXA is clear and Error set, the error occurred at the target device. For this example, field = 0b.

Example 2: WrSized (Dword) Response, Sequence Of Events

(Refer to Figure 7-4 on page 150)

Because the request that caused this response was isochronous, the Host Bridge also uses the isochronous virtual channel to send the response back (if it supports isochronous channels). Otherwise it uses the non-isochronous response virtual channel.
The Host Bridge transmitter sends one byte of the four byte response packet during each successive bit time on its 8-bit interface. The CTL signal is asserted during the transmission of the response, and the least significant byte is sent first (see [3] in Figure 7-4).
When the tunnel receives the response from the Host Bridge, it checks the Bridge bit and UnitID to determine if the response belongs to it; a non-bridge is only allowed to claim responses moving downstream (Bridge bit set = 1) and carrying the proper UnitID. In this case, the UnitID = 2, so the tunnel forwards the response downstream intact ” again using the virtual channel if it is supported.
When the response reaches Device 2 (UnitID (2) it is decoded and claimed. The SrcTag[4:0] field is used to identify the particular outstanding request this response is associated with (in this case, transaction #5).