Ring oscillator readout seems to be faulty
Two issues were observed while running ring oscillator tests with ITkPix V1 on a SCC in a normal lab setup:
-
The 4 MSBs often read back as
0010
= 2 instead of0001
= 1, indicating that two pulses have been received by the RO and thus the register value in the 12 LSBs has to be divided by that number to get the correct frequency.Fix:
cycles = int('{0:016b}'.format(raw_data)[-16:-12], 2) ... osc_data['frequency'] = frequency / cycles
Not sure however, why this is the case because the ROs are reset before they are started.
-
In order to measure the RO frequency, they are started for a given time, defined by the
pulse_width
parameter https://gitlab.cern.ch/silab/bdaq53/-/blob/development/bdaq53/chips/ITkPixV1.py#L1398I was wondering, how our default value of 8 affects the readout precision, as higher values should lead to higher register numbers and thus a lower influence of "LSB noise".
A new scan was used, which reads the ROs with
pulse_width
between 1 and 50 and plots the frequency over the pulse width. Instead of the expected flat line with decreasing fluctuation towards higher values, there is a strong asymptotic behavior:This disappears, when the
+ 1
is removed from this line:frequency = counter / (2 * (pulse_width + 1) / 40e6)
The implications of this potential bug are not too bad, in my mind. Yes, the calculated RO frequency might be wrong, but during wafer probing or irradiations we are interested in statistics, not so much absolute numbers.
I'd appreciate your opinion. As it looks to be implemented very similar in YARR, @mstandke: if it's not too much of a hassle, could we check this in our YARR setup?
- As suggested by Roberto, we could use the actual pulse width (in clock cycles) as the parameter for our
get_ring_oscillators
functions. Then we calculate the resulting chip-dependent register setting (pulse_width / 2) in_get_single_ring_oscillator
and remove the*2
from the formula.
Tasks:
-
Include cycle counter, change default pulse width: !446 (merged) -
Investigate the pulse width dependence: Unclear section in ITkPix documentation, discussed in https://indico.cern.ch/event/1023836/ -
(optional) Use the actual pulse width (in clock cycles) as parameter