[Feature] Redesign synconpulse into a configurable `<synchronization>` strategy

[davidbits]

Related Package / Scope

Core Simulator (fers)

Is your feature request related to a problem? Please describe.

The current Timing model includes a synconpulse boolean attribute. When set to true, this feature resets the entire state of the ClockModelGenerator at the beginning of each pulse/window.

Analysis of the original dissertation and early FERS design documents reveals this was intended to model slave nodes in a synchronized networked radar system. However, the current implementation has several significant problems:

1. Physical Inaccuracy: The reset() function is a "sledgehammer" that resets all internal states, including the low-frequency noise generators responsible for long-term correlation (flicker noise, random walk) and the counters for deterministic drift. A real-world synchronization event might reset the output phase, but it does not reset the underlying physical processes causing long-term noise and aging. This makes the current model physically implausible.

2. Inflexibility: The feature is a simple on/off switch. It cannot model common, realistic synchronization scenarios, such as:

   • A system triggered by an external clock that has its own jitter.
   • A Phase-Locked Loop (PLL) that re-locks to a reference with some residual error.
   • A phase reset that does not affect the long-term drift of the oscillator.

3. Ambiguity: The name synconpulse is not descriptive. It hides the critical assumption that the synchronization is perfect, instantaneous, and resets the oscillator to an ideal state. This makes the XML configuration less clear and potentially misleading.

Describe the solution you'd like

The synconpulse boolean attribute should be deprecated and replaced with a more descriptive, flexible, and physically accurate <synchronization> element within the <timing> block of the XML schema.

This change would transform the feature from a simple boolean into a configurable "synchronization strategy."

Proposed XML Schema:

The presence of a <synchronization> block would indicate a non-free-running clock. The default behavior (no block) remains the current synconpulse="false" free-running model.

<!-- Example 1: The old "synconpulse=true" behavior, now explicitly named for debugging/legacy use -->
<timing name="DebuggingClock">
    <synchronization mode="ideal_reset"/>
    ...
</timing>

<!-- Example 2: Models a slave node triggered by a master clock, inheriting its jitter -->
<timing name="SlaveReceiverClock">
    <synchronization mode="triggered" source="MasterClock"/>
    ...
</timing>

<!-- Example 3: Models a PLL re-locking to a reference with configurable residual error -->
<timing name="GpsLockedClock">
    <synchronization mode="relocked" source="GPS_Reference">
        <residual_error_stdev>1e-12</residual_error_stdev> <!-- in seconds -->
    </synchronization>
    ...
</timing>

Required Core Simulator Changes:

1. Remove _sync_on_pulse: The boolean member should be removed from the timing::Timing and timing::PrototypeTiming classes.
2. Refactor reset(): The noise::ClockModelGenerator::reset() method needs to be made more granular. It should be possible to reset only the phase/high-frequency state without affecting the low-frequency generators that preserve long-term memory and drift.
3. Implement Synchronization Strategies:
   • The timing::Timing class will be initialized with a specific strategy based on the XML.
   • At the start of each pulse, instead of checking a boolean, it will execute the configured strategy (e.g., perform an ideal reset, sample a trigger source for an initial offset, etc.).
   • The triggered and relocked modes will require the Timing object to hold a pointer to its reference source Timing object.

Describe alternatives you've considered

1. Keep the current system as-is: This is not ideal as the feature is physically inaccurate and inflexible. It undermines the high standard of realism set by other parts of the simulator, such as the "dynamic pruning" algorithm for phase noise.

2. Remove the feature entirely: This would be a loss of functionality. The ability to model synchronized systems is a valid requirement, and the feature is also useful for debugging, verification against simplified theoretical models, and for educational purposes.

The proposed redesign retains all the benefits of the current feature while dramatically improving its accuracy, flexibility, and clarity.

Additional Context

This redesign honors the original intent of the feature, which was to model networked radar systems. By evolving it from a simple boolean to a configurable strategy, FERS can more accurately simulate a wider range of hardware architectures. This change improves the simulator's fidelity and makes the simulation setup in the XML files more explicit and self-documenting, aligning with the project's goals of flexibility and accuracy.