Behavior of the automatic VFAT masking and recovery

Trying to keep track of something long-discussed... The automatic masking and recovery!

The VFAT should be masked from the DAQ path if any of the following conditions is met:

• the corresponding GBT was not ready (enabled via flag) - what about GBT0? should all VFAT be masked since it is a SPOF?;
• the VFAT synchronization error counter was different than 0 (enabled via flag);
• the VFAT is manually masked in the back-end register (always enabled).

One should note that masking the VFAT from the periodic synchronization checking and from the slow-control communication is not desired. The goal is to prevent the event building to break, not to prevent all kinds of communication with the front-end in case debugging is desired.

Unmasking the VFAT is more delicate. The proposal from always was:

• recover the synchronization errors after ReSync. The communication issue is thought to be associated with VFAT communication issues or e-link transceiver SEU. The VFAT configuration should be stable;
• recover the GBT not ready status after HardReset. In this case, it is unclear whether the GBTx lost its programming or not.

We can also consider adding a new TTC signal for the recovery (at the same level as the ReSync, Start, Stop, HardReset command). It would be the software's task to assign them to a given TTC B-channel command, ReSync, HardReset, or other depending on the findings to needs.

It goes without saying that the final masks of the VFAT enabled/disabled in the DAQ should be made available in some registers and stored in the DAQ bitstream (see #22 for more details). Deriving the reason why a VFAT is masked can easily be done is software if no additional details are available.