itop System Overview Kurtis Nishimura University of Hawaii October 12, 2012 US Belle II Firmware Review

Transcription

1 itop System Overview Kurtis Nishimura University of Hawaii October 12, 2012 US Belle II Firmware Review

2 Detection of Internally Reflected Cherenkov Light Charged particles of same momentum but different mass (e.g., K and ¼ ) emit Cherenkov light at different angles. Momentum measured by curvature of the particle through tracking. Detect the emitted photons in 2+ dimensions (x,y,t) BaBar DIRC as a model: The larger the expansion region, the better the x-y image... A large volume (>1m) may be required for acceptable performance. 7/25/2012 2

3 (cm) Detection of Internally Reflected Cherenkov Light Charged particles of same momentum but different mass (e.g., K and ¼ ) emit Cherenkov light at different angles. Momentum measured by curvature of the particle through tracking. Detect the emitted photons in 2+ dimensions (x,y,t) BaBar DIRC as a model: The larger the expansion region, the better the x-y image... A large volume (>1m) may be required for acceptable performance. (cm) Left: Simulation w/ 2 m expansion volume, 2 GeV K/¼ 7/25/2012 3

4 Detection of Internally Reflected Cherenkov Light Charged particles of same momentum but different mass (e.g., K and ¼ ) emit Cherenkov light at different angles. Momentum measured by curvature of the particle through tracking. Detect the emitted photons in 2+ dimensions (x,y,t) BaBar DIRC as a model: The larger the expansion region, the better the x-y image... A large volume (>1m) may be required for acceptable performance. Left: Simulation w/ 2 m expansion volume, 2 GeV K/¼ 7/25/2012 4

5 Detection of Internally Reflected Cherenkov Light Charged particles of same momentum but different mass (e.g., K and ¼ ) emit Cherenkov light at different angles. Momentum measured by curvature of the particle through tracking. Detect the emitted photons in 2+ dimensions (x,y,t) BaBar DIRC as a model: y t The larger the expansion region, the better the x-y image... A large volume (>1m) may be required for acceptable performance. Left: Simulation w/ 2 m expansion volume, 2 GeV K/¼ 7/25/2012 5

6 (cm) (ns) 7/25/ Time-of-Propagation (TOP) Counter DIRC variant: work directly at bar end compact! e.g., NIM A, 494, (2002) 90 ±, 2GeV Red - Pion Blue - Kaon (Peaks offset by ~200 ps)

7 7/25/ The Belle II itop Detector 2x16 SL-10 MCP-PMTs Precision timing for single ¾ TTS ~ 31 ps *K. Inami, et al., NIM A 592 (2008) Timing measured with CFD-based electronics One of 16 itop modules L bar ~ 2600mm L expansion ~ 100 mm W bar ~ 45 cm

8 October 12, itop and Belle-II Trigger itop is expected to provide information on the event start time at the trigger level to help reduce data volume from out-of-time hits in vertex detector. All hits are coarsely digitized and processed in real-time to get an estimate of T 0. ¾ T0 (trigger) ~ 4 ns w/ test data from MC running on real hardware.

9 Elements of itop Electronics Waveform sampling ASICs (Hawaii) COPPER Based Readout (KEK) Waveform data SCROD-based board stack, ASICs + Spartan-6 FPGA (Hawaii) Timing/trigger distribution module (KEK) Trigger data DSP_FIN (Hawaii) Remote programming link (CAT-7) October 12, 2012 FTSW TRG_FIN (Hawaii) 9

10 Overview of Trigger Flow (Final System) 1. Channel level triggers digitized and time stamped at front end. COPPER Based Readout (KEK) 2. Channel level triggers digitized and time Waveform data stamped at front end. SCROD-based board stack, ASICs + Spartan-6 FPGA (Hawaii) Timing/trigger distribution module (KEK) Trigger data DSP_FIN 5. Estimated (Hawaii) event T0 information to global decision logic. Remote programming link (CAT-7) 3. Channel triggers TRG_FIN 4. (Hawaii) Trigger sorted, merged. algorithm applied. October 12,

