• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 262 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DS160PT801: Reference Clock Configurations and SSC

DS160PT801: Is common-refclk with Root always required?

Tony Zabinski
Prodigy 100 points
Part Number: DS160PT801

This question is related to the following post:

DS160PT801: Reference Clock Configurations and SSC - Interface forum - Interface - TI E2E support forums

Are there conditions where the retimer can have a separate reference clock from the Root Complex?

    For example, maybe if the refclk is 100MHz meeting the PCIe refclk specs and without spread?

      We've been operating this way.   Our architecture does not allow for a common-refclk.

  It seems this spec for the chip changed around end of Q3 or 2022.

  If there is some bounding conditions that we could test for, that may be an acceptable solution for us.   For example SKP sequence parameters or total error between Root refclk and Retimer refclk.

Thanks,

Tony

  • 0
    TI__Mastermind 20901 points

    Hi Tony,

    Let me check internally about supporting other clocking architectures.

    If I understand correctly, your current setup operates with separate reference clocks, but without a retimer between root complex and endpoint?

    Best,

    David

  • 0
    Prodigy 100 points

    Hi David,

       We are actually running with DS160PT801 between Root and Endpoint, with separate refclk.  We completed our design before the spec was updated to remove support for separate refclk between Root and Retimer.

    Some additional architectural items that might (hopefully) make our design okay:

    We do not allow spread spectrum

    We operate with x4 links.  Currently one a single x4 link in each direction, but future designs might use two x4 links - But still only single retimer IC.

    We operate reverse from TI Dev Board:  B_PERP3:0 and  A_PETn3:0 are on out ROOT side.

    Thanks,
    Tony

  • 0 in reply to Tony Zabinski
    TI__Mastermind 20901 points

    Hi Tony,

    This may be possible. This test was not performed in our lab, but if enough SKPOS are provided from the CPU, a separate reference clock topology like yours described above could work.

    Are you able to perform any internal validation on this described setup with separate reference clocking topology? I would suggest this if possible.

    Best,

    David

  • 0 in reply to David Waier
    TI__Mastermind 20901 points

    To add on - I don't see an issue with using the reverse topology from TI EVM, or with two x4 links.

  • 0 in reply to David Waier
    Prodigy 100 points

    Hi David,

       Yes - We are testing with separate refclk.   Unfortunately we do not have access to a PCIe bus analyzer.

       Gen3 is working great.

       Recently started Gen4 testing and am having trouble getting link - Not sure yet, but seems likely to be our test hardware electrical.     I have one system configured with common-refclk, so our not linking Gen4 is not related to refclk.

        I can only adjust parameters on the retimer - Root and Endpoint parameters are out of our control.  I am not sure how the retimer SKPOS register affects the resulting SKP interval - Seems like it would have to be the lowest common-denominator between the endpoint and the retimer?

      If you have recommendations on any parameters to  test or seep, please go ahead and recommend them.

    Thanks,
    tony

  • 0 in reply to Tony Zabinski
    TI__Mastermind 20901 points

    Hi Tony,

    Good to know that the current issue at Gen4 is not refclk related.

    I'll have to check internally for any parameters to adjust on the retimer, excluding enabling SRIS mode. If you do not have access to our secure folder for various EEPROM configuration files, I can grant you access.

    During validation testing, I would recommend testing link robustness (such as secondary bus reset, link-speed changes, link enable/disable, etc.).

    Best,

    David