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

[Håkan T Johansson]

Dear Günter,

to me it makes sense.

Also, since has_rataclock_receiver is checked elsewhere when user tries to 
have use_rataclock, only checking for that looks good.

(Only would be that stdbool.h seems not needed.  But Hans will remove 
that then :) )

The big question: does it work?

Cheers,
Håkan


On Thu, 30 May 2024, Weber, Guenter Dr. wrote:

> 
> Dear Håkan,
> 
> 
> thank you very much for explanation. I pushed a new NURDLIB version with a
> corrected if-statement at the beginning of the RATACLOCK ADC snyc test. Also
> for aesthetics, I moved the firmware check to a separate function.
> 
> 
> Please have a look, if this makes sense.
> 
> 
> 
> 
> 
> Best greetings
> 
> Günter
> 
> 
> 
> 
> ____________________________________________________________________________
> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan
> T Johansson <f96hajo at chalmers.se>
> Gesendet: Mittwoch, 29. Mai 2024 17:05:13
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK  
> 
> 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
> 
>