11 Overview of Data Flow (Final System) 1. Raw data sampled at front end. 2. Channel level trigger bits used to manage ASIC analog memory. 5. Digitize upon trigger. 6. Raw data to backend. COPPER Based Readout (KEK) SCROD-based board stack, ASICs + Spartan-6 FPGA (Hawaii) Timing/trigger distribution module (KEK) Waveform data 7. DSP: Apply calibration constants. 8. DSP: Feature extraction. DSP_FIN (Hawaii) Trigger data 9. To Belle-II DAQ 4. L1 Trigger Distributed from FTSW Remote to front-end. programming link (CAT-7) TRG_FIN (Hawaii) October 12,

12 Some Key Electronics Requirements Deliverable electronics must: Fit in the very compact space. Maintain excellent timing resolution of the MCP-PMTs. Electronics contribution: ¾ t < 100 ps [minimum acceptable] ¾ t < 50 ps [target] Provide information on all photons to Belle II trigger system to obtain estimate of T0 (used for data reduction in vertex). ¾ T0 < 20 ns [minimum acceptable] ¾ T0 < 10 ns [target] Accommodate Belle-II trigger conditions: ~5 ¹s Belle II trigger latency. 30 khz Level-1 trigger rate. No dead time at: 1% occupancy [minimum acceptable] 2.5% occupancy [target] Relevant for: ASIC sampling control ASIC feedback loops DSP feature extraction Front-end trigger time digitization Back-end trigger algorithms ASIC sampling control & channel level trigger interface ASIC digitization ASIC readout 7/25/

13 October 12, Overview of Firmware (Final System)

14 October 12, Previous and Future Testing A number of beam tests have been conducted: CERN beam tests with CFD-based electronics. Fermilab beam test with preliminary waveform sampling readout. Spring-8/LEPS beam tests with CFD-based electronics. To pass CD3a, itop performance must be adequately demonstrated with a beam test during the coming year. Cosmic ray tests at KEK Fuji Hall. Beam test with final configuration and waveform sampling readout (facility TBD). We should identify what requirements are strictly necessary for these short term tests. Ideally avoiding development that will be thrown-away for the final system.

15 Overview of Data Flow (Short Term Goal) 1. Raw data sampled at front end. 2. Channel level trigger bits used to manage ASIC analog memory. 5. Digitize upon trigger (use trigger bits for zero suppression only). SCROD-based board stack, ASICs + Spartan-6 FPGA (Hawaii) 4. L1 Trigger Distributed from FTSW Remote to front-end. programming link (CAT-7) Timing/trigger distribution module (KEK) 6. Raw data to backend. Waveform data Trigger data COPPER Based Readout (KEK) 7. Apply calibration (if ready). 8. Feature extraction (if ready). Pass features + waveforms. DSP_FIN (Hawaii) 8. To Belle-II DAQ To test DAQ 9. Offline or software based cal. + feature extraction. Note: Trigger level data flow most likely not necessary for short TRG_FIN term. (Hawaii) October 12,

16 October 12, Notes on Previous Testing Previous tests used IRS2 ASIC. IRS3B is proposed for next round. Firmware should change accordingly. The rest of the board stack is ~ the same. COPPER Based Readout (KEK) Waveform data SCROD-based board stack, ASICs + Spartan-6 FPGA (Hawaii) Previous tests used cpci based back-end (DSPs were not included in processing loop). Swapping to COPPER based DAQ system for coming tests. DSP_FIN (Hawaii) DSP_cPCI (alternate to COPPER-based readout)

17 October 12, An Aside on Tracking itop requires tracking to properly evaluate performance. Next beam and cosmic tests need relatively precise tracking. Options include: Scintillating fiber tracker, based on KLM readout. Under development by Hawaii. For short term, this must work with the TARGET4 ASIC. Scintillating fiber tracker, based on conventional ADC/TDC readout. Currently under development by Nagoya group. Gary will discuss the scintillating fiber KLM systems more in the next talk. Use of KLM option couples the schedule of the two systems for short term. Figure from Matt Barrett s simulation studies. Final geometry still TBD.

18 October 12, Goals for Today 1. Review final system structure/requirements, existing firmware and associated data acquisition. 2. Determine specifications for short-term system (cosmic + beam tests). Associated benchmarks/milestones for specifications. Partitioning of labor. 3. Documentation plan: What is required for new or existing members? What is expected from each contributor by end of item Long term development plans and needs. Short-term development should, whenever possible, be flexible enough for use in final system.

19 Backup October 12,

20 October 12, Front-back Front-front itop Hardware Naming Conventions HV board ASIC daughter cards Carrier levels Interconnect Board SCROD