The TDC controller interfaces with the ACAM TDC-GPX chip and does whatever is neccessary to output timestamps aligned with the FD core's time base, as fast (in terms of delay) as possible. That is:
@itemize
@item detection of input pulses, checking their width and generation of coarse (128 ns granularity) timestamps by taking a snapshot of an internal counter,
@item detection of input pulses, checking their width and generation of coarse (256 ns granularity) timestamps by taking a snapshot of an internal counter,
@item reading out the fine part from the ACAM,
@item merging these values together, aligning the result to the local timebase and outputting everything in a format digestible by the pulse generators.
@end itemize
The TDC works by default in a so-called G-Mode, utilizing four tapped delay lines, two for start events and two for stop events. This improves the resolution and average precision at the cost of worst-case error. For calibration purposes, another mode (I-mode) is used, as it provides independent, FPGA driven start input and 4 stop inputs.
@subsection TDC timing
Before we time tag any pulses, we need to make sure the TDC is referenced to something and the time shift between
this something and the ACAM's internal time base is known (or better, fixed). Inside the TDC core, the local time base consists of:
this something and the ACAM's internal time base is known (or even better, constant). Inside the TDC core, the time base consists of:
@itemize
@item @code{utc_count} - seconds counter,
@item @code{coarse_count} - coarse start cycle counter (counting at TDC start signal rising edge in cycles of 128 ns),
@item @code{start_count} - start subcycle counter (0..15, reset with each start cycle of the TDC,
@item @code{subcycle_offset} - offset between the ACAM's and TDC core's timescales.
@item @code{coarse_count} - coarse start cycle counter, that counts TDC start events. In our case, the TDC start period of 256 ns is achieved by driving the Start input with a 7.8125 MHz clock coming from the PLL and gating out every second cycle via ACAM's StartDis input to effectively divide it by 2.
@item @code{start_count} - start subcycle counter (0..31, reset with each start cycle of the TDC,
@item @code{subcycle_offset} - offset between the ACAM's and core's internal timescales.
@end itemize
It is very simple if we work in local time base mode, as
the counters need not be aligned to any other counters. The WR mode is a bit more complicated:
TDC start occurs every 16 reference clock ticks, but a PPS pulse from the Csync
unit can come anytime. The most straightformward method here would be to reset the TDC start
generator at every PPS pulse, but it's unsafe (AD9516's output divider SYNC input is asynchronous).
A snapshot of these counters is sampled for every input event. The values are later postprocessed to obtain White Rabbit-formatted timestamps.
The interesting thing is how the TDC timebase is related to an external time scale, as TDC start events occur at fixed multiplies of 256 ns, but a PPS pulse from the Csync
unit can come anytime (with 8 ns granularity). The most straightformward method here would be to reset the TDC start
generator at every PPS pulse, but it is not very safe, as the AD9516's output divider synchronization feature is asynchronous.
The TDC core employs a simple trick here: when a PPS pulse comes, it stores the difference between the lowest
bits of the Csync coarse counter and the subcycle counter (@code{subcycle_offset} signal in @code{p_start_subcycle_counter} process). This difference is added to the timestamps at the postprocessing stage.
bits of the Csync coarse counter and the subcycle counter (@code{subcycle_offset} signal in @code{p_start_subcycle_counter} process). This difference is added to the timestamps at the postprocessing stage to compensate time base shift.
@ref{fig:tdc_timing} shows the relations between the time base signals.
@float Figure,fig:tdc_timing
...
...
@@ -427,8 +430,8 @@ input pulses come too close to each other or in case of poor quality or noise on
could be misinterpreted as a spurious input event. Even if the signal quality is fine, such spurious pulses may
occur while plugging the trigger input to a live signal. The remaining processes: @code{p_gen_acam_start_dis}
and @code{p_gen_acam_stop} drive the TDC's START and STOP disable signals. The former ensures that the start
input is not enabled in the middle of a rising edge of the 7.125 MHz start clock. The latter enables the stop
mainput when the TDC has received at least one valid start pulse and while we are not in the ``dead'' period.
input is not enabled in the middle of a rising edge of the 7.125 MHz start clock and gates the StartDis TDC input to effectively divide the start clock by 2.
The latter enables the stop input when the TDC has received at least one correct start pulse.
@item @b{Reject pulses that are not within the requirements.}