150 likes | 334 Views
PSI/SLS Timing Master and Slaves. Timo Korhonen PSI. Overview. Recap: functions of a timing system PSI timing hardware (and beyond) What are we doing with it? What (else) could be done with it? Interfacing to EPICS Summary. Timing Systems Recap. Timing system functions:
E N D
PSI/SLS Timing Master and Slaves Timo Korhonen PSI
Overview • Recap: functions of a timing system • PSI timing hardware (and beyond) • What are we doing with it? • What (else) could be done with it? • Interfacing to EPICS • Summary
Timing Systems Recap • Timing system functions: • Make actions happen at defined times • Timekeeping (clock): real-time or “cycle” • Common approaches: • (Baseband) pulse distribution & delays • Discrete event systems • Synchronized data (events) broadcast • Different level of complexity & functions
SLS Timing Hardware • Media (hardware): • Gigabit Ethernet Physical layer (raw data frame transmission) • 50 MHz 16-bit frame rate (can be adapted) • Functionality (firmware): • Adopted & enhanced the APS Event System functionality • The media can do more and/or different things than what we currently do at SLS! • The APS functionality matched well our requirements
SLS Event system Technical Features • Technology: Gigabit Ethernet (physical layer) • short wavelength (860 nm) fiberoptic transceivers, multimode (50/125 um) fiber • up to 550 meter range, 1300 nm transceivers could be used for longer range (up to 10 km) • 16-bit data frames sent at 50 MHz rate • Synchronized to the main RF oscillator through direct clock input (or use internal clock) • XILINX Virtex FPGA for the logic, loaded from Flash ROM (in-system reprogrammable) • FPGA code about 4000 lines of VHDL for EVR & EVG (each) : separation of HW platform and functionality
Future: Diamond Event system • Further development by colleagues at Diamond and Micro-Research, some contribution by PSI (to ensure compatibility with our existing system) • Higher frame rates, 2.5 Gbit data rate • Integrated RF clock recovery (in receivers) • High-resolution delay generators integrated • Full VME64x implementation • Improved VME interface (higher bandwidth) • XILINX Virtex-II Pro FPGA (with an integrated PowerPC CPU core)
(SLS) Timing Hardware Capabilities • 50 MHz 16-bit frame rate • 8 bits used for events, • 8 bits “free”. At SLS, these are used for distributing discrete clock signals. With a simple extension these could be used to broadcast arbitrary data at a maximal rate of 50 MB/s (in practice, would be limited by the IOC/VME bus bandwidth.) • For example: • Transmit beam “codes” as data and the strict timing as events. In this way, pulse-to-pulse control information can be transmitted together with the events. Delays from events can be generated locally with the receivers.
Event Distribution • Event codes representing timing fiducials are sent out at the frame rate from a single generator to multiple receivers (fanout) • The stimulus to send an event can be: • a hardware input pulse • a software event (write to a register) • an entry in an event playback RAM . • Upon receival of an event code the receiver can: • output a pulse, of specified delay and width • process an EPICS record • Each event receiver's response to an event can be independently programmed. • External stimuli are encoded to 8-bit event codes; when no stimulus is present, null frames are sent out
SLS Timing Master • Consists of one Event Generator card, using presently two signal inputs: zero-crossing marker (synchronized with AC line) and a utility frequency • Even these could be generated internally in EG from RF and AC frequency inputs (when using newer EVG version)
Summary • Gigabit Ethernet as a base technology • Widely used, several component sources, reliable • Room for extensions • Functionality implementation in VHDL • Had a good starting point (APS) • Portable to new platforms • Easy to add functionality • EPICS integration • Could use existing drivers and concepts, very big help for a new project
SLS Event receiver • Outputs are phase locked to RF through the local Gigabit transceiver PLL. • programmable pulse and set/reset "flip-flop" outputs. • delay & width generators down to 20 ns resolution • VME interrupt facility for software synchronization (also a hardware-delayed interrupt for fine-tuned software delays) • timestamp counter can count received frames or "tick" events. High resolution timestamp and event number are latched into a FIFO when received • Timestamp & IRQ facilities enable synchronous operations & data acquisition: • EPICS records can be processed when an event is received. The processed records can be timestamped with the time the event occurred (hardware time) • Needs some organization, but is powerful and very precise
Integration with EPICS • Specific records to control the hardware (inherited from APS, extended for new features) • Binding with EPICS “soft” events: dispatch soft events when a hardware event is received • Timestamp support (reminds me of work to be done…)
Integration with EPICS Record types to control the hardware • Event generator • EG record • Set up of the generator: • mapping of hardware signals to events,RAM mode, etc. • EGEVENT record • insertion of events into the event RAM. • Event receiver • ER record • setup of the receiver: • configuration of hardware signals (enable, delay generator setup, etc.) • EREVENT record • event code to output mapping. • Specifies what is the action upon receival of an event.
Integration with EPICS • Triggering an action at a certain time: • Incoming event causes an interrupt • Event record (soft) has been registered to receive this interrupt: record(event, “DOIT:NOW”) { field(SCAN,”I/O Interrupt”) field (INP,”#C0 S<HW event #> @”) field(VAL,”<soft event #>”) …} -other records can be set to process from the soft events. This will happen synchronously at all the crates which are set up to listen to this (hw) event. Applications: setting delays for different cycles, acquiring data synchronously, SW ramps, setup for next cycle, …
Integration with EPICS • Timestamp facility: • Each EVR has a timestamp counter • Can count incoming events or frame clock cycles (after prescaler) • Received events that have been programmed to cause an interrupt cause the event code and timestamp counter value to be put in FIFO -interrupt handler reads the FIFO and updates event times in a table -records can retrieve these timestamps. They are synchronous in all crates that have an even receiver -timestamp counters have to be synchronized and reset periodically (done through network broadcasts)