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.

Linux/AM5726: PCIe clock questions

Part Number: AM5726
Other Parts Discussed in Thread: CDCM6208V1

Tool/software: Linux

I am attempting to use PCIE1 in single lane mode on a custom AM5726 board, but I am seeing results I can not explain when trying to use (or intentionally break) parts of the subsystem.

My question is about these 3 components: DPLL_PCIE_REF, ACSPCIE, and APLL_PCIE.

1) Why does DPLL_PCIE_REF attain lock when M = 75 and (N+1) = 1 where the input clock is 20MHz?  The TRM states that CLKIN / (N + 1) must be kept between .62 MHz and 2.5 MHz, but DPLL lock is attained with both M = 75, (N+1) = 1 and M = 750, (N+1) = 10.

2) Using an oscilloscope, I have been unable to see a clock output at ljcb_clkn/p when CTRL_CORE_SMA_SW_6.PCIE_TX_RX_CONTROL is set to 0x1 (ACSPCIe TX mode). What could cause this?

3) What could be the reason I see APLL_PCIE attain lock when I set CM_CLKMODE_APLL_PCIE.REFSEL = 1 (ACSPCIE) but provide no clock at ljcb_clkn/p? For this experiment is there a way to disable the output clock from DPLL_PCIE?

  • The factory team have been notified. They will respond here.
  • Hi Kent,
    Our support model is such that we characterize and test products for specific use-cases. Not much time is spent internally on "what-if" questions that fall outside the bounds of these predefined use-cases and we don't support them externally. As to your DPLL locking questions, the design parameters of the PLL in question may not preclude it from "locking" when operating beyond specified limits, but in doing so the output may not meet the requirements of the consuming function(s).

    Do you have a specific issue with your custom board not working with a PCIe endpoint? If so, please provide details and the OS version in use.
  • DK,

    OS: Linux 4.9.69

    I have been unable to provide the 100MHz PCI clock as an output from lcjb_clkn/p.  Behavior I see at those pins:

    • CTRL_CORE_SMA_SW_6.PCIE_TX_RX_CONTROL = 0x0 (Power Down Mode) no bias, no waveform

    • CTRL_CORE_SMA_SW_6.PCIE_TX_RX_CONTROL = 0x1 (TX Mode) bias, no waveform

    • CTRL_CORE_SMA_SW_6.PCIE_TX_RX_CONTROL = 0x2 (RX Mode) no bias, no waveform

    I have also tried providing an external 100MHz clock (from a CDCM6208V1), with 0x2 (RX Mode) and for some reason the waveform ends up being just barely within the acceptable voltage swing from the PCIe spec.  The same clock configuration sent to our endpoint device, a Xilinx FPGA, has a much larger swing.  Does this indicate a configuration problem with the PCIe SS on the AM5726?  I believe I have used proper termination each time I've changed the test between trying the internal and external 100MHz clock.  I have also observed no* waveforms on the TX/RX lines of PCI lane 0 (* this needs confirmation).

    To reiterate, I have tried using the AM5726 to provide the 100MHz PCI clock without success and have tried providing separate 100MHz clocks from a CDCM6208V1 and see a small clock swing to the AM5726 and no* waveforms on the TX/RX n/p lines.

  • Hi Kent,
    Thanks for providing the Linux version. Are you using the TI SDK? If so, please attach (not paste) your board-specific .DTS or .DTSI files.
  • I don't have the exact device tree right now, but I included dra7.dtsi and enabled the pcie1_rc node with the appropriate gpio pin selected for the reset. In regard to the PCIe nodes, the device tree is similar to the beagleboard x15.
  • Hi, Kent,

    To get the output at lcjb_clkp/n using a TI EVM, it requires a hardware mod in addition to programming ACSPCIE to TX mode. I am not sure that applies to your board, but please take a look at the e2e thread in e2e.ti.com/.../653443

    Hope the thread would provide useful and enough info to you.

    Rex
  • I have confirmed that ACSPCIE in TX mode produced the 100MHz clock at lcjb_clkp/n in our custom design after switching to the 50Ω to ground termination described in the thread mentioned above.