• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Subscribers 99 subscribers
  • Views 636 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.

TMDS64EVM: EtherCAT SYNC Jitter and Delay

Jonas Ens
Prodigy 140 points
Part Number: TMDS64EVM

Dear TI-Team,

I have measured the SYNC signal of the above mentioned evaluation board using the 'Simple EtherCAT Example'. In my setup, the evaluation board was working as a clock slave, so it had to synchronize to the SYNC signal of the clock master (which was connected right after the EtherCAT master). The time difference between the clock master and the clock slave (TMDS64EVM) was measured in 30,000 oscilloscope triggerings. The result was as follows:

min time difference:     83 ns
max time difference:  100 ns
standard deviation:        3 ns
mean:                          91 ns

These results are very promising for us in terms of jitter, but the delay (mean=90ns) is quite high. The EtherCAT Slave: Datasheet (ti.com) specifies a jitter of 20ns, but does not provide any information about delay. Therefore my questions:

1. Is there anything specified about the delay? (Is 90 ns in the typical range?)

2. Considering my measurement, I assume that TI defines Jitter as the difference between max_time_difference and min_time_difference. Is this correct?

Best regards,
Jonas

  • 0
    TI__Genius 9325 points

    Hi Jonas,

    Thank you for sharing the above details. May I know the cycle time you are configuring in the master for the EtherCAT network and also how long are you waiting since enabling DC master mode in order to capture the above values ?

    Also do share the details of the SDK version you are using for this purpose.

    Thanks and Regards,

    Aaron

  • 0
    TI__Genius 9325 points

    Jonas,

    Jonas Ens said:
    1. Is there anything specified about the delay? (Is 90 ns in the typical range?)
    • May I know which delay you are referring to ? We have documented the path (process path and auto-forward path) delays which is in the range of 200ns for application running at 333MHz. Also do share the details of the topology used for measurement and the pins used for probing ? 
    Jonas Ens said:
    2. Considering my measurement, I assume that TI defines Jitter as the difference between max_time_difference and min_time_difference. Is this correct?
    • In our measurement for jitter, we are probing the SYNC signal of the end device with respect to the first device in the network. After enabling the persistence mode in the oscilloscope and running the application for long time (about 24 hours), we are measuring the jitter width across the extremes of the corresponding SYNC signal.

    Hope this answers your query.

    Thanks and Regards,

    Aaron  

  • 0 in reply to Aaron Thomas
    Prodigy 140 points

    Hi Aaron,

    thanks for your reply.

    Aaron Thomas said:
    Thank you for sharing the above details. May I know the cycle time you are configuring in the master for the EtherCAT network and also how long are you waiting since enabling DC master mode in order to capture the above values ?

    The cycle time was set to 1ms. I started the measurement 30 seconds after enabling DC mode.

    Aaron Thomas said:
    Also do share the details of the SDK version you are using for this purpose.

    I use "EtherCAT slave simple demo"-project out of AM64x INDUSTRIAL COMMUNICATIONS SDK: Introduction (09.01.00.03).

    Aaron Thomas said:
    Also do share the details of the topology used for measurement and the pins used for probing

    My measurement setup consists of an EtherCAT-Master. Connected to it are 3 slaves in total (Non-TI-Slave, TMDS64EVM, Non-TI-Slave; in this order). For probing  'J18 SYNC OUT0' (page 6 in AM64x / AM243x Evaluation Module User's Guide (Rev. A)) is used.

    Aaron Thomas said:
    May I know which delay you are referring to ?

    I am referring to the time difference between the SYNC0-Events of the one EC-Slave connected directly after the EC-Master (which makes this EC-Slave the clock-master) and the TMDS64EVM-EC-Slave. Based on the 20ns Jitter given in the datasheet, I would expect the SYNC0-signal of TMDS64EVM to be measured in the range of -10ns and +10ns around the clock-master (when triggering on the Clock-Master and take it as reference). Instead, I measured the TMDS64EVM-EC-Slave in the range of +83ns and +100ns.

    Aaron Thomas said:
    In our measurement for jitter, we are probing the SYNC signal of the end device with respect to the first device in the network. After enabling the persistence mode in the oscilloscope and running the application for long time (about 24 hours), we are measuring the jitter width across the extremes of the corresponding SYNC signal.

    Thanks, I understood. This definition matches with my measurement (100ns-83ns --> Jitter of 17ns). But the problem is that the signal is jittering around 91ns and not around 0ns. My understanding is that the signal on 'J18 SYNC OUT0' is directly routed from the PRU. So I would expect a much smaller time difference to the clock-master.

    Thanks and have a nice weekend,
    Jonas

  • 0 in reply to Jonas Ens
    TI__Genius 9325 points

    Sorry Jonas for the delay in response and thank you for the SDK version and topology. 

    Jonas Ens said:
    Instead, I measured the TMDS64EVM-EC-Slave in the range of +83ns and +100ns
    • Now I understand the issue. In our test setup, the signal was jittering around 0ns. Jittering delay was not seen. Can you clarify if this delay is consistent throughout multiple test iteration or if it changes when measured multiple times?

    Meanwhile, let me try to reproduce this from our side.

    Thanks and Regards,

    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 140 points
    Aaron Thomas said:
    Can you clarify if this delay is consistent throughout multiple test iteration or if it changes when measured multiple times?

    Hello Aaron,

    yes, this delay is quite consistent over several measurement on several days.

    Thanks and Regards,
    Jonas

  • 0 in reply to Jonas Ens
    TI__Genius 9325 points

    Hi Jonas,

    Thank you for the input. I'll look into this and get back to you by Friday.

    Regards,

    Aaron 

  • 0 in reply to Jonas Ens
    TI__Genius 9325 points

    Hi Jonas,

    Can you share the details of the device you are using as clock master ?

    Regards,

    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 140 points

    Hi Aaron,

    As clock master I am using a device where the EtherCAT implementation is based on the "Hilscher netX 51"-SoC.
    (Hilscher: netX 51–Network controller for fieldbus slave and Real-Time Ethernet slave with memory controller)

    But I also measured the same results with a clock master based on an FPGA with Beckhoff core.

    Regards,
    Jonas

  • 0 in reply to Jonas Ens
    TI__Genius 9325 points

    Thanks Jonas for the details.

    And I believe you're probing the the SYNC-OUT pin of AM64x with respect to that of the first device in the network ? 

  • 0 in reply to Aaron Thomas
    Prodigy 140 points

    yes, correct

  • 0 in reply to Jonas Ens
    TI__Genius 9325 points

    Sorry for the delay Jonas. I'll come back with an update by end of this week.

    Regards,

    Aaron

  • 0 in reply to Aaron Thomas
    TI__Genius 9325 points

    Hi Jonas,

    So we tried to reproduce the issue by keeping a non TI device (EL9800) as first device and AM64x EVM as 2nd device and measured the SYNC pulse of AM64x with respect to EL9800 but we weren't able to see the jitter happening around 91ns. In our setup, it is jittering around 0.
    Do let me know if I'm missing anything.

    Thanks and Regards,

    Aaron