New HCAL DCC Eric Hazen, S. X. Wu Boston University

Outline ● Current HTR/DCC status ● New DCC – Design Overview – New Features ● Higher bandwidth ● Selective Readout ● Remote diagnostics – Summary / Plans / Schedule – Manpower

Current HTR / DCC Status ● Hardware problems clearly identified in last review: – Long parallel traces on HTR channel link ● Fix:don't use the worst traces, remove from protocol – Insufficient bypass capacitors on both HTR FPGA and LRB ● Work-around:reduce I/O drive strength+slew rate, remove unnecessary core logic. This is a potential time bomb (IMHO) – “Loss-of-sync” (EvN mismatch) due to HTR+DCC firmware problems ● Mostly fixed. No LoS seen in Cruzet4 ● Other problems: – Errors in HTR FEE fiber receivers ● Maryland working hard on this -- getting much better

Current HTR / DCC Status – Zero-suppression logic problems ● Fixed ?! ?! – HTR malfunctions with L1A closer than 5 BX ● First seen last week in MWGR ● Used to work (in older HTR firmware)... not urgent to fix ● DCC Spares are critical – 10 Spare boards exist ● 5 shipped to CERN where a net (-1) spares existed ● After CASTOR, H2 etc there are only about 2 real spares ● 1 returned to Maryland for test stand (ongoing need) ● 2 have broken again after repair ● 2 in use in BU test stand

Few scattered BcN mis-match Persistent OrN mis-match in some runs (not this one!) Typically no link errors now (confirmed by MonLogger)

A few fibers still have front-end problems (Drew and Tullio are working on it!)

New DCC Improvements ● Many fewer parts; no back-side components ● Enough bypass capacitors !! ● Single-width VME module frees slots in crate ● Supports selective readout ala ECAL: makes better use of limited DAQ bandwidth ● Much simpler design – no complex internal protocols ● Inexpensive to produce – can build lots of spares ● Large and still-buggy PCI-based software support library no longer needed – a simple HAL table will do ● Remote diagnostics/status via Ethernet

New DCC Block Diagram Xilinx XC3S200 A FPGA RJ-45 HTR inputs (total 15) 32MByte DDR SDRAM Xilinx XC3SD1800A FPGA 64MByte DDR SDRAM TTCrx UMD board LVDS Tx TTS TT C Xilinx XC3S200 A FPGA VME Buffers VME64 x S-Link LSC DAQ Data TP Out Readout bits in Buffe rs Out In RJ-45 to/from Readout Processor 6U transition module at rear of crate

New DCC Block Diagram LVDS Deser. RJ-45 HTR inputs Event Builder 8 pairs+ clock TTS TT C VME64 x Input: 40MHz * 16 bits (peak) per link 100kHz * ~ 750 bytes per link maximum Max-size non-ZS data Buffer for 8000 max-size events Up to 480 MB/sec 8 S-Link Mbyte/sec (much more possible if FRL can handle it!) Out In TP sent to readout processor (few bits per tower per L1A) TP sends back bit-mask of channels to read Total BW needed ~ 30MB/s

New DCC Input Stage Front-end FPGA Xilinx XC3S200A RJ-45 HTR inputs 32MByte DDR SDRAM Event Builder FPGA Xilinx XC3SD1800A Trigger Primitives L1A, Calib Trig DAQ Data Control, Monitoring Input data buffered in SDRAM Write: 240 MBytes/sec Read: ~25 Mbytes/sec EvN correlated with L1A, re-sync if needed TP sent to event builder FPGA DAQ data sent to event builder To S-Link L1A sent to front-end FPGA Zero-suppression / selective readout algorithm selects channels to readout, sends readout mask back to front-end FPGA. If readout processor used, send TP to RP, receive readout mask, send to front-end DAQ data transferred from SDRAM buffer through FPGAs to S-Link Readout mask 32MByte DDR SDRAM Event builder temporary storage is for meta-data only (EvN, etc). Use BRAMs. SDRAM is for VME readout Selective Readout Processor

TTC TTS Etherne t HTR s (15) Partial PCB Layout VME6 4 TM Connecto r Input FPGA SDRAM (3 channels per input block) TTCr x Event Builder FPGA and SDRAM

Selective Readout ● Event size strictly limited to 2k bytes (at 100kHz) in current DCC by PCI bandwidth – Total of 60 (TP+TS) per HTR, or 2.5 per channel – If we send 1 non-suppressed TP, that leaves 1.5 – Choosing a workable combination of threshold and (TS,TP) given these constraints is challenging ● We can do a lot with more intelligent readout even without increasing average bandwidth or communicating with other subsystems ● For this to be useful, inter-board communication is a must

Selective Readout ● Possible Algorithms - with no ECAL input – Lower threshold around cluster at same depth – Lower threshold downstream (HO) of a cluster in HB ● Possible Algorithms - with ECAL input – Lepton and photon isolation – Other... some MC work is needed ● In addition... – We can run with higher occupancy on some regions (exceeding the 2k average) with a new DCC (trading for lower occupancy elsewhere to keep the DAQ folks happy)

  DCC Map in  /  HOHO HB/E HF Side +1Side -1

Selective Readout ● “Load levelling” amongst HTRs possible with no interconnections ● Hardware required for other algorithms – Bi-directional links between neighboring DCCs ● Each DCC would need to talk to 8 neighbors (plus depth!) – Or, send a single point-to-point link to a central processor from each DCC ● This is our preferred solution ● The “processor” would be quite simple (one main FPGA) and would receive a set of TP from each DCC, and return a readout map – Input from ECAL ● Need to discuss this further, but would clearly improve performance

Other New Features ● Fast response to HTR busy/overflow warnings – Avoid current situation where HTR empty events occur ● Long TTC/TTS state history with “trigger” features to capture problems ● Ethernet-based monitoring – Allow remote access for diagnostics independent of current state of DAQ software and computers – Read-only except in the lab!

New DCC Status -Hardware ● Draft schematic ready ● VME PCB Design in progress – Input section, VME largely complete – Event builder, TTC, Slink to be done ● Components donated by Xilinx for prototypes ● Backplane PCB – Very simple, just holds 3 or 4 press-fit connectors ● Transition module PCB – Conceptual design stage – Also very simple. Buffers for S-Link and RP connectors

Software ● As compatible as possible with existing DCC – Minimal changes to DCCManager – Existing cfgScript supported; only enhancements – Compatible monitoring (eventually will enhance) ● New DCC support class – No PCI initialization, simple flat HAL table – Fixed slot-based addressing like HTR – Much simplified initialize(), prepareforrun(), start(), stop() ● Arno and Phil (G.S.) will write most of it

New DCC ─ Proposed Plan ● Build prototypes ASAP (~1 month possible) ● Implement simple test firmware: – Receive and buffer raw HTR data – Validate Spartan-3A de-serializer ● Implement full DCC functionality, but with all unnecessary features eliminated ● Test in a few crates in UXC as time permits ● Production Readiness Review ● Full replacement during winter shutdown for 2009 runs – No longer realistic -- slipped to 2010 :(

Manpower - BU CMS Tasks ● Firmware maintenance of current DCC Wu – Not anticipated to be a big job, as things are working well now ● New DCC – Detailed Specification Eric – PCB Design Wu – Firmware Design Wu – Software Library Arno, Phil ● Calo Trigger Upgrade – uTCA DCC Design Hazen, Wu ● Plus support as needed from the BU team: – Jim Rohlf, Larry Sulak, Tulika Bose (+PD), Ulrich Heintz (+GS) Andrew Clough, Phil Lawson, Jason St John, Laza, Arjan, Arno