<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Yes, bool is not used anywhere. It was a remnant from playing around with the code. Sorry.<br>
<br>
DAQ is running now without error messages. If also the output data is correct, I will check tomorrow.<br>
<br>
<br>
Best greetings <br>
Günter
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Donnerstag, 30. Mai 2024 17:59:28<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
Dear Günter,<br>
<br>
to me it makes sense.<br>
<br>
Also, since has_rataclock_receiver is checked elsewhere when user tries to <br>
have use_rataclock, only checking for that looks good.<br>
<br>
(Only would be that stdbool.h seems not needed.  But Hans will remove <br>
that then :) )<br>
<br>
The big question: does it work?<br>
<br>
Cheers,<br>
Håkan<br>
<br>
<br>
On Thu, 30 May 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear Håkan,<br>
> <br>
> <br>
> thank you very much for explanation. I pushed a new NURDLIB version with a<br>
> corrected if-statement at the beginning of the RATACLOCK ADC snyc test. Also<br>
> for aesthetics, I moved the firmware check to a separate function.<br>
> <br>
> <br>
> Please have a look, if this makes sense.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan<br>
> T Johansson <f96hajo@chalmers.se><br>
> Gesendet: Mittwoch, 29. Mai 2024 17:05:13<br>
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK  <br>
> <br>
> Dear Günter,<br>
> <br>
> Background:<br>
> <br>
> Rataclock is a one-wire serial protocol to distribute clock _and_ time.<br>
> It sends a clock signal where the leading edges are periodic and can be<br>
> used to drive PLL (e.g. inside the main and ADC FPGAs) and the trailing<br>
> edges are made shorter and longer to encode information about the time.<br>
> <br>
> Thus modules can collect data synchronously, without the need to 'reset'<br>
> the time or such means.<br>
> <br>
> Since the clock is PLL-recovered in each ADC FPGA, it also needs to be<br>
> checked that ist works in each of them.<br>
> <br>
> More below inline...:<br>
> <br>
> On Wed, 29 May 2024, Weber, Guenter Dr. wrote:<br>
> <br>
> ><br>
> > Dear friends,<br>
> ><br>
> ><br>
> > in the merged SIS3316 code we found RATACLOCK, which does not exist (at<br>
> > least not under this name) in the module interface that we took over from<br>
> > Bastian. I also cannot find RATACLOCK in the manual from STRUCK.<br>
> ><br>
> ><br>
> > For a bunch of firmware versions it is hardcoded that<br>
> HAS_RATACLOCK_RECEIVER<br>
> > is true.<br>
> ><br>
> ><br>
> >     if (firmware == 0x33165010 || firmware == 0x3316b011<br>
> >         || firmware == 0x3316a012 || firmware == 0x3316b012) {<br>
> >         m->config.has_rataclock_receiver = 1;<br>
> >     }<br>
> ><br>
> > It happens that one of our modules has indeed firmware version 0x3316a012.<br>
> > So, this variable is set to true. This results in the following check:<br>
> ><br>
> ><br>
> > void<br>
> > sis_3316_test_clock_sync(struct Sis3316Module *self)<br>
> > {<br>
> >     /* test, if all clocks are still synced */<br>
> >     if (self->config.has_rataclock_receiver == 1) {<br>
> >         int tries_left = 3;<br>
> >         int ok = 1;<br>
> ><br>
> >         while (tries_left > 0) {<br>
> >             int i;<br>
> ><br>
> >             for (i = 0; i < N_ADCS; ++i) {<br>
> >                 uint32_t status = MAP_READ(self->sicy_map,<br>
> >                     fpga_adc_rataser_status1(i));<br>
> >                 int sync = status & 0x7;<br>
> >                 int lost = (status >> 4) & 0x7;<br>
> >                 int auto_edge =<br>
> >                     self->config.rataclock_use_auto_edge;<br>
> >                 if (sync != 7) {<br>
> >                     log_error(LOGL, NAME<br>
> >                         " ADC%d clock not synced "<br>
> >                         "(sync = %d) "<br>
> >                         "(tries_left = %d)", i, sync,<br>
> >                         tries_left);<br>
> >                     ok = 0;<br>
> >                 }<br>
> >                 if (lost != 0) {<br>
> >                     log_error(LOGL, NAME<br>
> >                         " ADC%d clock lost sync"<br>
> >                         "(lost = %d)", i, lost);<br>
> >                     ok = 0;<br>
> >                     MAP_WRITE(self->sicy_map,<br>
> >                         fpga_adc_rataser_control2(i),<br>
> >                         (1 << 31) | (auto_edge << 2));<br>
> ><br>
> >                 }<br>
> >             }<br>
> >             if (ok == 0) {<br>
> >                 tries_left -= 1;<br>
> >                 time_sleep(1e-3);<br>
> >             } else {<br>
> >                 LOGF(debug)(LOGL, "rataser clock synced.");<br>
> >                 break;<br>
> >             }<br>
> >             MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0);<br>
> >             time_sleep(30e-3);<br>
> >         }<br>
> >     }<br>
> > }<br>
> ><br>
> > And we receive an error message that our ADCs are not synchronized. As I<br>
> > have no idea what RATACLOCK is, it is hard for me to figure out what is<br>
> > happening.<br>
> ><br>
> ><br>
> > However, there is also the parameter USE_RATACLOCK. It is set to 0 by<br>
> > default. So, maybe it is simply a bug that the check for synchronization<br>
> is<br>
> > executed just on the basis of if (self->config.has_rataclock_receiver ==<br>
> 1),<br>
> > while not also checking for if (self->config.use_rataclock == 1)?<br>
> <br>
> It sounds like it.  Could you see if things work if you add such a check<br>
> (i.e. only do that rataclock sync check if use_rataclock == 1)?<br>
> <br>
> > But shouldn't the expectation be that the ADCs are always synchronized?<br>
> So,<br>
> > maybe this is still a problem with the configuration of our module?<br>
> ><br>
> ><br>
> > Sorry for this confusion. I would really appreciate if someone could<br>
> explain<br>
> > what is going on here 😊<br>
> <br>
> Cheers,<br>
> Håkan<br>
> <br>
></div>
</span></font>
</body>
</html>