Detector and DAQ mappings - how will they be organized?

O²
#1

Dear experts,

with the increasing amount of readout electronics being installed in the MCH system, we are starting to face the need for a close-to-final mapping of the readout channels, for FLP down to the detector pads.

My understanding is that the mapping will be split into tow logical units, one describing the detector structure and the other one the FLP/CRU arrangement. The common point between the two mappings will be a unique ID that will be assigned to each optical link.
The detector mapping will be under the responsibility of the detector groups, while the FLP/CRU mapping (i.e. which FLP/CRU/optical connector corresponds to a given unique link ID) will be maintained by the “DAQ” group (I put it in quotes as I do not know the exact group of people that will be in charge of this).

Again, if I understand correctly, during the data processing one will get the CRU ID, the data wrapper path ID and the link number from the RDH, and the above two mappings need to be applied in order to go from there to the corresponding detection elements and readout pads. The CRU ID is an unique number assigned to each CRU and stored at CRU configuration time.

First of all, is the above description correct?

If yes, is there already a consensus on how to define the unique link IDs as well as the CRU ID? In that case we could implement a close-to-final mapping in the MCH system, and use it in the commissioning. The detector side is probably already well advanced, apart from the exact values for the unique link IDs.

Also, for the moment we are using text files to store the mapping tables. Were is this information supposed to be stored at the end? CCDB? Or something else?

In case this discussion is already happening somewhere else, then please just point me to the thread, so that we avoid splitting the topic…

Thanks!

Cheers, Andrea

#2

@costaf maybe you know ?

#3

@bvonhall @costaf any news?

In addition to what I wrote in the initial post, I would like to mention that in our case we would need to store the mapping information in such a way that one could have different configurations with well-defined validity periods, in case something is modified at some point in the hardware.

Also, we would like to keep the history of the modifications to the mapping files, and be able to retrieve a snapshot of the mapping at a given point in time (not necessarily the most recent one).

#4

Ciao @aferrero … we are looking into that.
I am discussing the issue with the CRU colleagues, we will see if these information should be stored by the firmware or if the software could do it.

Keep you posted.
Cheers