1. ESS Timing System Plans Timo Korhonen Chief Engineer, Integrated Control System Division www.europeanspallationsource.se Nov.27, 2014

2. Timing system requirements Accelerator parameters for timing – Front end frequency is 352 MHz (CERN Standard) – High energy section is at 704 MHz – Master oscillator at 88 MHz (btw: we could also divide from 352 MHz – or even 704 MHz, for that matter) – Repetition rate 14 Hz Dictated by neutron choppers No need to do AC sync (I have been told) – Repetition rate must be programmable No RF pulsing when no beam (power consumption) But “some” devices need still 14 Hz triggers (TBC) 2

3. Timing system requirements Typical requirements for a pulsed accelerator – Triggering of devices – Synchronous acquisition and data handling Long pulses mean a lot of data per pulse! – Distributing beam parameters Machine mode: where will the beam go (target, tuning dump) Beam mode: pulse intensity, length – Repetition rate control Possibly even single pulses – if possible – Timestamping of data ESS challenge: – Interfacing with the machine protection system – Ensuring that machine and beam modes are propagated correctly to all receivers – Synchronization with the target wheel (not as big an issue as it might seem, though) 3

4. Timing system requirements The typical requirements are “easy” – 14 Hz (vs 100 Hz or higher) repetition rate – Long pulses create some issues in data handling For control system in general, not too much for timing More work in software side – Ramping up the beam power; intensity and pulse length – Beam mode handling – Beam synchronous data handling Interfacing to MPS is critical – Or, find a way to make MPS totally independent But I cannot yet imagine how that could be done in a reasonable way 4

5. Functions 5 The ESS timing system (aka event system) can: Distribute synchronous triggers to a (very) large number of devices Triggers can be pulses, electrical or optical, with different properties that can be programmed at the receiving end Triggers can also be software, triggering some action in the IOC (Control Box) By “processing” EPICS channels that read out data, write values, calculate, whatever the IOC is able to do. Can also be non-EPICS actions. Distribute (limited amounts of) data to many receivers synchronously and simultaneously This happens in parallel to the trigger distribution, no effect on accuracy. Limited amount = 2 kilobytes in one transmission. The raw speed depends on setup but can be up to 125 MB/sec (even faster in the ESS generation hardware) A single transmission takes some microseconds (~2 us for the raw transmission) Distribute synchronous timestamps (long story to explain how this works) Generate (programmable) sequences of triggers (events), RF synchronized Accept asynchronous inputs to generate events Synchronize to an external input trigger with optional phase adjustment And many more things…(distribute clock signals, take in interlock inputs,…)

6. Structure of the system Fan-out system can (and will) have many levels. Synchronization accuracy will not be affected by how many levels there are The (accelerator) synchronization frequency (of 88 MHz) will be fed into the master event generator and used as the system clock. Downstream will be synchronized to that. The 14 Hz operating frequency will be generated by a method (TBD, e.g., target wheel rotation) and also fed into the event generator Events and (limited amounts of) data can also flow upstream (optionally) Master Event Generator RF Generator fanout Event receiver Event receiver 88 MHz fanout Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Triggers Software synch (IRQ) Timestamps Data Control & setup

7. Synchronous data collection 7 Master Event Generator RF Generator fanout Event receiver Event receiver 88 MHz fanout Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver Event receiver I/O CPU Event receiver Event receiver I/O CPU Event receiver Event receiver I/O CPU Each IOC (control box) receives the same events Event triggers reading out a piece of data (detector, AD converter, status bit/word) Data is timestamped and put into a “silo” (possibly with pulse numbering, TBD) Data can be streamed out (continuous recording) or read out as chunks (finite length)

8. Issues to be considered Synchronizing with “slow” devices with no EVR – PLCs, etc. – We need to be able to correlate data – NTP server in EVG IOC? Is it sufficient? Handling user’s devices – Oscilloscopes, etc. (known issue) Access to API & hardware interfaces? – Purpose-built devices: detectors, etc. No standard interfaces There is still time to think about this, though. – Integrate EVR directly into user hardware is one possibility. 8

9. Summary ESS timing requirements are not too different from other pulsed accelerators Machine protection is a big issue, though – One single mis-steered pulse will break the machine Platform (form factor) is pending final decision – Lots of push for microTCA, though – How to integrate other devices? Project timespan is an issue – We are building now something that will be in full use after 10 years, and have an expected lifetime of 40 years – Roadmap for upgrades and technology refresh Collaboration is very much appreciated! – Sharing of knowledge, applications, ideas… 9