Update trigger OH main monitoring regs

[mexanick]

Modyfying trigger OH main monitoring registers according to changes in PR #29 in ctp7_modules

Description

Types of changes

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

Motivation and Context

Required for monitoring software to be even with ctp7_modules

How Has This Been Tested?

Screenshots (if appropriate):

Checklist:

• [x] 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.

[evka85]

Hi Misha,

If I understand it right, you're swapping out monitoring of LINK{0,1}_NOT_VALID_CNT for: LINK{0,1}_MISSED_COMMA_CNT LINK{0,1}_OVERFLOW_CNT LINK{0,1}_SBIT_OVERFLOW_CNT

This is fine, but you could also add LINK{0,1}_UNDERFLOW_CNT. As we talked before, these counters give different information. But the old LINK{0,1}_NOT_VALID_CNT is actually a subset of LINK{0,1}_MISSED_COMMA_CNT, and thus is redundant and has been removed.

Just to reiterate on the meaning:

• LINK{0,1}_SBIT_OVERFLOW_CNT -- this is an interesting counter to monitor from operations perspective, but is not related to the health of the link itself. Rather it shows how many times OH had too many clusters which it couldn't fit into the 8 cluster per BX bandwidth. If this counter is going up it just means that OH is seeing a very high hit occupancy, which could be due to high radiation background, or thresholds configured too low.
• The other 3 counters reflect the health of the optical links: -- LINK{0,1}_OVERFLOW_CNT and LINK{0,1}_UNDERFLOW_CNT going up indicate a clocking issue, specifically they go up when the frequency of the clock on the OH doesn't match the frequency on the CTP7. Given that CTP7 is providing the clock to OH, this in principle should not happen unless the OH is sending complete garbage and thus the clock cannot be recovered on CTP7 side, or the bit-error rate is insanely high, or the fiber is just disconnected, or OH is off. In other words, this indicates a critical problem. -- LINK{0,1}_MISSED_COMMA_CNT also monitors the health of the link, but it's more sensitive, because it can go up due to isolated single bit errors. With radiation around, this might count one or two counts in a day or two. But if it starts running away, that would indicate a real problem, but in this case most likely the overflow and underflow counters would also see it.

I think it's important that the meaning is clear when these counters are reported to the user. Also I think we should reset them during configure state transition (after TCDS has been configured), this can be done by writing to GEM_AMC.TRIGGER.CTRL.CNT_RESET.

Cheers, Evaldas

[mexanick]

missing registers are added

[bdorney]

I guess a separate piece of code will be raising a warning or error state depending on the output of these register reads shown here?

Additionally the same would be true for @evka85's suggestion:

Also I think we should reset them during configure state transition (after TCDS has been configured), this can be done by writing to GEM_AMC.TRIGGER.CTRL.CNT_RESET.

This PR covers only the monitoring of these registers not the follow up action once their values are known, correct?

[mexanick]

Yes. The follow up action will be added later (perhaps to daq_suite, but possibly to another piece of SW)