Timing Model Instantiation

Description

The configuration for a timing source, parsed from XML (see Timing Configuration (XML)), is initially stored in a PrototypeTiming object. This acts as a blueprint. The actual runtime instance used during the simulation is represented by the Timing class.

To make a Timing object functional, its initializeModel method must be called, passing the corresponding PrototypeTiming object. This initialization process configures the Timing instance based on the prototype's settings (like frequency, offsets, and noise parameters). Critically, during this initialization, it creates the underlying noise::ClockModelGenerator instance, which is responsible for producing the actual timing noise samples used later in the simulation (see Core Timing and Noise Generation).

Assumptions

• Assumes initializeModel is called exactly once for each Timing instance before it's used in the simulation.
• Assumes the PrototypeTiming object passed to initializeModel is valid and its data remains accessible throughout the duration of the initializeModel call.
• Assumes the parameters extracted from the PrototypeTiming and passed to the ClockModelGenerator constructor (like frequency, offsets, alpha/weights) are correctly interpreted and used by the generator.

Limitations

• Hardcoded Noise Model Structure: The internal ClockModelGenerator is always instantiated with a fixed number of branches (specifically, 15), regardless of the complexity specified or implied by the <noise_entry> elements in the XML configuration. This fixed structure directly impacts the fidelity and performance characteristics of the underlying MultirateGenerator noise model (see Multirate (1-over-f alpha) Noise Model), potentially limiting its accuracy or flexibility compared to a configurable structure.

Related Components

• Classes:
  • Timing (timing.h/cpp)
  • PrototypeTiming (prototype_timing.h/cpp)
  • noise::ClockModelGenerator (Created within initializeModel)
• Key Functions:
  • Timing::initializeModel
  • PrototypeTiming::copyAlphas (Likely used during init)
  • PrototypeTiming::getPhaseOffset (Likely used during init)
  • PrototypeTiming::getFreqOffset (Likely used during init)
• Wiki Pages:
  • Timing Configuration (XML)
  • Core Timing and Noise Generation
  • Multirate (1-over-f alpha) Noise Model
  • Timing Offset Handling

Validation Status

• Needs Verification: The instantiation process itself seems straightforward, but the correct transfer of all configuration parameters and the implications of the hardcoded branch limit need assessment.
• Key Areas for Validation:
  • Confirm that initializeModel correctly transfers all relevant configuration parameters (base frequency, constant/random offsets, alpha/weight pairs for noise entries) from PrototypeTiming to the Timing instance and subsequently to the ClockModelGenerator.
  • Verify the behavior if initializeModel is inadvertently called multiple times on the same Timing instance (Does it error? Warn? Overwrite silently?).
  • Assess the practical impact (performance, memory, fidelity) of the hardcoded branches=15 limitation on the generated noise spectrum, especially compared to simpler or more complex noise profiles defined in the XML.
• Priority: Medium (Core infrastructure setup. While functional, confirming correct parameter transfer and understanding the hardcoded limit's impact is important).