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

[Weber, Guenter Dr.]

Yes, bool is not used anywhere. It was a remnant from playing around with the code. Sorry.

DAQ is running now without error messages. If also the output data is correct, I will check tomorrow.


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: Donnerstag, 30. Mai 2024 17:59:28
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240530/c027550c/attachment.html>