PTP time drifting on K2L EVM

Hi Alan,

I've notified the team for this issue. They should post their feedback directly here.

Best Regards,
Yordan

Folks,

 We would appreciate some rapid feedback on this. At this point, this issue is considered a risk in our program.

Thanks

Harish

Hi Harish,

I've sent a reminder to the design team.

Best Regards,
Yordan

Hi Alan,

 I read your post and a couple of things come to mind:

1)      Can you double check that PTP4l is actually providing the clock adjustments via SPI to the CDCM clock generator of the CPTS input clock?

2)      Yes I believe the M/D/S parameter "nuances" of a 122.88mhz clock impact K2L EVM as I believe that is the fixed SYSCLK and TSREFCLK input clocks. However, the inaccuracy should yield a somewhat constant offset if you have a lock, drifting should not occur.

3)     Can you check whether PTP4l is “skipping” timestamps (i.e. Are you observing any events missing from the CPTS up the stacks to application layer?)

Please find attached a presentation that should also help on getting started with 1588 for K2 devices. The RFTCLK SEL mapping is in the table below:

Mux Sel Value	Reference Clock Followed
0	Clk2
1	Clk3
2	Timi0
3	Timi1
8	Tsrefclk

I am not sure what you are referring to with the RF connector CN7. Could you clarify what the intent is? Also, I am not sure if you can connect it that way you describe. I can double check the schematics again. 2210.Time Sync Keystone 2 HW SW.pptx

Regards,

Javier

Hello Javier,

1. It is my understanding that ptp4l is making adjustments to the PTP HW clock (CPTS) using the Linux API clock_adjtime(). From what I can see, this system call will ultimately call into the CPTS kernel driver (netcp_cpts.c) function cpts_ptp_adjtime(). Please correct me if I'm wrong, but it looks like this kernel driver is directly adjusting the CPTS counter time stamp. I don't believe there is any code in this driver that is making adjustments to an external clock generator via SPI.

But as I mentioned in my original post, we are using the default configuration and Linux device tree for the K2L EVM as delivered in the Processor SDK
(release 03.00.00.04) which is using the internal SYSCLK2 as the clock source for the CPTS. So, with this configuration, I don't believe the internal SYSCLK2 clock can be adjusted.

So does the default configuration for the K2L EVM as provided in the Processor SDK Linux release support PTP operation, or is there additional modifications required to the configuration to get it to work correctly?

2. This was our belief also. Even though we are not able to use a perfect set of M/D/S values, we didn't think that the PTP hardware clock would be drifting
away from the PTP master by as much as we are seeing. So this leads us to the following possible conclusions:
a. There is some missing or incorrect configuration in Linux for PTP to function properly on the K2L EVM. This could be either device tree configuration, or  possibly ptp4l configuration.
b. The actual SYSCLK2 clock being used to drive CPTS is running at a different frequency than what the Linux kernel thinks it is. If the kernel thinks CPTS
is counting at a different rate than what it actually is, then it will never be able to sync the clock with PTP time.
c. The SYSCLK2 clock is just very unstable on this EVM, causing CPTS instability. Same result as b.
d. CPTS kernel driver is not properly modifying the CPTS count when ptp4l calls clock_adjtime().

We assume that PTP operation has been validated on the K2L processor with this EVM. Can you tell us exactly how this was done? What was the configuration of the kernel and ptp4l?  What clock source was CPTS using?

3. Can you tell me where and what to look for with respect to the CPTS kernel driver missing events? As far as ptp4l, we didn't see any errors that were out of the ordinary, outside of the drifting offset, but I can try to capture the logs from ptp4l again.

4. Regarding the RF connector at CN7. My question is whether or not we can feed a 10MHz reference into this connector to use as a different clock source for CPTS. Looking at the schematic, it looks like this 10MHz external referece can be used to drive TSREFCLK, which in turn can be used as a different clock source for CPTS. We were thinking that if we could use this, we can provide a clock source that has a "good" M/D/S values to hae a more accurate CPTS timestamp. But it is not clear how or if we can setup the EVM to do this. It looks like perhaps there are some FPGA registers on the EVM that could be modified to change the clock source? Can you find out if what we're suggesting here is possible?

