1. FGClite Feedback from BE-CO & SUWG(Smooth Upgrades)
BE-CO Activities for LIU
FGClite Feedback from BE-CO & SUWG(Smooth Upgrades)
Marine Pace, input from BE-CO, BE-ICS, BE-RF.
NB: Input from Post Mortem Analysis is included in TE-MPE talk.
FGCLite Feedback Meeting - 4 May 2017
Marine Pace, BE-CO

2. Thanks for this constructive initiative, useful and appreciated.
BE-CO Activities for LIU
Thanks for this constructive initiative, useful and appreciated.
FGCLite Feedback Meeting - 4 May 2017
Marine Pace, BE-CO

3. Feedback from CO Hardware/Firmware team (Eva, Javier, Tom)
CO learnt by chance about the EPC Gateware (FPGA) issue
Solved quickly by involving Tom W (CO-HT) mid March. This allowed to resume the FGClite deployment & not to rollback.
What we would like to see: EPC-CO enhanced collaboration (acknowledged mutual interest from both teams).
Collaboration in Distributed I/O Tier electronics (DIOT) design 
Would have allowed to debug the above FPGA bug earlier through a natural process of joint design review.
Long term proposal (as this requires to converge on electronics): a joint EPC-CO design for a common DIOT.
Meanwhile, CO would like to stay in the loop for any new electronics development by EPC.
Validation of new masterFIP on FFGC2 and on FGClite
Before launching a large (500) production of masterFIP boards, CO interested in testing them on EPC GW with FGC2 and FGCLite. Collaboration just started.
Javier as CO contact.
CO to be kept regularly updated to be able to agree on a meeting point to launch the design of the DIOT.
FGCLite Feedback Meeting - 4 May 2017
Marine Pace, BE-CO

4. Feedback from CO LSA & SEQUENCER team (Roman)
What when well with FGC new class integration:
Excellent CO-EPC communication during migration process.
API compatibility (FGC-51 > FGC_92) preserved.
What went less well:
LSA had to identify and inform (non-CO) application developers
List of devices for migration late.
Important: LSA was not involved in design phase of new FGC
=> Overhead to manage several device types (FGC classes) for a given accelerator : complicated design of SEQUENCER (to keep the OP interface simple) & duplication of LSA configuration
How we would like things to change:
All LHC FGC classes hidden behind a unique API interface.
Collaboration CO + EPC + OP at design stage.
This is a general requirement -> see next slide
SEVERAL device types for a given accelerator complicated the design of SEQUENCER (to keep the OP interface simple) & the configuration of LSA (code duplication)
impact on OP :
more complex to use LSA GENERIC tools (as exposed to the multiple types)
In the current state due to introduction of multiple FGC types it is not anymore possible to execute LSA HW commands atomically for all the PCs – we have to do it per FGC type. Basically now the generic nature of LSA get in conflict with LHCOP requirement for atomic operations on FGC.
API compatibility in general: for Sequencer, for LSA, probably for CALS, for any other application
* list of devices was given to us in March: it was not too late, but we had to split the work in pieces, being blocked waiting for the last piece of information
* LSA team (and OP) were not involved in the design of the final solution mixing different FGC types. It is not about FGC class design which was kept similar to FGC_51 and therefore was ok
* In LSA we had to duplicate configurations: LHCOP would like to operate all the FGC types in the same way
FGCLite Feedback Meeting - 4 May 2017
Marine Pace, BE-CO

5. Feedback from SUWG (Brad Schofield, Ylenia Brischetto)
Insufficient communication of the changes induced by new FGC class
Impact and work on client were under-estimated & communicated late
cf TE-MPE, EN-STI talks
Impact of this change was not clearly communicated to the SUWG
No change of API was announced ! (a human error)
Some operational clients were not identified
BE-RF (FESA2 class reading FGClite data)
Too late for RF to adapt the code, temporarily rollback to previous version.
BE-ICS (Circuit Synoptic)
“Migration was no backwards compatible. incorporating the change in a complete way would imply considerable dev work.”
Resolved with a work-around.
How we would like things to change:
Need a system to identify all dependent clients connected to a new class, before deployment.
Brainstorming just started.
Apply CO3-agreed procedure: OP + EPC + CO/ICS should formally agree -at design stage- on the operational interface of each new class.
FGCLite Feedback Meeting - 4 May 2017
Marine Pace, BE-CO

6. Concluding Remarks
EPC had a challenge … and succeeded in deploying a massive amount of FGClite during EYETS.
One critical initial issue with FPGA gateware but finally quickly solved.
The main difficulty & strongest impact was the FGC SW Integration in the controls system.
Very positive approach from EPC to seek for collaboration & improvements.
Collaboration areas:
Automatic detection of dependent products before a class deployment
Agreement on the class API at design stage
How to avoid proliferation of FGC types (generating complexity for development team + Operation) ?
Establish EPC-CO collaboration on the Front-End Software evolution project whose aim is to provide a common framework for FGC, FESA, + other FMWKs (cf CO3 presentation today)
FGCLite Feedback Meeting - 4 May 2017
Marine Pace, BE-CO