Clarification on relationship between PTP, TSC, Fsync Generators

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
1.9.3.10904
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

This is my understanding of how the timing mechanisims on the AGX work when PTP is enabled (and please correct me where I am wrong or misunderstand anything)

  1. TSC clock kicks off 7 seconds before kernel is loaded and runs at 31.25 Mhz - which I believe is a resolution of 32 ns per tick.
  2. Kernel loads, eventually NVPPS module syncs the frequency (syntonize - very important distinction I have found - might want to clarify that in your documents) to the PTP hardware clock of the client interface (usually mgbe0_2)

This is where things get fuzzy - I think that ioctl calls to nvpps using NVPPS_GETEVENT still indicate that the tsc resolution is 32 ns - but if there is sycning with the PTP clock - would that not change? (I can also double check this later).

Now - the fsync generators can either be configured to be programmed at a point in the future in TSC ticks or they start up at sometime in the boot sequence if prgramming is not selected.

  1. If the fsync generators are not configured to be programmed - at what point in the boot sequence do they start when PTP is enabled? Are they at all coordinated with say top of a second as well - are there any kind of guarantess as to when they start - or is just right after something happens in the boot sequence?

  2. If PTP and TSC are locked, but there is a constant drift getting corrected by whatever code obeys this parameter:
    PTP_TSC sync LOCK_THRESHOLD - how would a person go about determining the time in the future to program the fsync to start in ticks. As I have pointed out in another thread here - my approach is to compute the average PTP-TSC offset using NVPPS_GETEVENT calls. Then, pick a time in the future and:
    Convert to ns since epoch
    Subtract PTP-TSC offset
    Divide by 32 ns per tick
    Use the program_fsync_start_time() call.

Aside from trying to clarify the highlevel view of how these things fit together, my other question is how would a person get the fsync generator across 2 ECUs to be in phase? Right now - telling each ECU the time in the future you want it to start and having them convert the time to TSC ticks individually (because TSC-PTP offset depends on boot time of device) is the only method I see.

4

I’m not sure about your concern, but you might clarify by reviewing the source code of “nvpps_main.c”.

Could you please clarify what ‘programming is not selected’ means in this context?

5

Programming not selected == fsync groups disabled, start at boot vs having to program fsync to start at point in future.

6

Did you mean that if fsync groups are disabled, it will start at boot? Could you please provide more details or a source for this information?

7

image
image1458×508 40.1 KB

If fsync groups are disabled, active generators start at some time during startup. If they are enabled, I can calculate a time in the future to start them at.

What I need to do is make sure that fsync starts at the same time between two AGX boxes. One thing I am hoping to figure out is if I do not enable fsync groups, then is their start time somehow aligned with PTP if it is used. Right now - my data points to no, but I am trying to determine if there is anything that I have missed and whether or not NVIDIA has any suggestions on how to do this other than what I am doing right now. Is there a better way that I am unaware of?

9

Please refer to drivers/media/platform/tegra/cam_fsync/cam_fsync.c for the inquiry about the start time and PTP-TSC Sync for the alignment.

How did you observe that the start of fsync isn’t aligned with PTP?

10

The fsync generators on an ECU are fine. I am asking about fsync generators across two different ECUs. When I start each of them up, they will have different boot times. Now - if they all have the same frequency and start at a specified time - like at the top of a second or whatever and PTP is synchronized across both devices - they should overlap and fsync generators should be in sync. What I saw when comparing timestamps of two cameras across two ECUs was that the trigger signals were not in phase. I am asking when fsync signals are started if they are not configured to be programmed per the docs above.

12

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Could you please elaborate on the method you used to compare the timestamps of the two cameras across the two devkit systems? Any specific tools or techniques employed in this comparison would be helpful for a more accurate assessment.