• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 684 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Details regarding PTM implementation

Dominic Rath
Mastermind 6875 points
Part Number: AM6442
Other Parts Discussed in Thread: DRA821

Dear TI team,

we've got some questions regarding details of the AM64x' PCIe Precision Time Measurement (PTM) implementation.

  • What Endianness does the AM64x use/expect for the delay field in PTM ResponseD messages, and is this configurable?
  • What values should we program in the PTM PHY latency parameters for Gen1 and for Gen2 speeds?

Some background on AM64x PCIe in general:

  • The AM64x TRM doesn't yet contain any description of the PCIe registers, but according to e.g. TI's linux sources the AM64x's PCIe controller is "the same" as on the J721e and J7200. I'm thus looking at the J7200 / DRA821 TRM, and this was a close enough match so far.

Some background regarding ResponseD endianness:

  • The original PCIe specification for PTM was ambiguous on the endianness of the propagation delay in ResponseD messages. The PCIe specification assumed that to be big-endian, the implementors like AM65x SR1.0 or Intel Apollo Lake assumed it to be little-endian.
  • The AM65x SR 2.0 has a bit PTM_REQ_PDEL_BYTE_REV that allows the endianness to be reversed. The AM65x SR2.0 is thus configurable to match link partners that use either endianness, which is a big plus.
  • There's a PCI-SIG ECN that defines a method to auto-detect the endianness.

Some background regarding PHY latency parameters:

  • PCIe PTM assumes that the propagation delay "on the wire" between EP and RC is symmetrical.
  • Actual implementations are apparently not symmetrical with regard to these delays.
  • The J7200/DRA821 TRM says "This field should be programmed with the parameter Receive Latency in [ns] from the PHY Datasheet." - I believe this means TI should specify the actual values that should be programmed.

Best regards,

Dominic

  • 0
    TI__Guru*** 147821 points

    Hi Dominic,

    The Linux driver doesn't support PCIe PTM, so I couldn't find the answer to your questions. I am consulting this internally, and will get you back once I have an update.

  • 0
    TI__Guru*** 147821 points

    Hi Dominic,

    Here is the update after initial internal review. We are still working on final confirmation.

    - AM64x PCIe uses big-endian as intented for the PCIe base spec, and the endianess is not configurable. The auto-detect defined in the ECN is not supported on AM64x.

    - The latency values are 7 pipe clock cycles for transmit and 9 pipe clock cycles for receive.  Controller MMR requires the values to be programmed in nanoseconds.  The following is conversion based on speed:
    1 pipe clock cycle for gen1 = 16ns
    1 pipe clock cycle for gen2 = 8ns
    TX latency for gen1 = 7 * 16ns = 112ns
    TX latency for gen2 = 7 * 8ns = 56ns
    RX latency for gen1 = 9 * 16ns = 144ns
    RX latency for gen2 = 9 * 8ns = 72ns
     
  • 0 in reply to Bin Liu
    Mastermind 6875 points

    Hello Bin,

    thanks for getting this information. It's exactly what I wanted to know, it would be great to get that final confirmation.

    IMHO these details belong into the TRM - maybe you can make sure they end up in the documentation at some point.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Guru*** 147821 points

    Hi Dominic,

    Are you blocked by this information? We are confirming this with the controller vendor, the process might be slow. I will update once we have the response.

    Dominic Rath said:
    IMHO these details belong into the TRM - maybe you can make sure they end up in the documentation at some point.

    Yes, I will check on this. Thanks.

  • 0 in reply to Bin Liu
    Mastermind 6875 points

    Hello Bin,

    the exact latency settings wont matter for at least a few weeks. When we get to implement PTM we can test with the values you gave me.

    The endianness issue means the AM64x wont be compatible with some Intel processors for example and a PCIe switch (though the switch appear to be broken w/ regard to PTM anyway...). The sooner we have confirmation there, the sooner we can look for alternatives.

    So no, not blocked, but we do care for a definitive answer.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Guru*** 147821 points

    Hi Dominic,

    Thanks for the update. I will let you know once I have the confirmation.

  • 0 in reply to Dominic Rath
    TI__Guru*** 147821 points

    Hi Dominic,

    We received the final confirmation that AM64x PTM does use big-endian and it is not programmable. And the "PTM Byte Ordering Adaption" ECN defined by PCI-SIG is not implemented in AM64x PCIe.

    I will update once we received the final confirmation about the PHY latency settings.

  • +1 in reply to Dominic Rath
    TI__Guru*** 147821 points

    Hi Dominic,

    Sorry for the late update. Here is the information of the PHY latency parameters for PTM.

     
    PHY logic latency
    PHY analog latency
    Total PHY latency
    Gen1 transmit latency
    112ns
    26.8ns
    138.8ns
    Gen2 transmit latency
    56ns
    13.4ns
    69.4ns
    Gen1 receive latency
    160ns
    25.2ns
    185.2ns
    Gen2 receive latency
    80ns
    12.6ns
    92.6ns
     
    You can round off the numbers to the nearest integer below the latency value. That will have a very minimal error margin (max of 0.8ns with gen1 transmit).
     
    Also please note that the PHY analog latency numbers are assuming the first bit on the serial pins.  So for transmit this is the latency to first bit transmitted on serial lines and for receive this is the latency from the first bit received on the serial lines. PCIe specification says that this has to be the first serial bit.