Update data format

[mexanick]

Data format updated in correspondence to https://docs.google.com/spreadsheets/d/1iKMl68vMsSWgr8ekVdsJYTk7-Pgy8paxq98xj6GtoVo/edit#gid=759184475

Description

• bit 19: If this is set to 1, it means that OH EC/BC FIFO is empty for this event (you can call it OH EC/BC underflow). This is an anomaly, which might be caused by VFATs sending more data than the number of L1As that they were sent, or it could be related to resync handling in OH where the OH clears it's EC/BC buffer before reading out all VFAT data. I don't expect this to happen often or at all, but if it does happen it would be very useful to know that. In case this is set to 1, the BC will always be set to 0xfff, and the EC will be a fake one, but guaranteed to be a different number each time so that the AMC can still separate these events.
• bit 18: this bit is latched to 1 whenever the above mentioned condition happens, and cleared only during the next resync. I would call this bit OH had EC/BC underflow
• bit 17: this bit is latched if the OH ever had EC/BC fifo overflow, and is cleared by a resync (which also clears this fifo). If overflow ever happens, it will result in OH EC/BC going out of sync with the AMC. This can happen if VFATs are missing some L1As, which is indeed the case with the current OH firmware, because a BC0 would cancel any L1A coming in the 3BX window after the BC0. But the new firmware will actually favor L1A instead of the BC0, so this shouldn't happen anymore, but who knows..
• bit 16: this bit is latched to 1 whenever a BC0 is canceled by an L1A, and this flag is cleared when the next BC0 arrives. During the time when this bit is set to 1, the VFAT BC is going to be wrong due to the missed BC0, but can be corrected by subtracting 3564 from the reported VFAT BC with a rollover (that is if VFAT BC - 3564 is e.g. equal to -2, that means the real VFAT BC is 0xfff - 3564 + 2

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

How Has This Been Tested?

Screenshots (if appropriate):

Checklist:

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

[jsturdy]

@mexanick, does #28 supersede this?

[mexanick]

no, they are different

[jsturdy]

Any reason why this hadn't been merged yet?

[mexanick]

I was waiting for Evaldas's review

[jsturdy]

I was waiting for Evaldas's review

Probably going to be a while... :-D