A Few Implementation Notes

Information Packets Not Flow-Controlled

Information packets, including NOP and Sync are not subject to flow control. When sent, they must be accepted, and are used for point-point communication between a transmitter and its corresponding receiver on a given link.

Transmitter Must Be Able To Track 15 Buffer Entries

While a receiver has the option of implementing buffers of any desired depth, including single entry buffers, each transmitter interface must implement its flow control counters such that they can track up to 15 entries in each of the six corresponding receiver flow control buffers (a four bit transmit counter will do this). If the transmitter counter is larger than that of the receiver, only a portion of it will ever be used (because NOP updates are always are based on available receiver flow control buffer entries). In the event that a transmitter implements a counter smaller than that of the receiver, the counter must "saturate" at the maximum value it can handle, and not roll over. The idea is that once the counters are initialized , they will use the maximum count that both devices can accommodate.

Sometimes Two Counters Must Be Checked

A transmitter can't issue a request packet that has data associated with it (e.g. a posted or non-posted write) without assuring the receiver has buffer entries available for both the request and the data. This is necessary because there is no receiver disconnect or retry mechanism once such a transaction starts.

NOP Packets Cannot Be Completely Blocked

The HyperTransport Specification indicates that it is the responsibility of each device to make certain that NOP update packets it sends are not starved (prevented from being sent) because of the sending of other types of traffic. If they are blocked, eventually one or more of the virtual channels may completely stall.

TheIsochronous Flow Control Option

In the event that a designer decides to provide Isochronous flow control in addition to the standard three virtual channels, each receiver interface which supports Isochronous will implement six more receiver flow control buffers and counters, and an additional set of transmitter flow control counters as well. The way the receiver determines which flow control buffer (isochronous or standard) a packet should use is determined by a bit in the request packet ( Isoc bit). If the Isoc bit is asserted in a request, it will also be asserted in the response when it comes back ” again identifying the buffer set to use.

How About NOP Updates For Isochronous Buffers?

If a device supports the Isochronous flow control buffers, it will track packet progress through these buffers in the same way as it does for non-isochronous packets it receives. As Isochronous buffer entries become available, the receiver will return NOP update packets to the other device and will set the Isoc bit in the NOP packet (byte 2, bit 5) indicating the NOP packet updates should be applied to the isochronous transmit counters.

Isochronous Traffic/Non-Isochronous Flow Control

Receivers which see request packets with the Isoc bit set, but which are not in isochronous flow control mode, do not use the dedicated isochronous flow control buffers to handle them. In this case, the standard six flow control buffers are used and NOP buffer update packets returned to the transmitter all apply to the standard transmitter flow counters. Such devices preserve the Isoc bit in both the request packet and its response as they forward it to the next device; in this way, if there is a device in the path that does support isochronous traffic, it can still be used in that portion of the topology.

Isochronous Traffic Disabled At Initialization

At initialization, all devices are disabled with respect to isochronous traffic. Software can later enable ISOC traffic on a link-by-link basis after support on both sides of the link is determined through configuration space accesses . Once enabled for ISOC traffic, each device which sees isochronous packets and supports them is expected to apply a higher priority to them than for standard virtual channel packets.