Inquiry regarding DP83640 One-Step mode

 Hi,

I apologize that no one ever responded to your question.  I am going to move your question to the Ethernet forum where if can be properly supported and tracked. Please post your future Ethernet PHYs, Ethernet MACs and Ethernet SerDes questions to the Ethernet Forum.

Thanks!

John

Hello, thank you for your reply.

We are still awaiting for your reply on this inquiry.

I am looking forward to hearing from you.

Thank you in advance for your information.

Best regards,

Hello,

In order to further look into the customer queries, can you please send more details on the exact scenario the customer is encountering?

You mention, One-Step mode could not operate properly, can please describe in what manner exactly?

Thanks,

Oren

Hello, thank you for your reply.

With regard to your inquiries, I could find out the actual reference for RX series on the website below;

http://am.renesas.com/products/tools/introductory_evaluation_tools/renesas_demo_kits/yrdkrx62n/sub/partners_child.jsp

I hope this could help you to find the history.

Best regards,

I followed the link you provided.  It does note that the DP83640 is used for IEEE 1588 PTP support, but I did not find any mention of issues with One-Step mode. If you could provide more detailed information, I will look into this.

Independent of the Renesas documentation, I can confirm that One-Step mode does operate as described in the DP83640 documentation.  There are no known and undocumented problems with this functionality. 

For general information on the DP83640 PTP configuration and functionality, I would refer you to the Software Development Guide (SDG).  It is part of a zip file that also includes the EPL C code reference library for the DP83640 device. 

The zip file is available at:

http://www.ti.com/tool/dp83640sw-lib

If you are seeing issues with the operation of One-Step mode, I would suggest that you confirm the device configuration against the recommendations in the SDG and confirm that the packet contents agree with this configuration. 

Patrick

Hello, thank you for your reply.

I apologize that the reference was based on SH7216.

With regard to the actual phenomenon, I could find out some detailed information on Renesas's 3rd party's website.

DP838640 just has embedded rate adjustable clock and time stamp acquisition functionality of packet transmission followed by its clock.Therefore, the software should read the time stamp from DP83640's resister after packet transmission, then calculate maenPathDelay and offsetFrmMaster, from which the digital PLL value will feedback to have clock synchronization.

This means that the accuracy on synchronization and jitter are depended on software processing.

The rout cause of this issue was time loss since DP83640's resister access was based on MDIO. The actual read time on time stamp was about 1ms. This influences on real time processing on synchronization accuracy.

If the CPU does not have order functionality to divide to calculate a remainder, it need to have shift operation instead due to this reason.

I hope this could help you to know exact rout cause.

Best regards,

Retrieving timestamps via the MDIO register interface can be time consuming.  For this reason, we designed alternatives into the device.  For more information on these capabilities, please see the sections of the SDG (Software Development Guide) related to:

• Packet-based Event and Timestamp Delivery (also referred to as Phy Status Frames)
• Transmit One-Step Operation
• Receive Timestamp Insertion

A combination of these features should allow for processing of timestamps without solely relying on the MDIO register interface.

Patrick