Special MPP-SMP v2 Meeting

The meeting took place on Friday, June 21st, 2019, at CERN.

Participants: V. Kain, L. Jensen, J. Uythoven, I. Romera Ramirez, M. Zerlauth, B. Todd, C. Martin, T. Levens, G. Kruk, J.-C. Garnier, K. Li, A. Apollonio, F.M. Velotti, B. Mikulec, N. Magnin, F. Tecker, D. Nisbet, M. Solfaroli Camillocci, R. Secondo.

The slides of all presentations can be found on Indico.

Overview of the Present System (I. Romera Ramirez)

Ivan presented the layout of the present system, its evolution since the first deployment, the general dependability of the SMP and the motivation to upgrade it.

Discussion

• G. Kruk commented that an LTIM class can be stopped and a CTRV/CTRP board would continue pulsing; the LTIM is needed only to configure the CTR at start-up. A CTR board would still work without the class running if relying on the pulses, not on the interrupts. At start-up, the correct configuration of the LTIM class is critical.
• Ivan pointed out that in the past there was an issue with one of the BCTs. A filter to overcome this issue was realized in the SMP. M. Zerlauth commented that changes were implemented also on the BCT side; these changes are still running in the present system. T. Levens clarified that some dedicated hardware was designed.
• B. Todd recalled an issue between BA4 and BA3 transmission which was possibly not in the list of "faults" given by Ivan.
• V. Kain recalled an issue with transmission of data from the BCT, which resulted in once injecting into an empty machine. L. Jensen put software protection in place, which never triggered since.
• Clarification on the LHC BCT Beam 2: the SMP uses 1 out of 2 logic.
• M. Zerlauth asked if there are statistics referring to problems "downstream" of the SMP. Ivan replied that so far no dumps were caused by the cross-checker. There is no data referring to issues in decoding GMT frames. G. Kruk commented that the cross-checker is present only on the SMP system; no checks are executed in case of an issue of the timing distribution. However, on the CTRV side there is a check for lost frames.

ACTION (MPE-MI): Check how the cross-checker verifies the validity of GMT distributed frames.

Feedback from LHC Operation (M. Solfaroli Camillocci)

Matteo gave general feedback on the SMP from the LHC operators, addressing each of the parameters broadcasted by the SMP system for the LHC machine.

Discussion

• The Energy parameter given to the BLMs is considered highly critical; it is broadcasted via timing and proved to be working reliably.
• The Beam Presence Flag, used by the SPS extraction BIC, is based on the LHC BBQ, which worked extremely well.
• Configuration of the SMP so far was quite good and should stay as easy as possible.
• The Squeezing Factors are generated by the SIS, therefore by software at a higher level. One could ideally directly put this information into timing without passing through the SMP, although the SMP does not constitute a problem for the broadcast.
• Regarding a possible Maximum Bunch Intensity parameter for the LHC, no clear interlock solution/strategy exists; OP proposes to wait on this matter. J. Uythoven suggested that a design for an SMP v2 version should consider the possibility of adapting to a Max Bunch Intensity connection/broadcast. T. Levens commented that it would be possible to plan a common solution with the SPS as well. It was agreed that a bunch-by-bunch intensity is not needed, only values like maximum, mean and/or average bunch intensities, which can easily be provided by the FBCT.

ACTION (MPE-MI, BE-BI, BE-OP): Define a strategy for the LHC maximum bunch intensity. Try to implement a common solution to both SPS and LHC.

Feedback from SPS Operation (V. Kain)

Verena gave general feedback on the SMP system from the SPS operation point of view, commenting on new possible requirements and needs for an upgrade.

Discussion

• There was the request to adjust the probe beam flag and TED beam flag by MCS.
• The SPS Ring BIS does not use the SMP for masking at present. A future North Area extraction BIC might take into account beam types and destinations directly decoded from timing or passed on by the SMP. B. Mikulec stated that LINAC4 might also be interested in such a use-case, and similarly PS and PSB. In addition, right now it is hard to set masks manually, especially during MDs.
• V. Kain stated that it is a good idea for a circular machine to distribute beam information: OP would greatly benefit from intensity and energy being distributed, but the same can be applied to other parameters (e.g. optics, emittance, maximum bunch intensity).
• Energy and intensity of SPS are a necessary requirement to protect instrumentation. BI instrumentation will also suffer from 288 LIU bunches, therefore BI would be interested in having SPS energy and intensity distributed on timing.
• Ideally it would be good to have the intensity distributed before injection, coming from the PS BQM system.
• SPS parameters are at present transmitted with 100 ms period on the GMT. For future frames distribution, 10 ms would be required. B. Todd asked if many of these parameters need to be distributed safely by the SMP or rather just sent directly via GMT; this is yet to be clarified.

