[feature-request] Add Reed--Muller ChipID decoding

[jsturdy]

Brief summary of issue

The fuse circuit on the VFAT3 chip ID has been shown to result in a strong probability of a (or more than a) bit flip when reading back the fused value from the register. As such, it was decided to encode the 16-bit chip ID to a 32-bit value, using a Reed--Muller cyclic code. The particular choice RM(2,5), allows for 3 bit correction, and in the event of more than 3 errors, will raise an error.

Types of issue

• [x] Feature request (request for change which adds functionality)

Expected Behavior

Do the decoding, and allow for some number of retries before throwing an "unable to decode" error under the assumption that consecutive 4-bit errors will be "rare".

Current Behavior

VFAT3 ChipID has been encoded and burnt to the chip using an RM(2,5) generator on the 16-bit ChipID, resulting in the encoded 32-bit register value. This value must then be decoded to retrieve the original ChipID

Possible Solution (for bugs)

Information from Aamir led to a python implementation, and there is a corresponding c implementation (both licensed under Apache 2.0).

I've currently modified the source code to produce a shared library with the generator and encoding/decoding built in. I ran some tests and verify that the encoding and subsequent decoding handles 3-bit correction flawlessly (tried up to 1000 random flips), and that it will always fail with more than 4 bit errors. The running was not "speedy, but I didn't properly profile anything, so there are probably avenues for improving that step. Additionally, the way the examples work now is based on expecting a string representation of a binary literal, which adds a bit of overhead on the routine, and I'm trying to allow the decoder to simply take an appropriately sized integer (regardless of representation) to do the decoding.

Once this is all sorted, moving forward, I think there are a couple of options:

• A separate library installed to the CTP7 (with devel headers and library also on the build machine)
  • Probably the better option, as this library shouldn't have to change ever
• Add my modified package as a submodule to ctp7_modules (removes the additional external package)

[mexanick]

I would support a separate library solution, as we do with the LMDB.

[jsturdy]

Closed by #95