<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>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear <span>Håkan</span>,</p>
<p><br>
</p>
<p>thank you very much for explanation. I pushed a new NURDLIB version with a corrected if-statement
<span>at the beginning of</span> the RATACLOCK ADC snyc test. Also for <span>aesthetics</span>, I moved the firmware check to a separate function.</p>
<p><br>
</p>
<p>Please have a look, if this makes sense.</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><br>
</p>
<p><br>
</p>
<br>
</div>
<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> Mittwoch, 29. Mai 2024 17:05:13<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>
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 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 is<br>
> executed just on the basis of if (self->config.has_rataclock_receiver == 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? 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 explain<br>
> what is going on here 😊<br>
<br>
Cheers,<br>
Håkan</div>
</span></font>
</body>
</html>