New Feature: Updates to DAC & GBT Phase Scans

[bdorney]

Description

Before a DAC scan is launched L1A's will now be disabled and VFATs will be taken out of run mode before configuring DAC Monitoring on all VFATs.

The GBT phase scan will no longer check the LINK_GOOD register as it was largely useless for checking communication status. Now each GBT phase scan point will attempt several slow control transactions per point before declaring the phase as good.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context

During QC7 tests saw that it was possible to generate both bus errors and out of sync states for VFATs in cases where the VFAT was placed into run mode and then subsequent slow control actions were performed. This caused crashes or unintentional masking of VFATs.

Also improves reliability of phase scan results.

How Has This Been Tested?

Extensively on QC7 setup.

Screenshots (if appropriate):

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[jsturdy]

As per discussion in #116, this may not the best way to solve this.

To better understand use cases, will there ever be a case where a DAC scan is being run on VFAT(s) on one OptoHybrid connected to a given AMC, while other OptoHybrids are actively participating in "data taking"?
If so, we could consider asking @evka85 to have the INPUT_ENABLE_MASK also serve as a per link trigger blocker. This would of course need to be weighed against the potential use case where a given OptoHybrid is not participating in data taking, but one still wants to have the front end receive L1As...

As I currently understand it, this routine itself should never be running when one is expecting the VFAT data formatter to be active, right?
So, I would instead ensure that whatever is driving should ensure that things are properly configured for the desired operational mode (i.e., much further out ensure that L1As are not being sent), rather than relying on this mechanism to potentially mask another issue.

Actually this raises another question, can you verify whether it was an active data formatter block that was the likely culprit (check if the EC counter is rolling up)?
Because if this was not the case, then although this solves the current problem, the underlying issue is still there and needs to be understood.

One can consider if this routine itself should only be run when the VFAT is in SC Only mode (as per #116 discussion), and if so, then this solution is likely to be appropriate (or at least, part of the appropriate solution).

[bdorney]

Yeah further study and the best way forward is needed. I'll come back to this on Monday.

[bdorney]

@jsturdy @mexanick ready for review

[bdorney]

@jsturdy @mexanick changes to readReg were reverted. Ready for re-review. Also this branch (v1.1.X) is not protected...not sure if that's intended.