Hub-Module Firmware E-log
----------------------------------------------------------------------------------------------------------------------------


                                                                                                 Original Rev.  10-Jan-2022
                                                                                                  Current Rev.  10-Jan-2022

----------------------------------------------------------------------------------------------------------------------------

10-Jan-2022 (Pawel Plucinski)


Yuri programmed HUB FPGA (flash) in all HUBs in the STF (HUB14 in STF1, HUB6 in STF3, HUB7 in STF4) with the latest FW.

https://web.pa.msu.edu/hep/atlas/l1calo/hub/firmware/FW_releases/STF/HUB/production/v2.4/


----------------------------------------------------------------------------------------------------------------------------
13-Jan-2022 (Pawel Plucinski)


Message from Rhys:

Good news is that it looks like we are definitely seeing back-pressure messages all the way in the ROD.
Less good news I think it might be inverted somewhere in the chain XOFF should mean that back pressure is asserted and XON
that data should flow but it seems to behave the opposite so far. Also for Ian designing the patch cable I am not sure if
I understand all of the numbers on the cassettes  but that could just be my normal key-up-down confusion... 
I can make a more accurate table if the picture is not clear.

The Felix <-> hub/rod cable was replaced with a set of plain trunk cables and breakout cassettes such that the exact mapping
could be altered on the fly with LC-LC patch cables.

The mapping was updated to connect channel 0 from the felix output to channel 7 on the hub input. Rod to felix fibres were
connected to maintain the current mapping 2,4,6,8 -> 6,7,8,9. With this mapping set up it was noted that the fibre order
on the cassettes was reversed compared to the target numbers. With the hub powered up again it automatically enabled
the rod indicating that the clock could be recovered from the felix link.

[rhowen@pcl1c-stf-felix-02 15:34:09 ~]
$ fexoff set
Link 0 XOFF: ENABLED
Link 1 XOFF: ENABLED
Link 2 XOFF: ENABLED
Link 3 XOFF: ENABLED
Link 4 XOFF: ENABLED
Link 5 XOFF: ENABLED
Link 6 XOFF: ENABLED
Link 7 XOFF: ENABLED
Link 8 XOFF: ENABLED
Link 9 XOFF: ENABLED
Link 10 XOFF: ENABLED
Link 11 XOFF: ENABLED

Was used to enable back pressure on all channels, then the following commands were used to generate back pressure

[rhowen@pcl1c-stf-felix-02 15:48:40 ~]
$ for LINK in {0..11}; do fexofftx -G $LINK; done
Link 0: XOFF generated
Link 1: XOFF generated
Link 2: XOFF generated
Link 3: XOFF generated
Link 4: XOFF generated
Link 5: XOFF generated
Link 6: XOFF generated
Link 7: XOFF generated
Link 8: XOFF generated
Link 9: XOFF generated
Link 10: XOFF generated
Link 11: XOFF generated
[rhowen@pcl1c-stf-felix-02 15:50:40 ~]
$ for LINK in {0..11}; do fexofftx -G $LINK; done
Link 0: XON generated
Link 1: XON generated
Link 2: XON generated
Link 3: XON generated
Link 4: XON generated
Link 5: XON generated
Link 6: XON generated
Link 7: XON generated
Link 8: XON generated
Link 9: XON generated
Link 10: XON generated
Link 11: XON generated

Reading an ipbus register from the ROD we seem to see back pressure when the felix claims xon and no back pressure when the felix
claims xoff which is inverted compared to my understanding however the good news is that the signals appear to be propagated correctly. 
Possible inversion to be followed up with the experts.
----------------------------------------------------------------------------------------------------------------------------