Discussion with Ed Jastrzembski, Ben Raydo, Kei Moriya, and MMI
- F1 TDC codes run from a bit more than 0 to a bit less than (2^16 – 1)= 65535, e. g. 10 to 65525
- These codes go round and round, repeating.
- When the code flips from the highest possible value to the lowest possible value (e. g., from 65525 to 10), it is called a “reset”, for now we will call the period of resets the “reset period.”
- The sequence starts at lowest possible code (e. g. 10) at sync time.
- There is a system clock going on a 32 ns period (31.25 MHz) all internal clock are derived from this one.
- A trigger time stamp is also generated with a 32 ns period starts at 0 and is read-out.
- For a 56 ps least count, the time between resets would be 3.67 microseconds if the count range were 2^16 (which it is not).
- The trigger defines the beginning of the read-out window, using the configured look-back time. Details of how this is done is not clear, but the data values are completely insensitive to these details, only the choice of which hits are read-out.
- The trigger time stamp is recorded.
- The read-out window cannot be more than 90% of the reset period, otherwise more than one reset could occur in the window and relative time differences channel-to-channel would be ambiguous.
- Since the reset period is not a intgral multiple of any clock period, except for the least count of the tdc code (56 ps), it cannot be referenced to any internal time except for the sync at the beginning of the run. Referencing time to the trigger would requiring calculating reset cycles since synch and looking at the TI timestamp to determine the tdc code for the trigger. Then all codes in the system could reference this trigger time. This has never been attempted.
- Currently the synch is not synchronized with the 31.25 MHz clock. William’s firmware fix will fix that.
- Having a reference signal in any F1-TDC solves all problems as well. That is why everybody does it.