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.

AM67A: PCIe REFCLK sourced from the SoC

Part Number: AM67A
Other Parts Discussed in Thread: AM67,

Tool/software:

Hi,

is it possible to source the PCIe REFCLK from the SoCs REFCLK pins? Does it comply with the PCI-SIG spec? I've seen some errata for other TI SoC (AM64xx, e2e.ti.com/.../4775845 ) but they don't appear in tn the Errata Sheet for the AM67 anymore.

Also do we need 49.9R resistors to GND on these pins as explained in https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1208861/am6442-am64-pcie-refclk/4625554.

Thanks,
Michael Walle

  • Hi Michael,

    Yes, PCIe REFCLK can be sourced from the SOCs REFCLK pins for AM67A. Please reference the design files for the EVM https://www.ti.com/lit/zip/sprr495 

    Regards,

    Takuma

  • Hi Takuma,

    thanks, it seems I had an old EVM schematics where the REFCLK was still connected to the clock buffer by default.

    Could you please elaborate on errata i2242 (PCIe: The SerDes PCIe Reference Clock Output is temporarily disabled while changing Data Rates"). What option for the workaround is implemented in linux? Does it use two PLLs?

    Thanks,
    Michael Walle

  • Hi Michael,

    Let me check with the team on this. Please expect a day or two of delay, since some team members are in a different timezone.

    Regards,

    Takuma

  • Hi Michael,

    It looks like the errata workarounds are not applied to the SDK.

    Regards,

    Takuma

  • Hi Takuma,

    in that case, how does the refclk work? Are there any plans to move to the two PLL option? Because to me that sounds like you cannot use the refclk supplied by the chip.

    Thanks,
    -michael

  • Hi Michael,

    Refclk will still work for most PCIe devices. However, there are a select few PCIe devices that do not tolerate reference clock to have jitter while the PLL frequency is being changed. 

    Regards,

    Takuma

  • Hi Takuma,

    What are the "few PCIe devices"?

    what about:

    Are there any plans to move to the two PLL option?

    Are there any issues which prevents moving to this option?

    -michael

  • Hi Michael,

    There are no plans as of now, and it depends on the PCIe device implementation. The TI SK-AM67 board uses the internal SoC clock, so you may test out the device that you are planning to connect to test functionality.

    Otherwise, the workaround to use external clock can be used.

    Regards,

    Takuma

  • Hi Takuma,

    sorry I don't understand. Why does the workaround using two PLLs depend on the PCIe device. AFAIU, using two PLLs won't disturb the refclk output. The flip side is that you have to use two PLLs. Therefore my question is, why can't you implement the workaround with two PLLs?

    Please note, that we are an OEM and we cannot tell what our customers will use. The workaround with the external clock is (a) not really cost effective and (b) takes up more space on the PCB. Thus we, would prefer the workaround with the two PLLs.

    Thanks,
    -michael

  • Hi Michael,

    In terms of software fix, we do not have a patch. Therefore, in terms of the paths you may take if you need a workaround ASAP:

    • If you have a specific PCIe device in mind to connect, you can test with SK-AM67 board from TI which uses internal clock to see if that specific PCIe device triggers the errata. If all functional, then no concern.
    • If you do not have a specific PCIe device in mind, you may design in an external clock generator, similar to how it is done for J721E EVM or J721S2 EVM. This will be a valid workaround.

    Understood that you will prefer the workaround with the two PLLs, but this will take considerable time for us to implement. If it is acceptable to wait for a couple of months, then I can discuss with our development team to see if we can implement the software workarounds.

    Regards,

    Takuma

  • Hi Takuma,

    the question is, what are the implications to use two PLLs. I'm fine if the implementation takes some time. But I'd really like to hear that it is at least feasable. Is the second PLL already used for something or is it free anyway? If you use two PLLs for PCIe, is SGMII not working, etc.

    The board is work in progess so there is no time pressure. I'm also fine telling our customers that the problem can be fixed with a future version. But if I tell them, there must be a way to actually fix it then without having an impact on other parts of the SoC. Therefore, I need an understanding what are the PLLs used for.

    Thanks,
    Michael Walle

  • Hi Michael,

    The two PLLs are shared between other interfaces, but it should not cause a limitation for other interfaces not working when using two PLLs. Reference clock is 100MHz and other shared interfaces like 100MHz should also take 100MHz.

    Regards,

    Takuma

  • Hi Takuma,

    Sorry I don't understand. With that logic, why do you even need two PLLs for PCIe gen2 and gen3. I presume the internal PLL runs with a much higher frequency to match the SerDes protocol, regardless of the external 100MHz refclk. Could you please elaborate?

    Thanks,
    Michael Walle

  • Hi Michael,

    The errata is only exhibited when there is no external 100MHz refclk. When using the internal Serdes clock as a reference clock, this reference clock temporarily gets disabled due to the programming sequence of PLL. By using two PLLs, one can switch the PLL source while reprogramming the first PLL so that there are no breaks in reference clock.

    Regards,

    Takuma

  • Hi Michael,

    It should be possible to use two PLLs for PCIe while USB is on the other SERDES interface. There are two individual SERDES interfaces which each only supports one lane, and limitation in errata is only for when the two interfaces are on the same interface, so it should be possible.

    Other limitations are listed in the errata.

    Regards,

    Takuma