Example 9: WrSized Request Crosses A Bridge | HyperTransportв„ў System Architecture

Problem: Device 2 (UnitID2) in Figure 7-11 on page 189 targets main memory with a non-posted sized (dword) write of one dword. The non-isochronous transaction must cross a HyperTransport-HyperTransport bridge; there is no coherency requirement.

Figure 7-11. Sized (Dword) Write Transaction Must Cross A Bridge

graphics/07fig11.jpg

Example 9: Request Packet On Bus 1

(Refer to [1] in Figure 7-11 on page 189)

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

This is the sized write (WrSized) command code. Assume dword (bit 2) is enabled; the posted (bit 5), Isoc (bit 1), and coherency (bit 0) bits are all disabled (0). This indicates a non-isochronous, non-posted sized (dword) write with no cache coherency requirement. For this example, field = 10 100 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)

This field is programmed with the UnitID of the requester. For transactions which move through a bridge, the UnitID and SrcTag fields in an incoming request are tracked internally and are replaced by those of the bridge as it reissues the request on the next bus. For bus 1, the UnitID of the requester is two. 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 (for same transaction stream). For this example, field = 0b.

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

All non-posted requests require a source tag (0-31d); the value is assigned by UnitID2 from a pool of available tags. Assume that tag 3 is the one to be used for this request. For this example, field = 00011b.

Compat Bit Field (Byte 2, Bit 5)

Used by bridges to tag downstream requests. Cleared here. For this example, field = 0b.

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

In this example, a single dword transfer is being done and the value programmed into this field should be dword count -1, which is zero. For this example, field = 0000b.

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

This field carries the 40-bit target start address. For this example, the target address is in the main memory portion of the system memory map. For this example, the 40-bit address = 0004810008h.

Example 9: Sized (Dword) Write Data Packet: Bus 1

In this example, one dword is to be written to memory. This is reflected in the transfer count in the Mask/Count[3:0] field above (0). In a sized (dword) write transaction, data transfer immediately follows the request.

For this example, assume the following dword value is to be written:

Dword = 12345678h

Example 9: Request/Data Sequence Of Events On Bus 1

(Refer to Figure 7-11 on page 189)

UnitID2 on bus 1 checks its transmitter Non-Posted Request (CMD ) and Non-Posted Request (Data) flow control counters to make sure it has "credits" in both before issuing the request.
The transmitter asserts the CTL signal and starts sending out the request packet information on its eight bit interface. After 8 bit times, it has finished sending the request and commences sending the dword data packet; the CTL signal will be deasserted during this time.
When the bridge receives this request and data, it checks the target address and recognizes it is upstream; it prepares to reissue the request on bus 0.

Example 9: Bridge Reissues Request Packet: Bus 0

(Refer to [2] in Figure 7-11 on page 189)

Note : When the bridge re-issues a request packet onto a new bus, it substitutes its own transaction stream information into the request's UnitID and Source Tag fields. It does this because transaction stream ordering is on a "per-bus" basis; the bridge is host (UnitID 0) on bus 1, but is simply UnitID 1 on the upstream bus (bus 0). If a response is required, the bridge will "remember" the transaction stream information it replaced in the request so it can be restored when the response is later driven onto the source bus. Except for UnitID and Source Tag, the bus 0 request packet fields are the same as on bus 1.

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

The bridge issues the same command (with option bits) as it received in the request from bus 1. This is a non-isochronous, non-posted sized (dword) write with no cache coherency requirement. For this example, field = 10 100 b.

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

This field is used to tag 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)

This field is programmed with the UnitID of the requester, which on bus 0 is UnitID 1. For this example, field = 00001b.

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 this example, field = 0b.

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

This value is assigned by the bridge from its pool of available tags. Assume that the bridge's next available tag for non-posted requests it issues onto bus 0 is seven. For this example, field = 00111b.

Compat Bit Field (Byte 2, Bit 5)

Used by bridges to tag downstream requests. Cleared here. For this example, field = 0b.

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

The count field is copied from the original; this example is a single dword transfer and the counter is loaded with dword count - 1. For this example, field = 0000b.

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

This field is also copied over from the original request. For this example, the 40-bit address = 0004810008h.

Example 9: Sized (Dword) Write Data Packet: Bus 0

(Refer to [2] in Figure 7-11 on page 189)

In this example, one dword is to be written to memory. The single dword data packet that accompanied the request on bus 1 is simply repeated on bus 0.

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

