Re-thinking the TTC generator
Going through the various software routines and trying to implement more refined behavior, I noticed that the various TTC module functionalities sometimes overlap and can be tricky to configure properly. Some more features would also be required/interesting, such as the possibility to send TTC commands at a given BX.
Here is a proposal, trying to simplify the TTC module while increasing the number of features. First of all, the TTC input stream is split as follows with the possibility to enable or disable each stream individually:
- Channel-A/L1A
- Channel-B/BC0
- Channel-B/Commands
If an additional trigger input is available on the board, it is configurable through an additional register (per GEM block, in the TTC module). A system-wide register (as currently implemented) is welcome to synchronize the different GEM blocks within a given board. In case both the external trigger input and the TTC input are available, the L1As are combined (OR'ed) if both sources are enabled; the responsibility is on the user/software.
The TTC generator features are replaced as follows:
-
Single generator
The L1A signal and all supported TTC commands (the same as inBEFE.GEM.TTC.CMD_COUNTERS
andBEFE.GEM.TTC.CONFIG
) have a corresponding single generator. This is an additional source on top of the TTC A and B channels (OR) that can be disabled through a register for safety concerns during global runs (or similar). Some signals require precise synchronization in order for the system to end up in a fully functional state. Therefore it should be possible to configure the BX at which L1A/TTC command is issued. This mimicks the most basic behavior of the TCDS. That being said, reproducing sometimes complex TCDS sequences is not needed and can be loosely emulated in software. -
Cyclic generator
The cyclic generators are meant to replace the current L1A and calibration pulses combined generator. Indeed, it is sufficient to include independent L1A and calibration pulses cyclic generators to reproduce the current functionalities, i.e. calibration pulse-only generator and combined generator. In the latter case, the phase relationship between the commands can be ensured through the use of the TTC calibration mode, the typical example being the possibility to take S-curves. -
BC0 cyclic generator
In the absence of a TTC receiver, an additional cyclic generator can be used to issue periodic BC0. Would the user enable the TTC BC0 input and the BC0 generator, the orbit definition would be... flexible... Nevertheless, this helps in the debugging since the source of BC0 is clear and any misconfiguration would lead to significant problems. In addition to the normal cyclic generator options, the BC0 cyclic generator of multiple GEM blocks, within a board or across boards can be synchronized with the first L1A received, similarly to the currentEXT_SYNC_RESET
feature. When set, the BC0 would synchronize itself to the first L1A received, sending a BC0 and OC0 to the system (care must be taken about the timing). Additionally, the register is unset, reporting the success of the synchronization procedure to the user.
Such an implementation relies slightly more heavily on the user configuration, but simplifies the actions and shouldn't lead to a major increase of complicity on the firmware side.
If not strictly part of the TTC generator, remains the question of the PROM-less feature. At the moment, the only way to trigger an OH FPGA re-configuration is to enable the TTC generator (disrupting the BC0), send a single HR (with side effects on the VFAT for example), and disable the TTC generator (disrupting again the BC0). This is not a good option.
The proposal is once again to decouple the features and rely on the software/user to combine them in a coherent approach. If it might sound more complicated, it is in fact easier and allows a better integration in the software, providing function with minimal or no side effects.
The idea is to simply add one more register that would trigger the PROM-less itself, i.e. sending the firmware from the BE to the "PROM" e-links. Resetting the FPGA and putting it in a mode where it can get programmed can already be done with the BEFE.GEM.SLOW_CONTROL.SCA.CTRL.OH_FPGA_HARD_RESET
register or through manual SCA GPIO commands. It also gives the possibility to re-program a single OH FPGA in the system (the feature could already be interesting now for some debugging).
On the other hand, the HardReset, either locally generated or received through the TTC input, would trigger a full re-configuration of the front-end, blaster and OH FPGA re-programming included.