[subexp-daq] Question on COUNTER_DIFF in crate.c

[Weber, Guenter Dr.]

Dear Håkan,


thank you. This explanation makes some sense.


Could you also explain the concept of "shadow module". What is it good for?


Also I would like to point out that the implementation of readout_dt for the V560 module that we used as a reference looks weird to us:


uint32_t
caen_v560_readout_dt(struct Crate *a_crate, struct Module *a_module)
{
    (void)a_crate;
    LOGF(spam)(LOGL, NAME" readout_dt {");
    a_module->event_counter.value++;
    LOGF(spam)(LOGL, NAME" readout_dt(ctr=0x%08x) }",
        a_module->event_counter.value);
    return 0;
}


Here the counter is incremented every time the module is 'touched' by the readout_dt function. In the loop that starts at line 1240 in crate.c the function readout_dt is executed for the module until the test around line 1270 is passed or the timeout around line 1280 happens. Thus an initial mismatch between the (software) counter of module V560 and the crate that prevents the loop from being existed at the first trial will grow steadily as the module is accessed via readout_dt many, many times until it runs into the timeout. What is this good for?


To my (current) understanding it is pointless to try to mimic the function of a true hardware counter within the module by a counter that only exists in software. The better way would be to tell crate.c that this module does not have such a counter so that the check is pointless. Is this understanding correct? And if yes, how can I tell NURDLIB to skip this check?




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: Freitag, 16. Februar 2024 13:25:59
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] Question on COUNTER_DIFF in crate.c


Dear Günter,

I think Hans might have to correct me.

This is not exactly what this code does, but typically the modules have a
trigger/event counter, which is incremented for each gate/common signal
they receive on the front-panel.

When the readout is event-by-event, these counters are checked strictly by
nurdlib, in order to detect cabling issues, double-triggers and so on.
This is especially important for modules that have multi-event buffers,
that otherwise easily can become desynchronised.  (It takes of course some
time to read these counters, which contributes to the overall deadtime.
But the amount of times this has 'saved' data-taking by detecting issues
early make it very worthwhile.)


What the code you refer to is doing is I think 'abusing' this a bit.
There is typically some time (order of us) between the trigger, and when
the signals have been digitised and the data becomes available.  Often,
those counters are only updated after that is the case.  To me it looks
like this function use the counters (which we anyhow want to check) to
wait for the modules to have finished converting one event.


Best regards,
Håkan





On Fri, 16 Feb 2024, Weber, Guenter Dr. wrote:

>
> Dear friends,
>
>
> we are now trying to add a new module into NURDLIB. At the beginning, we just want to have a 'software version' of the module, so no
> hardware involved yet.
>
>
> We are stuck with the following code in crate.c (line 1262 and following):
>
>
>             diff_module = COUNTER_DIFF(*module->crate_counter,
>                 module->event_counter, module->this_minus_crate);
>             /* TODO: Clean this. */
>             shadow_counter.value =
>                 module->shadow.data_counter_value;
>             shadow_counter.mask = module->event_counter.mask;
>             diff_shadow = COUNTER_DIFF(*module->crate_counter,
>                 shadow_counter, module->this_minus_crate);
>
>
> As we understand, the idea here is to check with a call of readout_dt if the module's internal counter agrees with the counter of the
> crate for the given module. Basicly when the crate thinks it has accessed the module n times, the module should report the same number of
> access attempts. Is this understanding correct?
>
>
> If yes, how exactly should the module increment it's internal counter? If this is done on readout_dt, a mismatch between the crate and the
> internal counter occurs as soon as we stop the aquisition.
>
>
> I can explain in more details, but maybe first you can explain to us what the whole idea behind this check is? To us it looks like also
> the dummy module implementation will have problems with it.
>
>
>
>
> Thank you very much!
>
>
>
>
> Best greetings
>
> Günter
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240216/2ea4ddbc/attachment-0001.html>