napoli october 2007 wg3 - pierre edelbruck fazia wg3 – front end electronics
TRANSCRIPT
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
C on tro l
P ip e lin e2 G S /s
AD C 15 0 M S /s
AD C 21 0 0 M S /s
D ig ita lM em ory
S h ap e
D ig ita lF ilters
D S P
D ig ita ltr ig g er &T im in g
C h arg e
C u rren t
Inte
rfa
ce
D é tec tor
T o D AQ&
T rig g er
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 = 1000 µs @ 100 MHz) Arithmetics
DSP ADSP-2191 (single chip 16 bit) Analog pipeline:1236 samples, 2 Gs/s, readout @ 50 Ms/s (25 µs)
Napoli October 2007 WG3 - Pierre Edelbruck
Project Status
2 prototypes built in 2005-2006 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 mm2
Coverage = 4 If Rdetector = 1000 mm 31 000 telescopes
If Rdetector = 500 mm 7 800 telescopes
15 600 preamp (if no PD)
31 200 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
1
100 regional boards
1000 FEE
10000 telescopes
DAQ
+ Global trigger
FEE
PACI
Napoli October 2007 WG3 - Pierre Edelbruck
Module for 4 telescopes
Connector
FP
GA
80
1 60
CO
LD
FR
AM
EP ream p
40
Pream p
MA
RM
AR
MA
RM
AR
MA
RM
AR
MA
RM
AR
FP
GA
DS
PD
SP
CsI
Si-2
Si-1
50
CsI
Si-2
Si-1
CsI
Si-2
Si-1
CsI
Si-2
Si-1
CsI
Si-2
Si-1
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 30 000 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 ~300-400 ns Validation time < 1-1.5 µ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