DP83TD510E: Motor control with 10Base-T1L 10M Single Pair Ethernet PHY

Hi Victor,

Can you please explain in detail what the parameters data cycle time and data jitter mean?

--
Regards,
Gokul.

Hi Gokul,

See my answers below.

data cycle time:

E.g. a transmission principle of telegrams (data), based on a master-slave principle.

Cycle time for each telegram (Data) could be 100μs.

That means that every 100µs a new telegram is received.

data jitter:

If there is a deviation regarding the cycle time for the telegrams (Data), e.g. 98µs and 102µs instead of 100μs,

then there is a data jitter of +/-2µs.

Best Regards

Viktor

Hi Victor,

I've understood the definitions now.

DP83TD510 can support the data cycle time you have mentioned. For each data cycle, what is the size of the data sent in bits/bytes?

Regarding the data jitter +/-100ns seems to be very stringent from an 10M Ethernet standpoint (100ns is just 1 bit length of the data). The data jitter is caused by the PHY due to variable latency. I don't have the numbers ready and I will try to respond with the numbers by end of this week.

Just curious, why is stringent data jitter required for motor control applications?

--
Regards,
Gokul.

Hi Gokul,

The size of the data sent is 64 bits.

Regards
Viktor

Hi Victor,

I see that the above system specifications are feasible with DP83TD510. 

Low Data jitter can be achieved using appropriate MAC interface. For a given part, after link-up, the data jitter can be minimal.

Are you looking for data jitter for packet-to-packet(after link-up), linkup-to-linkup or part-to-part?

--
Regards,
Gokul.

Hi Gokul,

Oh, that's good news.

I am not very familiar with the expressions "packet-to-packet(after link-up), linkup-to-linkup or part-to-part".
Do you have a link for me, where this is explained a liitle bit or can you describe it?

Since there is no reference design so far covering this item, do you think that TI is going to have a refernce design for "real time applications"
in future since there is no off-the-shelf solution yet?

Regards
Viktor

Hi Victor,

By part-to-part data jitter, I mean data jitter caused by just changing the part in the same system/setup.

By link-up to link-up data jitter, I mean data jitter caused when measured across different power cycles and reset cycles.

By packet-to-packet data jitter, I mean data jitter caused when measured across different bursts of data for a single power cycle or reset cycle.

We have a reference design just for the DP83TD510 https://www.ti.com/tool/DP83TD510E-EVM. We don't have a system level reference design yet. I can drop you a note if at all we are planning to do the same.
You can take a look at few application notes on the product page https://www.ti.com/product/DP83TD510E if they help.

We can support you all through your development cycle through E2E.

--
Regards,
Gokul.

Hi Gokul,

Thanks for your explanations.
According to this, the "packet-to-packet data jitter" is the relevant for me.
Can you make a more precise statement regarding this kind of jitter?

And thank you very much for the reference design information.,

Regards
Viktor

Hi Victor,

Packet-to-Packet jitter comes into play due to one of the two factors

1. Inherent clock jitter with which PHY is working (this is usually lower than 1ns and is not a contributing factor)
2. Packet to Packet latency variation (this is a very large factor)

To make the latency variation zero for packet-to-packet, we need to choose the xMII interface of the PHY carefully. RGMII, RMII have packet-to-packet latency variation. MII contributes to zero packet-to-packet latency variation for the PHY. So we can make this work if we use MII interface.

--
Regards,
Gokul.