This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN75LVCP601: Mode changing from Auto low-power mode to normal mode with OOB signal

Part Number: SN75LVCP601

 Hello guys,

 One of our customer is evaluating SN75LVCP601 (Two-Channel 6-Gbps SATA Redriver). They have a question about OOB signal after mode changing from auto low-power mode to normal mode as the follow. Could you please give me your answer or comment?

 [The customer question]

 SN75LVCP601 needs 50ns to exit from auto low-power mode as the maximum. OOB signal header portion consists of the following commands.  "COMRESET" command from Host -> "COMINIT" from Device -> "COMWAKE" from Host -> "COMWAKE" from Device.

 The customer question is "the first 50ns period of "COMRESET" command from host will be disappeared because SN75LVCP601 is waking up during the period. Is the situation not problem for "COMRESET" command and OOB signal protocol? If it is not problem, could you tell me why it is not problem?

 Best regards,

Kazuya Nakai.

  • Hello, guys.

    Could you please give me your comment?

    Best regards,
    Kazuya Nakai.
  • Hi Kazuya,

    Here is my understanding from the SATA specification.

    During OOB signaling transmissions, the differential and common mode levels of the signal lines shall comply with the same electrical specifications as for normal data transmission, specified in section 7.2. In Figure 198, COMRESET, COMINIT, and COMWAKE are shown. OOB signals are observed by detecting the temporal spacing between adjacent bursts of activity, on the differential pair. It is not required for a receiver to check the duration of an OOB burst.

    Since only the first ~ 40nS of the initial burst of activity will be removed, the spacing between all of the COMRESET signals will remain as originally transmitted by the Host system.

    Regards,

    Lee

  • Hi Lee,

    Thank you veru much for your reply.

    Could I ask you a few additional questions?

    Q1. Could you please tell me URL of SATA specification you mentioned because I couldn't find figure 198?

    Q2. The customer did SATA compliance test for OOB signaling on their own board uses SN75LVCP601 using Digital Signal Analyzer: KEYSIGHT DSA91304A.

    Digital Signal Analyzer
    KEYSIGHT DSA91304A
    www.keysight.com/.../infiniium-high-performance-oscilloscope-13-ghz

    Then the analyzer indicated that the first burst pulse width of COMRESET was not compliant for SATA specification because the pulse width is shoter than 106.7ns due to wake up time from Auto-low power mode.

    Is this no problem? Also if second burst pulse width of COMRESET meets 106,7ns with allowance, can the COMRESET command pass the compliance test?

    Thank you and best regards,
    Kazuya Nakai.
  • Hi Kazuya,

    I did find a version 3.0 at this location

    www.lttconn.com/.../20100521170123066.pdf

    I cannot speak for the compliance test by Keysight.  It seems to be very complete to test for both the active and idle OOB times.  The specification indicates only the idle time is important for COMRESET.

    Regards,

    Lee

  • Hi Lee,
    Thank you for your reply.

    Are you looking at Table 34 not Figure 198?

    I think COMRESET transmit Gap Length is not only important for OOB signaling, but also Transmit Burst Length is important.

    Do you think it is correct?

    Thank you and best regards,
    Kazuya Nakai.
  • I do think they are both important.  Any redriver which implements the Auto low-power mode will shorten the first Burst Length.  The shorter first Burst length does not reduce the COMRESET Gap Detection Window.  The detection circuit will receive consecutive Gaps of ~ 320ns.

    This is from page 313 of the 3.0 specification:

    Each burst shall be 160 Gen1 UI’s long (106.7 ns) and each inter-burst idle state shall be 480 Gen1 UI’s long (320 ns). A COMRESET detector looks for four consecutive bursts with 320 ns spacing (nominal).

    Regards,

    Lee

  •  Hi Lee,

     Thank you very much for your reply.

     Your reply is very helpful for us.

     Thank you again and best regards,

     Kazuya Nakai.