Dword 0 = 12345678h

Example 9: Request/Data Sequence Of Events: Bus 0

(Refer to Figure 7-11 on page 189)

The Host Bridge (UnitID1 on bus 0) 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 Host Bridge bus 0 transmitter interface asserts the CTL signal and starts sending out the request packet information on its eight bit interface. After 8 bit times, it has finished sending the request and commences sending the dword data packet; the CTL signal will be deasserted during this time.
When the bridge receives this request and data, it checks the target address and performs the non-posted write of the single data dword to memory. It then prepares to send a Target Done Response downstream.

Example 9: Response Packet On Bus 0

(Refer to [3] Figure 7-11 on page 189)

Because this is a non-posted sized (dword) write transaction, the Host Bridge owes the requester a confirmation response indicating the transfer is complete. This information is returned in a four-byte Target Done response packet. The UnitID and Source Tag information contained in the bus 0 response packet will belong to the HT-to-HT bridge bus 0 interface. It will be the HT-to-HT bridge's responsibility to restore the original transaction stream information before forwarding the response packet to the next bus (bus 1).

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 will be cleared because isochronous traffic was not enabled in the request. For this example, field = 1b.

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

For downstream responses, this field contains the UnitID if the requester. In this example, it will contain UnitID 1 (the HT-to-HT bridge bus 0 interface). For this example, field = 00001b.

Bridge Bit Field (Byte 1, Bit 6)

Set by host bridges in responses they issue downstream (such as this example). For this example, field = 1b.

PassPW Bit Field (Byte 1, Bit 7)

This bit will be cleared because passing was not enabled in the request. For this example, field = 0b.

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

Programmed with the Source Tag provided by the HT-to-HT bridge (7). For this example, field = 00111b.

Error Bit Field (Byte 2, Bit 5)

Cleared in this example. For this example, field = 0b.

NXA Bit Field (Byte 3, Bit 5)

Cleared in this example. For this example, field = 0b.

Example 9: Response, Sequence Of Events On Bus 0

(Refer to Figure 7-11 on page 189)

Once it has the Response (CMD) flow control credits, the Host Bridge transmitter asserts the CTL signal and sends the four byte Target Done response onto Bus 0.
When the HT-to-HT bridge receives the response from the Host Bridge, it checks the Bridge bit and UnitID (1) to determine if the response belongs to it (it does). The HT-to-HT bridge then attempts to match the Source Tag field in the response to one of the entries in a table of outstanding requests it has been tracking.
Using its Source Tag, it locates the original transaction stream information for the device on bus 1 which made the request. It then prepares to forward the response onto bus 1 with the original transaction stream information (UnitID and Source Tag) restored.

Example 9: Response Packet On Bus 1

(Refer to [4] Figure 7-11 on page 189)

The HT-to-HT bridge forwards the response packet onto bus 1. With the Bridge bit set and the original UnitID (2) and Source Tag (3) restored, the response will be claimed by the original requester.

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 will be cleared because isochronous traffic was not enabled in the request. For this example, field = 1b.

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

Restored by the HT-to-HT Bridge to the value provided by the original requester (2). 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). For this example, field = 1b.

PassPW Bit Field (Byte 1, Bit 7)

This bit will be cleared because passing was not enabled in the request. For this example, field = 0b.

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

Restored by the HT-to-HT bridge with the Source Tag provided by the UnitID2 (3). For this example, field = 00011b.

Error Bit Field (Byte 2, Bit 5)

Cleared in this example. For this example, field = 0b.

NXA Bit Field (Byte 3, Bit 5)

Cleared in this example. For this example, field = 0b.

Example 9: Response, Sequence Of Events On Bus 1

(Refer to Figure 7-11 on page 189)

Once the HT-to-HT bridge has prepared the response to be driven onto bus 1 (with the original UnitID and Source Tag restored), it asserts the CTL signal and sends the four byte Target Done response onto Bus 1.
When UnitID 2 receives the response from the HT-to-HT Bridge, it checks the Bridge bit and UnitID to determine if the response belongs to it (it does). UnitID 2 then attempts to match the Source Tag field in the response (this is the source tag it sent with its request) to one of the entries in a table of outstanding requests it has been tracking.
Using its Source Tag, it locates the pending transaction and retires it. If there had been an error on either bus, the Error bit (and possibly the NXA bit) in the response would have ben set.