gates in a circle, gate delay depends on temp and voltage, this sets the least count to something like 100 ps. There is a circuit that senses the phase of an external clock and adjusts the voltage to keep the ring in synch with the external clock. when clocks are out of sync, the chip indicates that in a bit and that bit is added to the output stream. the changes on the bit are not strictly syncronous with the condition of the clock sync, there may be a few triggers plus or minus between the indication of the bit vs. the sync condition under which the data were recorded.
Resolution could be worse when unlocked. He has seen factors of 5 to 8. This even though unlocked, the clock period should only change by 10% or so.
the unlocked state is unrecoverable. the meanderings of the period while lock is being sought is not recorded anywhere.
He recommends looking at the correlation of unlocked state and high rate. He has been able to knock a chip out of lock by putting in 20 MHz rate.
Had not heard of the missing bit on the DAC problem. If we get a board to him he will have a look.
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.
On March 12, 2012, with Chuck Hutton, Fernando Barbosa, Tim Whitlatch, Mark Ito.
• 10 boards
• 1 mm air gap on BCAL
• Fernando will send specs for cable to Chuck
• no show stoppers identified
• Werner will need to weigh in on noise, room temperature current design
• patch panel idea from Fernando
• pre-amp separate drivers
∘ buffer for adc
∘ times 10 amplifier for tdc
• Chuck will send VXF[?] file to Fernando with current dimensions of board
• maybe go for final configuration in prototype
• 100 vs. 50 micron
• better rate capatility with 50
• better pde with 100
• order both for prototype