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.

AM6442: 2 x TMDS64EVM PCIe connected back to back , 1 as EP, 1 as RC.

Part Number: AM6442
Other Parts Discussed in Thread: TMDS64EVM

Tool/software:

I'm just wondering how to connect thought PCIe  2xTMDS64EVM together, 1 acting as Root Complex, and 1 acting as EndPoint.

1) Do you have a recommended cable ?

2) How to manage VMAIN & VCC_3V3_SYS collision?

3) How to manage RX/TX swapping?

Thanks for your help

  • Hi ,

    Thanks for your query.

    This is Linux or RTOS use case ?

    Regards

    Ashwani

  • Hello, 

    I will be more Linux than RTOS.

    But my question are more related to HW topic.

  • There are pictures of a cable in the Processor SDK Linux and MCU+ SDK documentation, e.g. https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/11_00_09_04/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html

    That cable has unpopulated 0-Ohm pads for connecting 3V3 and 12V, and swaps RX/TX. RefClk is left unconnected by default.

    I don't know about the cable on DigiKey linked in the documentation.

    The cable in the pictures is a Adex Electronics PCIe PE-FLEX1-G2-MMCX-12-TI1 cable. I believe it is not listed on the Adex website, but we were able to purchase it via a German distributor.

    Regards,

    Dominic

  • Hello Dominic,

    Thanks for your answers and your link.

    As far as I understood that :

    • REFCLK is not propagated, so I suppose than synchronization is done by using Independent Reclks (IR) and not Common Refclk (CC)
    • you don't propagate the +3.3V neither +12V from root complex to end point, so the 2 boards are powered externally to the PCIe connector.
    • it's mandatatory to have end point ready to be enumerated before the host is ready to enumerate because the host have a timeout shorter than time for the endpoint to boot.
    • PERST is not propagated from root complex to endpoint

    Am I right?

    Do you have the schematic taken in reference into the link ? :https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/11_00_09_04/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html

    because this dip switch doesn't fit with TMDS64EVM (SPRR462C.ZIP).

    Thakns for your help.

  • Hello Thierry,

    REFCLK is not propagated, so I suppose than synchronization is done by using Independent Reclks (IR) and not Common Refclk (CC)

    Yes. That's especially important because on all but the first AM64x EVM revisions (E2), RefClk is being fed from a clock generator IC to both the AM64x and the PCIe connector. Connecting RefClk would cause contention I believe (no idea about the effects for that type of I/O, but I never wanted to risk it). It is possible to re-solder some 0-Ohm resistors to connect the RefClk from the connector to the AM64x directly, thus allowing a common reference clock setup.

    I only ever used the MCU+ SDK AM64x + AM64x examples, and they work just fine with independent Refclk. One one x86 system we were having problems unless we were using a common reference clock (which is mandated by the PCI express card standard).

    you don't propagate the +3.3V neither +12V from root complex to end point, so the 2 boards are powered externally to the PCIe connector.

    Yes, both boards have their own power supply via the 12V connector.

    it's mandatatory to have end point ready to be enumerated before the host is ready to enumerate because the host have a timeout shorter than time for the endpoint to boot.

    That depends on the software you're running on RC and EP, but generally speaking, yes.

    The PCIe specifications (PCIe itself and the electromechanical specification for the PCI express card, i.e. what you'd commonly call a PCIe card) specify that the EP can expect at least 100ms of stable power before PERST is released, and then EP has 20ms until it should be able to enter link training. Since an AM64x can't boot within that time, especially not when running Linux, you need the EP up and running before the RC.

    The MCU+ SDK documentation for the pcie_enumerate_ep example (currently the example Linux RC driver is NOT compatible with an AM64x as an RC) has more details: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_00_00_15/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_PCIE_ENUMERATE_EP.html

    PERST is not propagated from root complex to endpoint

    Yes, for the same reason as above: The EVM has a jumper that could connect the PERST from the PCIe connector to either the PORz input on the AM64x (and you get the startup timing problem described above) or to a I2C port expander (GPIO) output.

    You don't want PORz for timing reasons and obviously you don't want to connect one output to another output.

    Do you have the schematic taken in reference into the link

    I've ignored that. It seems to be a copy&paste left-over from the J721E EVM that has this SW3 and uses it to switch PCIe0 and PCIe1 between RC and EP mode. I'm not sure what exactly it does there, as these two signals are inputs to a port expander (GPIO).

    On the AM64x there is no hardware switch for that. There are jumpers J34 (PERST) and J35 (PRNST). PERST I explained above, and PRNST you can ignore for AM64x EVM <-> AM64x EVM.

    For Linux the device tree configures RC vs. EP. For MCU+ SDK it merely depends on the software you run.

    Best Regards,

    Dominic