5. I have looked at that slide deck before and it really doesn't provide enough details on how to actually enable PTP on this specific K2L EVM.  In addition, for our application, we don't need to implement some additional PLL software to adjust the external clock that is driving CPTS.   It is sufficient for ptp4l to adjust the CPTS timestamp only.   Of course this assumes that CPTS has a stable reference clock to begin with.

HI Alan,

I am still reviewing all your comments of this last post. But, let me address #1 which, seems to be the driver of this issue here.

The clock_adj function of the kernel driver is more a notification layer than an actual hardware clock manipulation. As the User Guide suggests, in the section explaining that API, it is the application's responsibility to adjust the VTCXO via the SPI->DAC path  in order to calibrate the CPTS clock and align it with the master clock.

So, the app computes the offset after however many SYNC - DELAY_REQ - DELAY_RESP "rounds" (depending on path asymmetry or symmetry) and then adjusts the VTCXO. It then informs the CPTS Kernel driver by how many ppb it has moved the clock via clock_adj in order for the driver to correctly convert RAW CPTS cycles into UTC time. Now, if the CPTS kernel diver clock_adj is being called without the VTCXO actually being changed, then definitely this will account for the drifts.

This is better explained in the slide deck, slide #19-#22. I understand this slide deck was not meant to explain specific EVM implementations rather the overall Keystone 2 PTP architecture. On K2L EVM, specifically the CDCM clock generator that feeds SYSCLK and TSREFCLK (2 of the 5 reference clock sources for CPTS) is driven by the SPI->DAC->VTCXO loop depicted in the aforementioned slides. So it is possible to calibrate it, but as you mention, my concern was that ptp4l is not actually doing this job. After discussing internally with several colleagues, I don't believe, like you have found, that it is doing it. There would have to be some code added to perform this "step".

Kind regards,

Javier

So after some trial and error changing the M/D/S values in the device tree file we were able to find some values to get the CPTS clock drift down to sub-100 ns per second.  The CPTS clock is still drifting away from the PTP master,  but it is much better (slower) than the default settings, which had a drift of > 1.5ms/s.  We think that since we are still not using a "perfect" set of M/D/S values to match the CPTS reference clock and the fact that the reference clock itself (SYSCLK2)  is not perfectly stable (and needs to be tuned externally via DAC)  that this explains why we are still seeing the CPTS drifting.

So this goes back to our question of whether or not we can use a (high stability) external reference source on the K2L EVM board to use as the ref clk for CPTS.  If this is possible then we may be able to eliminate the drift on this EVM completely.  This would also eliminate the need for the additional software to tune the VTCXO that you mention in your last reply.   So please let us know if this is possible and what we need to do to configure the EVM to operate in this way.

Thanks,
Alan

Hi Alan,

Glad to know that software change improved the drift. Unfortunately, best of my knowledge, there is no other source input other than VTXCO for CPTS refclk (via TSREFCLK pin and SYSCLK). However, VTCXO is a high stable clock, in terms of delay variation I mean, it is withing ppb ranges, if I recall correctly. But, as discussed previously, if the VTXCO is not calibrated via software, drift is always going to occur with respect to the master. The hardware clock has to be adjusted in order to acquire lock form the master.

Regards,

Javier

Ok, so were you able to confirm that the RF connector CN7 on the EVM board cannot be used for an external reference source? According to the EVM schematic, it looks like it can be selected as the source to feed into TSREFCLK pin. We just couldn't figure out exactly how to select it. As I mentioned it looks like there might be some FPGA registers that can be changed via the BMC but the documentation is not very clear on exactly how to do this.

Also, can you tell us how to select TSREFCLK as the refclk for CPTS in Linux? I tried to update the "refclk_sel = <8>" in the device tree but it seems like that is not sufficient. CPTS was completely unstable with just that change. Can you tell us what else needs to be changed to be able to use TSREFCLK? Also on this EVM what is the frequency of the clock on TSREFCLK when using the VTCXO as its source?

Hi Alan,

I have been trying to provide external 10 MHz Ref to  CN7 of K2L EVM . Looks like nobody has got it working, From past 2 months this issues has been raised  with eInfochips but all my efforts have gone vain . Atleast eInfochips should put this in the Know issues list so that people like us do not waste time to figure this.

Best Regards

LN