• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 276 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LC4357: Using EMAC RX Interrupt to Timestamp Messages for PTP

Wezley Sherman
Prodigy 20 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: DP83640

Tool/software:

Hello,

I'm looking to implement a PTP Slave/Master on the TMS570LC4357, and do not have a PHY on my board capable of supporting hardware PTP. We will not be able to change the hardware to provide this support either.

We've been working through the EMAC section of the TRM, looking over the latency reported as well for for the EMAC FIFO/DMA transactions to occur. Through the TRM and testing of the TMS570, we're starting to believe it would be possible to implement MAC-level timestamping of received frames for PTP with a maximum jitter of 5.12us for a 100Mbps link. This would be utilizing an RTI capture event for when the EMAC requests an RX interrupt to be serviced, and then associating that timestamp with the received packet through the EMAC RX ISR.

Is there an application note on this, or has anyone on this forum successfully/unsuccessfully implemented PTP using this method? Is there something in the TRM that we are missing that would make this method of timestamping indeterministic? 

Hoping to get a response from a TI AE here. Thank you!

  • 0
    TI__Guru 71221 points

    Hi ,

    No, we don't have any PTP example using EMAC.

    If you are using PHY (DP83640) then you can find the example in below thread:

    (+) LAUNCHXL2-570LC43: IEEE 1588 support - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    However, without PHY we don't have any examples on PTP.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 20 points

    Hi Thank you for your response!


    I'm wondering if we could get some input from a TI AE or EMAC expert here on expected latency/jitter in our system that could be introduced by using the EMAC RX interrupt to timestamp incoming messages. We are wanting to know if we can deterministically bound the latency/jitter that would be introduced with this method.

    Thank you!

  • 0 in reply to Wezley Sherman
    TI__Guru 71221 points

    Hi Wezley,

    Apologies for the delay in my response, i was stuck with other issues in this mean time.

    Wezley Sherman said:
    I'm wondering if we could get some input from a TI AE or EMAC expert here on expected latency/jitter in our system that could be introduced by using the EMAC RX interrupt to timestamp incoming messages. We are wanting to know if we can deterministically bound the latency/jitter that would be introduced with this method.

    Exactly which latency you are looking for?

    Correct me if i am wrong:

    You want the latency between the time of arrival of packet to the input of EMAC and time of generating Rx interrupt by EMAC?

    This is the latency you are expecting.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 20 points

    Hi Jagadish,

    Yes, we are looking for the exact latency between the time of arrive of the packet (e.g. the start of frame delimiter hits the PHY) and the time at which the EMAC generates the RX interrupt. We know that this will vary with packet size, but can calculate the time offset based on our negotiated link speed (e.g. a 120-Byte packet with a 100Mbps link should take ~9.6us to transfer -- but in test we're seeing 11.4us. With a consistent latency of 1.7-1.8us that we are assuming is from the EMAC potentially servicing the last cell of the RX FIFO).

    We're wondering if this timing is consistent and if our worst-case latency or jitter would be 5.12us assuming the latency spec in the TRM is correct.

    Thank!

  • 0 in reply to Wezley Sherman
    TI__Guru 71221 points

    Hi ,

    Currently there is no active silicon team is working on these devices.

    And even if there is a team, i don't think they will disclose these values accurately, because as you said this involves the packet length and also hard to determine exact values for processing a packet.

    And even i don't see disclosing these values for any other controllers as well. Again, this process might be in order of uS only is it really necessary to timestamp this internal processing values and it is also almost common for all the packets of same size (i mean same offset will be added) so that mean you can just time stamp the packet after you receive interrupt only. I mean we can ignore this and time stamp only at the interrupt generation.

    --

    Thanks & regards,
    Jagadish.