The Need To And Data Packets


The Need To Interleave Control And Data Packets

An important feature of HyperTransport packet management is that a transmitter may interleave control packets with data packets associated with earlier requests . Interleaving control packets with data helps mitigate "stalls" in sending new control packets on the multiplexed CAD bus when large data transfers are in progress. An example of such as stall is as follows :

  1. A transmitter starts a Sized Dword Write of 64 bytes (16 dwords) on a 2-bit HyperTransport link interface.

  2. After the write transaction commences, the transmitter realizes it needs to send a read request or NOP information packet over the bus.

  3. Without the ability to interleave control packets, the transmitter would have to send the entire data payload first (64 bytes x 4 bit times/byte = 256 bit times). This represents a worst-case latency of 128 clocks to start sending the new control packet.

To avoid such situations, HyperTransport allows a transmitter to insert new control packets into a data payload on four byte boundaries, as long as the control packets do not have any immediate data of their own. For example, read requests and NOP flow control packets are candidates for interleaving; write requests would not be candidates for interleaving because they are accompanied by immediate data.

The CTL Signal Indicates Packet Type

A transmitter uses the CTL signal on a HyperTransport link interface to indicate the presence of control vs. data packets it is sending concurrently on the CAD bus. When CTL is asserted (high), a control packet is in transit on the CAD bus; when CTL is deasserted (low), a data packet is being sent. During idle periods, CTL is asserted and control information NOP packets are sent.

When interleaving control packets and data packets on a link, the transmitter is required to observe the following rules as it asserts and deasserts the CTL signal:

  1. CTL is always asserted and deasserted on four byte boundaries.

  2. The only time CTL is deasserted is when a data packet associated with an earlier control packet (e.g., request or response packet) is being sent.

  3. CTL is asserted during all bit times of a control packet; for control packets which are either 4 or 8 bytes, the packet must be sent in its entirety without deasserting CTL (there is no interleaving within control packets). This also means that flow control must assure that transmitters never start sending a control packet if the receiver lacks sufficient buffer space to accept all bytes at full speed. Changes in flow control buffer availability are reported by means of NOP packets.

  4. CTL is deasserted through all bit times of data packets.

  5. Re-assertion of CTL within data packets is permitted on four byte boundaries if the transmitter decides to interleave a new control packet, providing it does not have immediate data of its own. After the control packet is sent, CTL is again deasserted and the current data packet transfer resumes.

  6. Only one data packet may be in progress at a time, although it may be paused for the interleaving of control packet(s).

  7. Ordering of control packets is not affected by the fact that data packets may be paused to interleave them.

  8. The bit time immediately following the end of a data packet is always the start of a control packet, and CTL must be asserted.

Figure 4-5 illustrates packet transmission basics and the use of the CTL signal by a transmitter in accordance with the above rules.

Figure 4-5. CAD Bus Control/Data Packet Management Using the CTL Signal

graphics/04fig05.jpg



HyperTransport System Architecture
HyperTransportв„ў System Architecture
ISBN: 0321168453
EAN: 2147483647
Year: 2003
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net