[subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK

[Håkan T Johansson]

Dear Günter,

Background:

Rataclock is a one-wire serial protocol to distribute clock _and_ time. 
It sends a clock signal where the leading edges are periodic and can be 
used to drive PLL (e.g. inside the main and ADC FPGAs) and the trailing 
edges are made shorter and longer to encode information about the time.

Thus modules can collect data synchronously, without the need to 'reset' 
the time or such means.

Since the clock is PLL-recovered in each ADC FPGA, it also needs to be 
checked that ist works in each of them.

More below inline...:

On Wed, 29 May 2024, Weber, Guenter Dr. wrote:

> 
> Dear friends,
> 
> 
> in the merged SIS3316 code we found RATACLOCK, which does not exist (at
> least not under this name) in the module interface that we took over from
> Bastian. I also cannot find RATACLOCK in the manual from STRUCK.
> 
> 
> For a bunch of firmware versions it is hardcoded that HAS_RATACLOCK_RECEIVER
> is true.
> 
> 
>     if (firmware == 0x33165010 || firmware == 0x3316b011
>         || firmware == 0x3316a012 || firmware == 0x3316b012) {
>         m->config.has_rataclock_receiver = 1;
>     }
> 
> It happens that one of our modules has indeed firmware version 0x3316a012.
> So, this variable is set to true. This results in the following check:
> 
> 
> void
> sis_3316_test_clock_sync(struct Sis3316Module *self)
> {
>     /* test, if all clocks are still synced */
>     if (self->config.has_rataclock_receiver == 1) {
>         int tries_left = 3;
>         int ok = 1;
> 
>         while (tries_left > 0) {
>             int i;
> 
>             for (i = 0; i < N_ADCS; ++i) {
>                 uint32_t status = MAP_READ(self->sicy_map,
>                     fpga_adc_rataser_status1(i));
>                 int sync = status & 0x7;
>                 int lost = (status >> 4) & 0x7;
>                 int auto_edge =
>                     self->config.rataclock_use_auto_edge;
>                 if (sync != 7) {
>                     log_error(LOGL, NAME
>                         " ADC%d clock not synced "
>                         "(sync = %d) "
>                         "(tries_left = %d)", i, sync,
>                         tries_left);
>                     ok = 0;
>                 }
>                 if (lost != 0) {
>                     log_error(LOGL, NAME
>                         " ADC%d clock lost sync"
>                         "(lost = %d)", i, lost);
>                     ok = 0;
>                     MAP_WRITE(self->sicy_map,
>                         fpga_adc_rataser_control2(i),
>                         (1 << 31) | (auto_edge << 2));
> 
>                 }
>             }
>             if (ok == 0) {
>                 tries_left -= 1;
>                 time_sleep(1e-3);
>             } else {
>                 LOGF(debug)(LOGL, "rataser clock synced.");
>                 break;
>             }
>             MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0);
>             time_sleep(30e-3);
>         }
>     }
> }
> 
> And we receive an error message that our ADCs are not synchronized. As I
> have no idea what RATACLOCK is, it is hard for me to figure out what is
> happening.
> 
> 
> However, there is also the parameter USE_RATACLOCK. It is set to 0 by
> default. So, maybe it is simply a bug that the check for synchronization is
> executed just on the basis of if (self->config.has_rataclock_receiver == 1),
> while not also checking for if (self->config.use_rataclock == 1)?

It sounds like it.  Could you see if things work if you add such a check 
(i.e. only do that rataclock sync check if use_rataclock == 1)?

> But shouldn't the expectation be that the ADCs are always synchronized? So,
> maybe this is still a problem with the configuration of our module?
> 
> 
> Sorry for this confusion. I would really appreciate if someone could explain
> what is going on here 😊

Cheers,
Håkan