• State
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 52 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: PCIe L1 power management and clocking

Vladimir V
Prodigy 30 points

Part Number: AM6442

Hello TI Team,

We are planning to use the PCIe interface to connect the AM6442 as RC (host) to a FPGA as EP (device).

  1. Can you please give us some details on the mechanism and implementation for L1 sub-states entry & exit for the AM6442?
  2. Was this tested by TI?
  3. Based on Errata i2236, do we have to implement the external clocking scheme using a clock generator like CDCI6214RGET or PI6C557-03, or this doesn’t apply to the silicon rev.2.0?
  4. To use the PCIe power management, do we have to use the CLKREQ# signal connected between AM6442 and FPGA? If so, do we also have to connect it to the enable input of the external clock generator?
  5. The CLKREQ# pin is multiplexed and it is not enabled as a default function upon power up which is in violation of the PCIe specification, and there seems to be a voltage level mismatch as explained here: AM6442: PCIE0_CLKREQn unused in EVM GP? - Processors forum - Processors - TI E2E support forums. How does this affect the PCIe power management?

Thanks.

  • 0
    TI__Expert 7205 points

    Greetings Vladimir,

    1. Section 12.2.2.4.3 PCIe Subsystem Power Management in the AM64 TRM has details on the device and link power states supported by the SoC.

    2. The IP is designed to work with any device that is PCIe compliant, I am assuming you're looking for driver testing/support? Can you share what software stack you are using (MCU+SDK or Linux) for your use-case?

    3. This errata item does not apply to revision 2.0, per the "Silicon Revisions affected" column.

    4. Section 12.2.2.4.3 PCIe Subsystem Power Management has these details, but it is only required for L1s (so L1.1 and L1.2). For any other device, you will need to consult their specific datasheet.

    5. According to the PCIe CEM spec (section 1.5 Electrical Overview), the CLKREQ signal is an optional auxiliary signal. Reading the PCIe base spec, it's not required for the  PCIe link training from initial Detect state into L0; it's only used by the optional L1 substates. That being said, the voltage level mismatch comes from when the processor is using a 1.8 V I/O supply, which in this case violates the max voltage requirements in section 6.1 Absolute Maximum Ratings of the AM64 datasheet. This violation does not occur when using a 3.3V I/O supply voltage, but the non fail-safe description does still apply. If you have need of this pin, the linked thread's answer still applies: you will need some glue logic on the PCB.

    What software stack are you interested in using in this use-case? This will help narrow down the right expert to see the thread.

    Sincerely,

    Lucas

  • 0 in reply to Lucas Bowe
    Prodigy 30 points

    Hi Lucas, thanks for the quick response!

    1. Yes, I did see in the TRM that L1 substates are supported. 

    2. I asked if the L1s support was tested with AM6442 to understand how we can support this in hardware (and software). So, do you have an example of this test, including how the AM64x was connected to the End point device, and steps taken in SW to enter and exit the L1s states?

    3 & 4 - Thanks for clarification

    4. Thanks, I see that "L1s support requires that the CLKREQ pin be connected to the remote peer" - so, this would be the diagram:

     

    5. Yes, the CLKREQn is an optional signal according to the PCIe spec, however if AM64x supports the L1s states, it is a requirement. So, this non-conformance of the CLQREQn should really be in the Errata document, including the workaround glue logic.

    The problem is not only the voltage levels and fail-safe, but also the fact that the pin doesn't default to this function at power-up. So, if it is connected to the enable pin of the clock generator, the PCIe will never enumerate due to the timing violation (PCIe spec requires that clock is stable before PERST# is released). Hence my question 2 above - if there is a claim in the TRM that AM64x supports L1s, how was this tested?