Napoli October 2007 WG3 - Pierre Edelbruck FAZIA WG3 – Front End Electronics

Napoli October 2007 WG3 - Pierre Edelbruck Digital Electronics Dual channel preamplifier Simultaneous charge and current outputs Charge: energy and timing information High speed, High resolution digitization (100 Ms/s 14 bit) Energy extraction through digital shaping Timing extraction through pulse shape analysis Digital trigger Current: pulse shape analysis Ultra High speed digitization (2 Gs/s)

Napoli October 2007 WG3 - Pierre Edelbruck Channel structure

Napoli October 2007 WG3 - Pierre Edelbruck Digital Electronics Advantages: High flexibility through VHDL / Software programming Possible sophisticated trigger algorithms “Pretrigger” capability: past information still available after trigger Reduced or no dead time Hardware ADC Linear Technology LTC 2254 (100 MHz, 200 MHz available) FPGA Xilinx - Spartan III Up to 5 Million gates Embedded memory (1872 kbit = 100 kword = MHz) Arithmetics DSP ADSP-2191 (single chip 16 bit) Analog pipeline:1236 samples, 2 Gs/s, 50 Ms/s (25 µs)

Napoli October 2007 WG3 - Pierre Edelbruck Project Status 2 prototypes built in Jointed development in Florence and Orsay VHDL and software VHDL Interfaces with DSP, VME, stand alone USB Handling of the Analog Pipeline Various housekeeping tasks: offset compensation etc. Storage and readout of both charge and current waveforms Hardware, continuous, trapezoidal shaping Fast trigger with fast trapezoidal filter High speed analog inspection line (100 Ms/s DAC)

Napoli October 2007 WG3 - Pierre Edelbruck Project Status Software Stand alone development bench (USB-Labview) Noise evaluation module (ENOB calculation) Calibration of the analog pipeline Hardware for the Legnaro experiment VME carrier boards 8 FEE boards, revised PCB PACI with patch panels

Napoli October 2007 WG3 - Pierre Edelbruck

Napoli October 2007 WG3 - Pierre Edelbruck

Napoli October 2007 WG3 - Pierre Edelbruck

Napoli October 2007 WG3 - Pierre Edelbruck

Napoli October 2007 WG3 - Pierre Edelbruck Trigger

Napoli October 2007 WG3 - Pierre Edelbruck Energy shaper

Napoli October 2007 WG3 - Pierre Edelbruck Global System Architecture 1 telescope = 2 Si + 1 CsI (photodiode) Single telescope area = 20 x 20 mm 2 Coverage = 4  If R detector = 1000 mm  telescopes If R detector = 500 mm  telescopes  preamp (if no PD)  analog channels

Napoli October 2007 WG3 - Pierre Edelbruck System architecture Massive channel count requires (some) organisation Tree structure proposed Bottom level = detector with front end electronics Intermediate level = regional : gather FEE information Top level = DAQ & global trigger Objective: Reduction of the connection count Closer to the top of the hierarchy = less wires ! Possibly push the entire bottom level INSIDE the vacuum chamber Positive side effect: Very short analog path from PA to ADC

Napoli October 2007 WG3 - Pierre Edelbruck System Architecture Detector level Regional level Data & trigger processing regional boards 1000 FEE telescopes DAQ + Global trigger FEE PACI

Napoli October 2007 WG3 - Pierre Edelbruck Module for 4 telescopes

Napoli October 2007 WG3 - Pierre Edelbruck Issues A few issues to work on … High power to be evacuated through conductive heat sink Any decision about neutrons ? Data and trigger path to be designed Can we design a hierarchical trigger system ? Nota bene The thermal issue is critical and requires a careful design Wiring issues will have to be solved anyhow coaxial cables are not transparent to neutrons either

Napoli October 2007 WG3 - Pierre Edelbruck Architecture shopping list Angular resolution as a function of  and  Counting rate as a function of  and  Resolution for Time of flight (100 ps ?) Modularity Do all telescopes look the same ? (shape & size) Do we want to remove / replace a section ? Energy range and resolution Do we have (or can we be) ancillaries ? Do we want transparency ? If yes, what is transparency ?

Napoli October 2007 WG3 - Pierre Edelbruck Trigger First Reflections (MF Rivet) Trigger must be hardwired Asynchronous mode: local trigger + global validation Path should be fast in both directions (dead time reduction) Organization Multiplicity based on telescopes (not just single detectors)  Three detectors in the telescope managed by the same unit  All three sets of parameters always recorded Coincidence window ~ ns Validation time < µs, Star distribution Clever telescope grouping in order to balance counting rates

Napoli October 2007 WG3 - Pierre Edelbruck Trigger Miscellaneous More elaborated information may be useful (additional threshold) Need for a slow trigger to accommodate ancillary detectors or elaborated software trigger Nature of the trigger information packet to be defined Trigger system must be fast with dedicated lines Pulser Avoid firing all telescopes at the same time ! Other lines also required Clock RF …

Napoli October 2007 WG3 - Pierre Edelbruck Trigger Giacomo’s note 1 Local Trigger - Global Validation scheme Only those detectors who have fired transmit data Fine timing (100 ps) performed offline 2 Local trigger to be fast and low threshold Use digital filtering to lower threshold Walk should be kept low (CDF ?) 3 Multiplicity is not enough A rough estimate of the energy would help Position information is also important, also how many stages in the telescope have fired Necessity of a programmable “trigger box”  Program based on the nature of the experiment

Napoli October 2007 WG3 - Pierre Edelbruck Trigger 5 Refinement An intermediate energy shaping could be performed, leading to a lower threshold, information available after local trigger but before validation. 6 How do we physically organize the up and downstream communication path ? 7 What hardware ? Why not an optical fiber. 8 Dead time and event recognition Event-counter and/or time stamp required ?

Napoli October 2007 WG3 - Pierre Edelbruck Trigger Comments on Giacomo’s notes (Pierre) System is fully digital Past information fully available for several µs Front End never stops working  No dead time (with the exception of the MAR chip)  Latency exists but should not hurt Dead-time, Latency, Walk and Spread are four different things Walk may reduce coincidence quality  digital DFC to be designed. Spread is more complicated No strong real time requirement if events clearly dated Time stamping with 10 ns resolution to be implemented Required unique clock source for the whole system

Napoli October 2007 WG3 - Pierre Edelbruck Trigger A meeting in Florence