Example 7:Fence Request Problem: Device 3 (UnitID3) in Figure 7-9, issues a Fence request to provide a barrier between previous and subsequent posted writes ; it applies to all I/O streams and virtual channels (except isochronous). Figure 7-9. A Fence Request Issued By UnitID 3  Example 7: Fence RequestPacket Setup (Refer to Figure 7-9 on page 179) Command[5:0] Field (Byte 0, Bit 5:0) This is the Fence request command code. There are no option bits within this field. For this example, field = 111100b. 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. Fence requests are never part of an ordered sequence, so this bit should be cleared. Setting SeqID[3:0] to a non-zero value may have indeterminate results. 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. In this example, the request originates at Device 3 (UnitID3). For this example, field = 00011b. PassPW Bit Field (Byte 1, Bit 7) This bit should be cleared in a Fence request so that the request will perform its intended function: pushing earlier posted writes for all transaction streams ahead of it. Setting this bit = 1 may have indeterminate results. For this example, field = 0b. Example 7: Fence Request, Sequence Of Events (Refer to Figure 7-9 on page 179) -
After UnitID3 checks its transmitter Posted Request (CMD ) flow control counter for credits, the transmitter interface asserts CTL and starts sending out the Fence request packet information. On this eight bit interface, the transmitter sends one byte of request packet info during each successive bit time, least significant byte first. -
When the tunnel receives this Fence request, it will check its own transmitter Posted Request (CMD) flow control counter for the upstream link and prepare to reissue the request towards the host bridge. -
When the host bridge receives the Fence request, it creates an "internal barrier" which guarantees that any subsequent non-isochronous posted writes (from any transaction stream) will not be able to pass any posted writes which arrived prior to the Fence request. Note: normally, there are no ordering rules between transactions belonging to different transaction streams; Fence creates an exception. A Few Notes About Fence Operations -
Fence requests are intended to act as a barrier between posted writes. It is different from Flush in that it applies to all transaction streams (all UnitIDs). It also travels in the posted virtual channel, meaning that, unlike Flush, there will not be a response to this request. It also means that there is no source tag (SrcTag[4:0]) field required for Fence. -
If isochronous flow control mode is not supported on a link, isoc packets travel in the standard virtual channels and are affected by the Fence command. -
Fence requests are only sent from devices to host bridges, or from one host bridge to another. Tunnels are not required to take any special action with a Fence other than to forward it in the direction it is already moving. -
If a Fence request mistakenly reaches an end-of-chain device, it is required to decode the command and then drop it (no response is required). This may be logged as an end-of-chain error if the end-of-chain device is programmed to handle it that way. Refer to "End-Of-Chain Errors" on page 243 for a discussion of error handling by end-of-chain devices.  |
