search

cms-gem-daq-project / ctp7_modules

0 stars 13 forks source link

[Feature Request]: Reed-Muller Encoding Applied From ChipID 6101 #106

Open bdorney opened 5 years ago

bdorney commented 5 years ago

Brief summary of issue

In the VFAT3 meeting last week we discussed that for chipID's from 6101 we would use the Reed-Muller encoding; however we will need to (at least in the lab) work with VFATs that use reed-muller encoding but also those chips that do not use any encoding. We will still need to query the DB for calibration info and so it would be useful to try to extract chipID info for those chips.

While getVFAT3ChipIDsLocal has a flag for returning the rawID I would say that it should be changed such that if the rawID could be less than or equal to 6100 it never applies the Reed-Muller encoding.

Having looked at that list of numbers of raw and encoded numbers that @jsturdy circulated the only number that has a raw ID less than or equal to 6100 when converted to decimal is 0x0. So in this case all reed-muller encoded numbers pass this (except 0x0 which isn't used).

So this would enable the function to work with both chips in lab and the production set.

Types of issue

Expected Behavior

See above.

Current Behavior

Right now the chipID will either never be decoded or always be decoded which won't really work with multiple test stands.

Context (for feature requests)

We will need to maintain multiple test stands both with old/new hybrids; so we need some mechanism to accommodate this situation.

jsturdy commented 5 years ago

The problem with implementing this mode would be that you can't control where a bit flip will occur. In a non-encoded VFAT, this can randomly result in the raw ID triggering the Reed--Muller decoding (it will likely fail, causing a re-read, but may not). Likewise, even in the case of the encoded VFATs, if a bit flip occurs that would result in the raw ID being "low enough", you'll get the wrong ID still

Is there a table of VFATs, fused chip IDs, encoding mode? Don't need a full table, would be sufficient to have, e.g., (edit table dropped from initial reply...)

number of VFATs chip ID range encoding mode
500 0--500 unencoded
100 0--100 RM encoded
100 6101--6201 RM encoded

At some level, non-encoded VFATs have no business being in any production DB and should always be handled "manually", but we don't live in a perfect world...

bdorney commented 5 years ago

There are O(1e3) VFAT3s mounted on HV3b_V2 hybrids that had their chipID's burned without RM encoding. Sadly the ID range was not continuous. However for sure all VFATs with chipID's from 6101 (inclusive) will be RM encoded.

These HV3b_V2's will not be used for production chambers for P5 but they are already in the production DB. I guess that they will be in circulation for test stands for sometime to come...

jsturdy commented 5 years ago

There are O(1e3) VFAT3s mounted on HV3b_V2 hybrids that had their chipID's burned without RM encoding. Sadly the ID range was not continuous.

And the RM encoded chips are already starting from above this range? Or for some unknown reason did someone think it was a good idea to have duplicate IDs?