HT Link Disconnect/Reconnect Sequence

The specification defines the ability of the HT bus to disconnect all of its links simultaneously. This mechanism uses the LDTSTOP# signal and NOP packet (with disconnect bit set) to gracefully disconnect and subsequently reconnect all links within the HT fabric. This feature has five specified uses:

• Disconnecting HT links to conserve power

• An alternate and faster method of changing link frequency and width during initialization, when compared to Soft Reset

• Support for Host Voltage ID and Frequency ID (VID/FID) change

• Processor is entering certain ACPI-specified states

• System is entering certain ACPI-specified states

Regardless of the system motivation for asserting LDTSTOP# the sequence of events associated with one of the five previous features is initiated in one of the following ways:

• Host software accesses a register within the I/O Controller Hub (or South Bridge)

• I/O Controller Hub (or South Bridge) logic initiates the sequence.

• The host sends a VID/FID SM request.

Reference Information: LDTSTOP# Procedures

The specification defines the following procedures associated with the disconnect and reconnect sequence.

1. Once LDTSTOP# is asserted, it must remain asserted for at least 1 us. LDTSTOP# assertion must not occur while new link frequency and width values are being assigned by link-sizing software, or undefined operation may occur. (This is because both sides of a link must have link width and frequency programmed, and if one side has been programmed with new values and the other has not yet been programmed, the width and/or frequency of the two sides will not match.)

2. PWROK and RESET# assertions have priority over LDTSTOP# assertion, and LDTSTOP# must be deasserted before RESET# is deasserted.

3. A transmitter that recognizes the assertion of LDTSTOP# finishes sending any control packet that is in progress and sends a disconnect NOP packet. After sending this packet, the transmitter continues to send disconnect NOP packets through the end of the current CRC window (if the window is incomplete) and continuing through the transmission of the CRC bits for the current window. After sending the CRC bits for the current window, the transmitter continues to drive disconnect NOP packets on the link for no less than 64 bit-times, after which the transmitter waits for the corresponding receiver on the same device to complete its disconnect sequence, and disables its drivers (if enabled by the LDTSTOP# Tristate Enable bit). No CRC bits are transmitted for the last (partial) CRC window, which only contains disconnect NOP packets. Since the HyperTransport protocol allows control packets to be inserted in the middle of data packets, and since transmitters react to the assertion of LDTSTOP# on control packet boundaries, a given data packet could be distributed amongst two or more devices after the disconnect sequence is complete.

4. A receiver that detects the disconnect NOP packet continues to operate through the end of the current CRC window and into the next CRC window until it receives the CRC bits for the current window. After sampling the CRC bits for the current window, the receiver disables its input receivers to the extent required by the LDTSTOP# Tristate Enable bit.

5. Note that LDTSTOP# can deassert either before or after the link disconnection sequence is complete. A link transmitter is not sensitive to the deassertion of LDTSTOP# until both its disconnect sequence as described in step 3 is complete, and the disconnect sequence for the associated receiver on the same device is complete. A link receiver is not sensitive to the deassertion of LDTSTOP# until both its disconnect sequence is complete and the disconnect sequence for the associated transmitter on the same device is complete.

6. A transmitter that perceives and is sensitive to the deassertion of LDTSTOP# enables its drivers as soon as the implementation allows, begins toggling the CLK with a minimum frequency of 2MHz and places the link in the state associated with the beginning of the initialization sequence (CTL = 0, CAD = 1s, CLK toggling). The transmitter is required to have CLK running within 1 us (to assure that the receive logic has a clock source). The clock frequency does not have to match the currently programmed frequency before CTL is asserted. A receiver that perceives and is sensitive to the deassertion of LDTSTOP# waits at least 1 us before enabling its inputs. This 1-us delay is required to prevent a device from enabling its input receivers while the signals are invalid before the transmitter on the other side of the link has perceived and reacted to the deassertion of LDTSTOP#. When a transmitter's corresponding receiver on the same device has been enabled, it is free to begin the initialization sequence.

7. After reconnecting to the link, the first transmitted packet after the initialization sequence must be a control packet, as implied by the state transitions of the CTL signal during link initialization. This is true even if the link was disconnected in the middle of a data packet transmission.

8. The CRC logic on either side of the link should be re-initialized after a disconnect sequence in exactly the same way as for a reset sequence.

9. Link disconnect and reconnect sequences do not cause flow control buffers to be flushed, nor do they cause flow control buffer counts to be reset.

10. LDTSTOP# should not be reasserted until all links have reconnected to avoid invalid link states. The means to ensure this is beyond the scope of this specification, although it is expected that this will be under software control.