TDA4VE-Q1: Heterogenous multiprocessor design - clock generator synchronisation

Thanks Kadeem, your clarification is very much appreciated. I'm more than happy to use the LMK3H0102, I'd rather have the LVCMOS settings preconfigured versus having to set them dynamically via I2C. Is my understanding correct that I'd need to order this part direct from TI (specifying the required OTP settings), not through a distributor?

Thanks Kadeem, your assistance is much appreciated. I'll be sure to reach out as advised when I'm ready for samples.

Hopefully I can receive some similar input from the broader TI team regarding the other questions in my post.

Thanks!

Hi Jars,

What are your open questions that you still need help with? 

This is a very cross-functional thread, and I am trying to determine to get the right support engineer for the rest of your questions. 

regards

Suman

Hi Suman,

I very much appreciate the cross-functional nature of this thread, I appreciate your support! I'm comfortable with the 100MHz distributed clock clarification provided by Kadeem, but I'd still like to confirm that the proposed GTC0 counter via EXT_REFCLK1 is a suitable approach for the distributed/synchronised timestamping function I've described.

Thanks!

Hi Jars,

The GTC_CLK can indeed be sourced by EXT_REFCLK1 (if that's your question).

From 5.4.3 Clock Mapping section of the J721S2/TDA4VE TRM,

You did mention that the HLOS will be Embedded Linux for TDA4VE. What about the bootloader - are you going to use the U-Boot/SPL as your bootloader or an RTOS-based SBL bootloader?

The TI SDKs do use a frequency for 200 MHz for GTC today (ARM Trusted Firmware will print out a warning otherwise).

regards

Suman

Hi Suman,

Thank you for confirming. I have been through the TRM and am comfortable that the EXT_REFCLK1 can be a source for GTC, I was more looking to confirm that this is a suitable/advisable solution for the proposed synchronised timestamping function between the two processors.

As for the TDA4VE, I am planning on using U-Boot/SPL for bootloading. As mentioned in my original post, Table 5-25 Section 5.4.4.2 of the TRM states that EXT_REFCLK1 is limited to 100MHz, so even though the GTC clock may operate at 200MHz in the TI SDK, I imagine the 100MHz limit stated in the TRM applies.

Thanks!

Hi Jars,

jars121 said:

I need for each processor to maintain a precise internal timestamp, and I need for these timestamps/counters to be synchronized between each processor, such that a timestamped event on the MCU can be processed by the SoC using a common/synchronized time reference.

Can you clarify on what you have in mind when using GTC for the synchronization across these two SoCs - GTC in general provides a read-only counter for various processors within each SoC itself? 

jars121 said:

so even though the GTC clock may operate at 200MHz in the TI SDK, I imagine the 100MHz limit stated in the TRM applies.

Yes, correct. You may have to adjust both the ATF and U-Boot/SPL code for choosing the 100 MHz.

regards

Suman 

Suman Anna said:

Can you clarify on what you have in mind when using GTC for the synchronization across these two SoCs - GTC in general provides a read-only counter for various processors within each SoC itself? 

Basically, once the board is powered up, both the TDA4VE and the AM2434 will go through their boot routines. Once both devices are booted and their respective GTC0 counters configured, the TDA4VE will enable the 100MHz clock (the LMK3H0102 IC as outlined above). In theory this should then provide a synchronised 100MHz read-only up-counter within each device. I.e. reading of the GTC0 value in the TDA4VE and the GTC0 value in the AM2434 at the same time should have the same value.

The reason for this is as follows: the TDA4VE will have access to precise world-time (either via NTP or PTP depending on the connected network), and the synchronised 100MHz up-counter will allow for translation between the baremetal/RTOS timestamp on the AM2434 and the backend processing, distribution, etc. on the TDA4VE in Linux. I could instead implement an NTP/PTP process between the two processors over the PCIe connection, but I figured using a hardware up-counter would incur less overhead for such a simple task.

Hi Jars,

I have referred this to one of our engineers who deals with Time Synchronization to better assist you with your architecture related question. Please wait for further comments/queries from the assigned engineer. 

regards

Suman

Jars, 

Suman asked me to share my thoughts on the discussion. 

From the latest description, you are assuming the GTC is not running upon boot on both sides, then after boot, both sides will configure the GTC to use the EXT_REFCLK1 as refclk, and then enable the GTC. since EXT_REFCLK1 is flat at this point, the counters will not tick till the LMK device is enabled. The scheme should work in theory, with a few notes as below:

1. This seems no different than using a system timer (DMTimer). what is the reason you decided to use GTC instead of DMTimer?

2. The GTC is also responsible to feed the gray-coded timebase for A53 internal timers. It is default to use the MAIN_PLL0_HSDIV6_CLKOUT (200 or 250 MHz) refclk, and enabled by default upon boot. So you will need to stop the GTC, reconfigure refclk, reenable it. If you going this operation while Linux is running, your Linux system time may be messed up. so ideally this need to be done before Linux is booted. I will also check with our internal team if there are other violations to Arm V8 architecture with operation scheme. 

3. You mentioned RTOS in AM2434 will read its own GTC and infer the world time received at TAA4VE via PTP. Since the register read is via the interconnect, it may take 100-200ns to read each 64bit counter. So even with calibration, you may still have dozen's nsec uncertainty due to the read operation on both sides are non-deterministic.  

4. you will also need to trigger a synchronized reading via some kind of PCIe message, every time a PTP conversation happens on the TDA4 side. 

So if you are still vetting different options, I would suggest considering:

1. use a DMtimer instead of GTC to achieve the same function as you envisioned

2. alternatively, is it possible to enable PCIe PTM on the existing link you have, calculate the world time in reference to PTM in TDA4, then apply the same adjustment on the AM24 side. we can discuss more if you are open to consider option.

Regards

Jian

First of all, thank you very much Jian for your input, it is greatly appreciated. You've clarified a few items for me in your post which is a great help.

jian35385 said:

1. This seems no different than using a system timer (DMTimer). what is the reason you decided to use GTC instead of DMTimer?

To be honest I didn't spend much time reviewing the DMTimer sections in the datasheet or TRM. I've had a read through this morning, and this does look like a viable path forward. However, I did find this thread, which suggests that I'm not going to be able to utilise the full 100MHz resolution that the LMK device provides via EXT_REFCLK1?

jian35385 said:

2. The GTC is also responsible to feed the gray-coded timebase for A53 internal timers. It is default to use the MAIN_PLL0_HSDIV6_CLKOUT (200 or 250 MHz) refclk, and enabled by default upon boot. So you will need to stop the GTC, reconfigure refclk, reenable it. If you going this operation while Linux is running, your Linux system time may be messed up. so ideally this need to be done before Linux is booted. I will also check with our internal team if there are other violations to Arm V8 architecture with operation scheme. 

Thank you for clarifying. It looks like the GTC is not the correct solution; I don't want to mess with the gray-coded timebases for the A53 cores.

jian35385 said:

3. You mentioned RTOS in AM2434 will read its own GTC and infer the world time received at TAA4VE via PTP. Since the register read is via the interconnect, it may take 100-200ns to read each 64bit counter. So even with calibration, you may still have dozen's nsec uncertainty due to the read operation on both sides are non-deterministic.  

Understood. Do the DMTimers offer a more deterministic read?

jian35385 said:

4. you will also need to trigger a synchronized reading via some kind of PCIe message, every time a PTP conversation happens on the TDA4 side. 

The device isn't guaranteed to be connected to a PTP grandmaster; the device can also operate completely disconnected from any external networks. This is one of the reasons I'm looking to implement this synchronisation between the TDA4VE and the AM2434; they need to share a common 'baremetal' timebase, which can be supplemented by PTP if/when available.

jian35385 said:

So if you are still vetting different options, I would suggest considering:

1. use a DMtimer instead of GTC to achieve the same function as you envisioned

2. alternatively, is it possible to enable PCIe PTM on the existing link you have, calculate the world time in reference to PTM in TDA4, then apply the same adjustment on the AM24 side. we can discuss more if you are open to consider option.

I am absolutely still vetting different options. Both of these platforms (TDA4VE and AM2434) are new to me, so I'm trying to understand the best way forward. If the DMTimer approach can deliver the solution I've outlined above, without messing with default SDK behaviour, and with reduced timestamp jitter/uncertainty then it seems like a logical way forward. As mentioned above, I may look at implementing a higher level synchronisation process in software using the PCIe link between the two processors, but the initial requirement is for a lower level, hardware-based solution which can operate independent of NTP/PTP availability.

Thanks!