Patches from EcalSMM on Bittware

[tomeichlersmith]

Just having this PR open so folks know where I'm pushing developments while working on this and to have a place to keep any notes on progress out in the open.

Right now, I have not been able to get the driver to load on the machine hosting the Bittware, so I'm blocked by that issue (unrelated to pflib). I'm hopeful that, since the HcalBackplane move from ZCU to Bittware went pretty smooth, that the EcalSMM will as well. 🤞 also hoping I didn't just jinx it 🤞

• add state names for ECON PUSM
• add config for a single EcalSMM Bittware teststand

[tomeichlersmith]

Good News: I figured out how to get the firmware loading and the driver enabled after working with the BittWare support folks. I've written my notes into a wiki page in slaclab/ldmx-firmware: https://github.com/slaclab/ldmx-firmware/wiki/loading-the-initial-firmware

Bad News: The ECON on the EcalSMM is consistently "falling" into PUSM State 5 WAIT_DLL_RESET_DONE. I believe this is a FC timing-delivering issue and was the original motivation to switch to developing on the ZCU. I am going to focus on investigating this issue now.

[tomeichlersmith]

I observed the same "reset-cycle" behavior with a new EcalSMM that was assembled here at UMN with a new solder mask (making the attachments of the boards much more reliable).

https://econ-user-manual.docs.cern.ch/CommonBlocks/pusm/

"reset-cycle"

What I mean by this is that the ECON-D is still in the PUSM cycle when I launch pftool. I copied the ECON.STATUS printout into the ECON's constructor and observe a PUSM State Val of RESET (0), WAIT_DLL_LOCK (6), or most often WAIT_DLL_RESET_DONE (5) on every launch. This conflicts with the behavior of the same board on the ZCU where the ECON shows IDLE (1) in the status after a power cycle.

The new EcalSMM has both an ECON-D and an ECON-T on it and both show this behavior. Interestingly, I am not seeing the PUSM State Val cycle while in pftool (i.e. successive iterations of ECON.STATUS do not display a change in the state val). I think this is either the root cause of the issue or (more likely) just an issue with how I'm reading the state which may require a request-for-update from the Watchdog.