1 / 15

DCH Electronics Upgrade: Overview and Status

DCH Electronics Upgrade: Overview and Status. Christopher O’Grady For the DCH Electronics Upgrade Group. The DCH Deadtime Problem. DAQ system behaves like a set of parallel assembly lines; runs as fast as the slowest “worker”. Worker speed depends (to first order) only on event size.

alanna
Download Presentation

DCH Electronics Upgrade: Overview and Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DCH Electronics Upgrade: Overview and Status Christopher O’Grady For the DCH Electronics Upgrade Group

  2. The DCH Deadtime Problem • DAQ system behaves like a set of parallel assembly lines; runs as fast as the slowest “worker”. • Worker speed depends (to first order) only on event size. • Trigger rate sets speed requirement. • Using VMON software from Perazzo and Swain projected event sizes: in 2001 predicted a future DCH readout bottleneck. • Bottleneck observed in 2003/2004.

  3. Projected Readout Times • Latest round done by Matt. NOW 2004 2005 Luminosity Component 2006 2007 Noise Component 140us LER Component HER Component Svt Ifr Trg Drc Dch Emc

  4. Upgrade DCH Readout? • Trigger requires 7kHz (x2 background) in 2007: 140us. Historically, some projections have been pessimistic, some optimistic, but not wildly off. • If we don’t improve DCH bottleneck, no point in doing any other DAQ upgrades. Significant improvement possible (thanks to original system designers). Pressure to compete with KEK. • Experience: Dataflow has track record of successfully modifying firmware and understanding/fixing subtle electronics problems (SVT,DCH,EMC,EMT,FCTS). Matt also designed/built his own board (FCGG) from scratch. Significant experience added with Herbst. • Babar management made decision to attack the problem on many fronts (e.g. backgrounds, DAQ deadtime, trigger rates). • But this is the most “serious” work so far: deep inside detector. Must work perfectly. Forever. I think we can do it.

  5. Existing Readout System

  6. Data Transfer Rates

  7. Improving Throughput • Two options to improve readout speed: • Scale existing system to increase data transfer rates, and/or • Reduce size of data • (1) was original idea, but successfully argued against by Nelson/Haller • Two ideas for (2) were conceived in Jan. 2004. Both are being implemented.

  8. Phase I • Change ROIB “slave” readout firmware to send up half the DCH waveform: for a pair keep TDC hit (if present) or second half of pair of ADCs. • Factor of 2 improvement.

  9. Phase I (part b) • To first order, affects only dE/dx, not tracking. • Re-ran physics analysis with/without this: no significant degradation observed. • Needed to increase elefant readout rate to 15MHz from 7.5MHz to avoid FIFO underrun. Many subtle issues. Necessary for Phase II. • Installed in August, tested with hundreds of millions of bit-pattern events (and many other tests) • “Serious tracking” a couple of days from now

  10. Phase II • Move Feature Extraction algorithm (FEX) from ROM to larger FPGA at front-end • Keep all I/Os the same. Need new ROIB and ROM software. • All firmware the same except FEX firmware • Much easier because of elegant FEX algorithm from J.J. Russell.

  11. Requirements/Deliverables I • New ROIBs: FEA1, FEA2, FEA3, 16 each, + 20% spares. (Ryan’s talk) • FEX Firmware, able to transfer data to ROM in <140us, on average, in 2007. (Matt’s talk) • Master/Slave/Trigger Xilinx firmware rewritten in VHDL (currently “structurally”). (Matt’s talk, work from Jinlong, Pradeep and Chris) • Validation for all firmware (Matt’s talk) • Good VHDL support for mixing/matching 2 compatibility modes, FEA1-3, FEX (Matt’s talk) • New ROM Software (Matt’s talk)

  12. Requirements/Deliverables II • Two software and jumper selectable PROMs on front-end. One “fixed”, the other supports new “FEX” firmware download from ROM (Ryan’s talk, Pradeep’s work). • Fixed PROM to contain “compatibility” mode firmware (32 byte samples). Allows board to look like old ROIBs for old teststands and for calibrations. (Ryan’s talk) • No significant noise degradation (Ryan’s talk) • T0 value same as old board to <2ns. • No change in power/cooling loads (Ryan’s talk).

  13. Requirements/Deliverables III • Testing procedure to validate new production (Chris’ talk) • Data quality not compromised by radiation (Chris’ talk) • Documentation and archive • Firmware maintainable over the years (difficult)

  14. Status • First FEA2 was received in first week of Nov. • Two weeks after receiving it we were able to run hundreds of millions of bit pattern events and DCH calibrations (compatibility mode) both on the teststand and on the detector!!! This is impressive, in my biased opinion. • Major missing piece is firmware download support: in simulation, highest priority after review.

  15. Plan • Over next week or so, hopefully get download to work. • Pack I/O flops into IOBs. • Test, measure, get more “faith” in the board. • Wanted to install board in compatibility mode at “Christmas”, but have to wait because of safety issues. Be opportunistic. • Work on ROM software, and FEX support (new opcodes: constants download, firmware download) • Full installation in summer 2005. • Neutron radiation is significant concern. • We can’t mess this up. Healthy paranoia required.

More Related