AM3352: IEEE 1588v2 Annex D time-stamping limitations

Ok -- I've figured out the why of it for myself.  Just checked the 1588 v1 document and it's all there: v1 has no peer-to-peer synchronization, and you can use any of the multicast addresses 224.0.1.129 thru 132 (v2 by contrast specifies only the 224.0.1.129 multicast address).

So what you have in the AM335x is IEEE 1588v1 Clock Synchronization Support, and not IEEE 1588v2 Clock Synchronization Support as is advertised in the TRM and anywhere else you look.  This is not good.

And even as a v1 implementation, it still lacks support for unicast messaging, which v1 does specify as being ok.

Still need a workaround.

Thanks,
GerryL

Please post what software you are using, and which version.

Hi Biser,

Here's the setup -- some fairly old stuff . .
Custom PCB
AM3352BZCZ30
CCS Version: 6.1.2.00015
bios_6_45_01_29
pdk_am335x_1_0_3
GNU v4.9.3 (Linaro)
Win 7 64-bit

Thanks,
GerryL

Hi Biser,

Anything on this yet?  If the TRM is accurate and if I am reading it correctly then it's quite a serious issue.

Btw, I'm using the TRM from march 2017, which I believe is the latest.  The section in question is 14.3.2.2, and in particular the descriptions of Annex D operations for both receive (14.3.2.2.1.2) and transmit (14.3.2.2.2.2).

Thanks,
Gerry

Hello Gerry,

I am still working on this. I will have an update for you by the end of the week.

Regards,
Nick

Hello Gerry,

Thank you for bringing this to our attention. It does look like the hardware was designed for IEEE 1588v1 rather than IEEE 1588v2.

I am still working on what corrections must be made to the documentation, and if there are any workarounds for you or not.

Regards,
Nick

Hi Nick,

This is very disappointing, especially as one of the reasons why we selected the AM3352 was its support of 1588v2 time-stamping.

But on to the workarounds . .

TRM section “14.3.2.2.1.2 Annex D” lists necessary conditions for receive time-stamping, including the following requirements for the destination IP address:
6. Byte 30 contains decimal 224 (0xe0).
7. Byte 31 contains 0x00.
8. Byte 32 contains 0x01.
9. Byte 33 contains one of the following:
• Decimal 129 and the pX_ts_129 bit in the switch Px_Control register is set
• Decimal 130 and the pX_ts_130 bit in the switch Px_Control register is set
• Decimal 131 and the pX_ts_131 bit in the switch Px_Control register is set
• Decimal 129 and the pX_ts_132 bit in the switch Px_Control register is set

As these conditions are apparently AND’d together, the implication is that even if none of the pX_ts_1xx bits are set the system will still require the first 3 bytes of the address to be 224.0.1. This is nonsense that no self-respecting engineer would allow to stand. Is it possible that the TRM is misleading in this case, and that if none of the pX_ts_1xx bits are set then the entire destination IP address is a don’t care?

Thanks,
Gerry

Hello Gerry,

Working on it. I hope to have more information by Friday, but it could take a bit longer.

Regards,
Nick

Hi Nick,

That's very bad news.  As long as that restriction is in place I don't see much hope for a workaround.  Do you agree?

Thanks,
Gerry

Hello Gerry,

I do not have a clean, prepackaged solution for you at the moment. Please treat all of these comments like a brainstorming session.

TI has PHYs that support IEEE 1588 Start of Frame Detection (e.g. DP83867, DP83822) - would something like that be a possibility for your design? I have not had time to investigate integration considerations if that is a potential option for you.

Thoughts?

Nick

DP83640 is another potential option.

Hi Nick,

Thanks for your efforts on the PHY, but we already have hardware in place. One problem with PHY time-stamping however is that the AM3352 MDIO interface, at 2.5MHz, is too slow to keep up with any significant 1588 traffic on a 1Gb network.

And while I do appreciate your desire to come up with a clean prepackaged solution to the 1588v1/v2 problem, I am in a position where I have to make a decision and move on. I think the central question remains whether or not there is any way to time-stamp a packet which does not have a destination address starting with 224.0.1. Without that capability both peer-to-peer delay measurement and unicast messaging are ruled out.

It looks at this moment that the answer is no, unless any new information has come your way which would change that outcome.

Thanks,
GerryL

Hello Gerry,

Unfortunately I do not know of a way for AM335x to time-stamp packets with other destination addresses if you cannot use PHY timestamping. If you have a Sitara-based infrastructure in place but you have flexibility with the actual part, another option would be to look at other processors in the Sitara family (e.g. AM57xx) that have later versions of CPSW that do support 1588v2.

Thank you again for bringing this to our attention! I am working on getting the documentation fixed so this is not an issue for customers going forward.

Regards,
Nick