ACTION (V. Kain): Check if there was in fact any availability issue in the SPS in the past.

ACTION (MPE-MI): SHIP destination flag or NA destination flag are not energy related. Check possibilities on how this destination should be transmitted (Timing to BIS or Timing to SMP to BIS).

ACTION (MPE-MI, BE-OP, BE-BI): Clarify the needs of max, mean, average bunch intensity.

BI Connections to SMP (L. Jensen)

Lars briefly introduced the present structure of the BI sources and their connections to the SMP.

Discussion

• The Probe Beam Flag has one source with redundant connection. A second source was not needed so far but can be added for redundancy.
• Regarding Bunch Intensities, for both SPS and LHC, T. Levens commented that the BCT can send to the SMP the value of maximum / mean / average instead of the individual bunch intensities. The precision of absolute values is in the percent level.
• The BCT5 was added due to its lower noise level.
• Together with a possible max bunch intensity, the number of bunches should be transmitted as well.
• L. Jensen commented that having energy on the timing network would be of great interest for BI as well.

ACTION (BE-BI, MPE-MI, BE-OP): Do we need redundant BA4 intensity for Probe Beam Flag calculation?

LS3 Plans for Timing and Beyond (G. Kruk)

G. Kruk presented the system plans for LS3 and the considerations on the implementation of White Rabbit (WR).

• The present GMT is already quite filled up. There is a possibility that it will be replaced by White Rabbit after LS3, greatly increasing speed and bandwidth. Within BE-CO nothing is yet decided but BE-CO is setting up a request to install the optical network between 2021 and 2025 for a possible implementation of WR between 2023 and 2029, with a prototype installation during Run 3.
• If WR is not funded, the GMT will very likely continue as present until the end of LHC running; the CTRV will continue being supported. If WR is installed, the present GMT is likely to be removed in the future.
• Estimated price for WR is about 4 MCHF for all machines CERN-wide: half for hardware, half for installation. B. Todd commented that the estimated price might not include the cabling to the end-users.

ACTION (BE-BI, MPE-MI, BE-OP): Beam Intensity and Machine Energy can also be distributed over GMT directly and not over the SMP. To be followed up in the coming weeks.

ACTION (BE-CO): Keep MPE-MI updated on the planning decisions related to White Rabbit deployment.

SMP v2 Hardware Implementation and Timeline (R. Secondo)

Raffaello introduced the general hardware requirements for the SMP v2, in particular in terms of synergy with the BIS v2 project.

• Since no clear decision has been taken on the timing network layout, the SMP v2 should be able to connect to both the present GMT and White Rabbit. The use of SFP transceivers as in the BIS might enhance monitoring of the transmitted flags.
• Since the CIBF is a common hardware between BIS and SMP, if the CIBFc will be eliminated for the BIS v2, then the same should be applied to the SMP v2 as well, requiring a change of the present SMP backplane.
• The present CISV is based on an old CTRV board developed by CO. This board is hard to maintain, and the new CTRVD has never been used to receive SMP frames.
• An alternative layout to broadcast SMP frames/flags via a dedicated BIS channel rather than using the GMT was shown. B. Todd commented that this solution might lead to longer development times and to an SMP integrated with the BIS which should rather be avoided.
• An early prototype of the SMP v2 shall be installed in 2023 for a reliability run in parallel with BIS v2.
• For injectors, the SMP shall be avoided for the generation of flags, but it might be interesting for broadcasting information that can be used to apply masking.

Follow-up

• The SMP v2 shall follow the BIS v2 developments in terms of hardware choices, in particular the VME platform with its backplane, the SFP use and the CIBF design.
• The timing network is a key component of the SMP; the realization of WR will have a large impact on the SMP v2 design choices.
• Consider if the SMP is required as "intermediate" for supplying certain information distributed over the timing system. Possibly the SMP can be used to guarantee the correctness of the information by checking it against another source.