Change in FSYNC driver from 7.0 -> 7.2 changes alignment of rising edge relative to start delay for group

Autonomous Vehicles DRIVE AGX Thor DRIVE AGX Thor General
1

DRIVE OS Version: Provide DRIVE OS version. Example: 7.2.5

Issue Description: The FSYNC driver changed how the FSYNC generators are programmed from 7.0 → 7.2. Previously the generators were programmed such that the FSYNC signal started “asserted” and the first edge in the edge table de-asserted the generator output. This resulted in a pulse-train for all generators in a group that alligned ASSERT with the start offset.

in 7.2 this has changed to initialize the FSYNC generator output to be de-asserted. The first edge in the edge table now asserts the generator output. As such, each generator assert is now delayed from the start offset by the dwell amount (the amount the pulse is low) before asserting.

is this change rationalized somehow?

Why it matters

Starting a group with all generators at the same frequency and duty cycle can still be cajouled into aligning the pulse train to the start-of-second or an arbitrary offset by applying compensation to the offset value. Eventually the pulse train (if it divides integrally into one second) will come around and assert on the start-of-second.

The compensation is a pedantic calculation based on duty-cycle and frequency (inverted to period) and some tedious math.

In the case of a group that contains generators that do not have strictly integral frequency relationships the problem of starting all of the generators such that they will recycle around to the same offset from the start-of-second becomes very difficult. The phase offset of an individual generator is not controllable via the API and in fact would require a much more capable driver.

This is a deviation and/or unexplained change from FSYNC behavior across 7.0 → 7.2.

Please explain the rational for this change and provide more comprehensive documenation and assumptions of use for FSYNC generation.

4

Dear @david.cattley ,
Let me check on the FSYNC details with engineering team and update you.
Do you see any issue with your application from 7.0.3 → 7.2.5? Can you share details to seek feedback from the team? Thanks

5

The fundamental issue is determinism of pulse timing relative to the gPTP timescale synchronized and syntonized from mgbe3 (by default).

It is not enough for FSYNC-disciplined sensors to run at the same frequency and be nominally syntonized to that timescale. Both frequency and phase must be controlled and known. Other sources in the system—for example Ethernet or CAN sensors—are disciplined by the same gPTP timescale but not by FSYNC. To establish, control, and monitor phase relationships among sensor data streams in a heterogeneous system (or even a dual-SoC setup), FSYNC behavior must be intentionally designed, precisely controllable, well documented, and stable against unexpected change.