How is PTP time synchronized using an ARM available across the other DSP cores?

I am not sure why some of the information was cut-off:


Given that the time is intended to be global (in the spirit of Common Platform timestamp), how would the other cores (incl. the second ARM processor and the 4 DSP 66X cores) access the PTP time?



We have some potential solutions on how the ARM can pass this information along in a reliable manner but we are trying to understand if there is a fundamentally more native method .

Hi Harish,

We are working with factory team members to answer this post and will get back to you. Thank you for your patience.

Hi, Harish,

The CPTS is a clock synchronization protocol and has nothing to do with the cores. Since it is a protocol and hence is an application which has a specific format of packet. When this packet is detected by hardware, hardware will insert/retrive the timestamp to/from the packet. It depends on how applicationi wants to do with the timestamp.

Rex

Hi Harish,

I understand your approach to the question. But, first, I recommend all who are just getting introduced to our 1588 implementation to go over the attached presentation. It should address many of your concerns. Please note that on slide 20, "1588 Top Level" is not provided by TI. But must be developed by customers or obtained via third-party providers who may have similar solutions.

Time Sync Keystone 2 HW SW.pptx

Kind regards,

Javier

Hi Rex and Javier,
First, thanks for the response. I had already reviewed the slides and went through the Linux Core NetCP user guide. I can see that the ARM (running Linux) could readily use a entity such as linuxptp to get going. That isn't my issue. If we take a multi-core architecture running linux, we have one instance of PTP client running that handles everything PTP to maintain the system clock. Once set, all other applications (regardless of the core that it runs on) have access to the system time. Is such a provision available on K2 based multi-core architecture such as the 66AK2L06? We do not want the two ARM processors and 4 DSP cores running a PTP client and control CPTS. We have other means to handle it. One such solution being a method to run a free-running timer in continuous mode and the ARM that runs the PTP client taking a snapshot of the free-running timer and system clock and passing it along to the other entities. I assume such a solution will work, might not be as accurate (i am talking 10's of nanoseconds potentially on top of the error in PTP so is probably not an issue for our specific application) but then I keep wondering if there is a different way. For example, the TI-BIOS does provide system time but it needs to be set first. Is there a way for this to be internally setup with some configuration.

I guess I asked the same question again but just with a little bit more insight. Hopefully it helps :).

Hi Harish,

Thanks for going over the presentation. It makes things easier to have a discussion with an established frame of reference. I get your point. What I would do in the case that you are running as an ordinary "slave" clock while having Linux running on ARM & TI-Bios running on other DSP's, is to run the PTP stack on Linux for CPTS calibration/synchronization with the remote PTP master clock. Then, have TI-Bios calibrate its timer very similarly as the suggested ARM timer calibration on slide 17. That is, you use the TS_PUSH feature of CPTS to get a "soft" timestamp and you can then compute the DSP's timer offset to the PTP-synchronized CPTS timer and adjust the DSP timer accordingly. That way you have all "local" core timers synced to the "master" CPTS timer. That would off course require some sort of "ping-pong" mechanism between Linux and TI-Bios that would allow the former to inform the latter CPTS 1588 synchronization is complete.

In the case that 1588 falters, say you lose connection to the PTP master clock, you let Linux control the holdover state of CPTS, and leave DSP's tracking the CPTS timer via TS_PUSH or if latency is not much of an issue, just let them run in holdover state themselves, waiting for Linux to recover the CPTS timer whenever connection is established with the remote master clock.

I hope this makes sense, if you need further assistance, let me know.

Kind regards,

Javier

Hi Javier,
Thanks again. The response does help. I cannot go into details but suffice to say that once the SoC loses PTP, it will be out of service. From that perspective, while it is important that the SoC keep track of time to an accuracy of under 1us, it isn't imperative that it be tied down in 10's of nanoseconds.

Another question is if you see a specific issue with the solution that I was mentioning. It possibly got lost in the rather long post but to reiterate, the proposal was to use a common free-running timer that all the cores have access to. Once PTP sync is achieved, the ARM periodically takes snapshot of the system time and the timer and passes it along to the DSP cores. Assuming the timer runs at 1GHz (for ease of this discussion), it seems possible to compute the current system time where:

SystemTimeSnap and timerAtSnap are the systemTime (sec/ns) and the counter value of the freerunning timer.

The snapshot, let's say is taken in a context such that they are almost atomic (within a few nanoseconds of each other)

curTimer is the current counter value of the timer

CurSysTimeNs = SysTimeSnapNs + MOD32(curTimer - timerAtSnap)
if (CurSysTimeNs overflows)
curSysTimeSec = SysTimeSnapSec + 1

Do you see specific issues with it? The reason I propose this is because this still allows us to track PTP time while making sure we abstract the DSP cores from the chore of accessing the CPTS but I am curious if there are issues with it In a way, this is similar to a solution that we have had on a prior platform just that the FPGA was doing it for us instead of the ARM but that in essence is also the concern with regards to how much this can be off by. If it is in 100's of nanoseconds, that is probably okay. If it has potential for more, then probably not.

Again, as usual a long post. Apologize :).