1. 2 October 2003Paul Dauncey1 Paris Summary Part 2 and Status of UK Electronics/DAQ Paul Dauncey Imperial College London, UK

2. 2 October 2003Paul Dauncey2 Rest of talks at Paris: Very Front End (VFE) electronics Christophe de la Taille, Julien Fleury UK electronics/DAQ Adam Baird, Paul Dauncey Simulation studies Nigel Watson Organisation Jean Claude Brient, Sandrine Le Quellec Will summarise these in (apparently) random order Except simulation work was all from UK so is covered in some detail later today Paris Meeting Part 2

3. 2 October 2003Paul Dauncey3 Medium term aim for ECAL is beam test at DESY This is currently assumed to be around Aug 2004 Requires mechanical construction of ECAL to start in Mar 2004 Competition! SLAC/Oregon are now proposing full Si-W ECAL prototype also; their timescale is end 2005 Longer term aim for ECAL+HCAL(s) is beam test at FNAL Less certain timescale; could be end of 2004 but could easily slip into 2005 Will need to write proposal for beam time (discussion at end of day) Will also help “lock-in” US DHCAL collaborators Documentation Want central repository of “all” documentation (not clear exactly what) Have set up an EDMS (CERN) database at Ecole Polytechnique Web accessible interface but not email list handler Somewhat overly complicated for our needs? Organisation

4. 2 October 2003Paul Dauncey4 Very Front End (VFE) electronics is what the UK connects to VFE PCB physically holds the silicon wafers and VFE readout electronics Main component of VFE readout electronics is the VFE ASIC, FLCPHY2 Three flavours of VFE board, with either 216 or 108 channels, 12 or 6 chips VFE overview

5. 2 October 2003Paul Dauncey5 FLCPHY2 is second iteration of design Small fabrication run completed in Jul 2003 Testing now ~complete VFE chip status (de la Taille)

6. 2 October 2003Paul Dauncey6 Chip performs to requirements Pedestals; rms 5mV (in 1.4V) Peaking time; rms 1ns (on 180ns) Crosstalk; <1% Will go to full production ~now Need ~600 chips Back end Dec, test in Jan VFE chip performance

7. 2 October 2003Paul Dauncey7 Prototype PCB was half-size Scaling up to full number of channels Several changes to UK interface; still in flux VFE board status (Fleury) Trying to freeze final design ~now Big jump from prototype, so doing production in two steps Will produce two pre-production PCBs by end Oct 2003 Ideally test these and then make the other ~60 needed during Dec 2003 But must test with UK prototype before this; delay by ~one month VFE PCB is part of ECAL mechanical structure; UK delaying assembly!

8. 2 October 2003Paul Dauncey8 Need to produce six readout boards for whole ECAL 1728 channels maximum per board, 9720 channels total All other items needed for readout commercially available Crate, PC, VME interface, cables Board architecture Eight Front Ends (FE), each controlling one or two VFE PCBs Single Back End (BE) does data fan in/out to FEs Based on CMS FED board Overview of UK electronics

9. 2 October 2003Paul Dauncey9 CMS FED board (Rob Halsall, RAL)

10. 2 October 2003Paul Dauncey10 Design and layout “close” to completion Six months later than scheduled Unfortunately, these became too closely coupled Aiming to send for fabrication within two weeks CALICE board layout (Adam Baird, RAL)

11. 2 October 2003Paul Dauncey11 Main change from CMS is FE area Higher component count in CALICE so denser layout CALICE board FE layout

12. 2 October 2003Paul Dauncey12 Also need to write firmware (code to load into FPGAs) VME interface identical to CMS; (we hope) no work needed BE close but not identical so some work needed (Dave Mercer, Manc). Will also contain VME trigger interface, not existing in CMS (Matt Warren, UCL) FE completely different; effectively a new design (Osman Zorba, IC) Progress being made in these areas using simulation But real prototype CALICE board will speed things up Readout board firmware E.g. FE trigger delay simulation Allows adjustment in 3ns steps so trigger arrives at time of VFE chip peak

13. 2 October 2003Paul Dauncey13 Multi-PC system driven by common run control PC Each PC is independent; can have separate technology (VME, PCI, CAMAC, etc) PC configuration can be changed easily; single VME crate readout for separate system tests possible. Multiple tasks could be run on one PC; e.g. run control, ECAL and event build Prefer PCs outside radiation area if possible Have own hub and network (cost?) or rely on network infrastructure at beam line? DAQ software overview

14. 2 October 2003Paul Dauncey14 For tests, assume worst case; each subsystem (ECAL, HCAL, beam monitoring and slow controls) read out with separate PC Require one socket-socket branch for each DAQ topology Each branch can read out separate technology (VME, PCI, etc) Monitor does not necessarily sample all events; its buffer allows through events only when spare CPU available

15. 2 October 2003Paul Dauncey15 First version of data structure software exists Records and subrecords; loading/unloading, etc. Arbitrary payload (templated) for subrecords First version of data transport software exists Buffers, copiers, mergers, demergers, etc. Arbitrary payload (templated) with specialisation for records First version of run control software exists Both automatic (pre-defined) and manual run structures VME hardware access working SBS 620 VME-PCI interface board installed in borrowed VME crate Using Hardware Access Library (CERN/CMS) These work together Sustained rates achieved depend critically on PCs, network between the PCs on the different branches, compiler optimisation, inlining, etc; a lot of tuning needed DAQ status

16. 2 October 2003Paul Dauncey16 MIDAS (PSI) No experience of using this in UK Written for ~MByte data rates, ~100 Hz event rates, single PC systems Limited state diagram; no ability to take different types of events in run A lot of baggage (databases, slow controls); more complex than required C, not C++, so less natural interface downstream (and not type-safe) XDAQ (CERN/CMS) Significant experience of this in Imperial; useful to have experts on hand Optimised for CMS; no beam spill structure and asynchronous trigger and readout but easily deals with CALICE event rates and data sizes Includes HAL automatically so (should be) simple to retrofit later Deserves further investigation If moving to an existing system, XDAQ seems more suitable (?) Beware of “3am crash” issue; it is hard to debug code written by other people in a hurry… DAQ alternatives: MIDAS? XDAQ?

17. 2 October 2003Paul Dauncey17 Electronics schedule JFMAMJJASONDJFMAMJJA Prototype 2 boards Design Layout Fabrication and assembly Testing VFE PCB tests Production 9 boards Redesign Layout Fabrication and assembly Testing, including Paris system cosmic tests DESY beam test 2003 2004

18. 2 October 2003Paul Dauncey18 Board cost estimates (£k) OriginalCurrent PrototypeNRE2.53.0 (2 boards)Components8.07.8 Fabrication1.01.5 Assembly5.06.0 ProductionNRE2.53.0 (9 boards)Components35.035.1 Fabrication4.56.5 Assembly13.522.5 Total72.085.4 N.B. fab/ass cost not final until board design and layout complete

19. 2 October 2003Paul Dauncey19 Electronic boards were the major item but not total budget Miscellaneous other electronics; £2k Custom cables (100 needed); £15k PC, disk, VME interface, VME crate; £4k, £8k, £4k, £6k Major saving in cables VFE PCB will use same connector as readout board; don’t need custom Number of VFE PCBs (and hence cables) reduced from doubling PCB size Off-the-shelf cables (70 needed); £6k Minor savings elsewhere VME interface, VME crate; £3k, £5k Within a few £k of budget Under-using travel so could transfer from there if necessary Possible savings from rest of budget

20. 2 October 2003Paul Dauncey20 There is progress in CALICE as a whole Mechanics and electronics converging early next year Aiming for DESY beam test in Aug 2004 UK electronics going slowly Six months behind schedule Now critical path for ECAL as a whole Also cost estimated to be going over budget Not gone critical (yet…) After VFE test in Jan 2004, will disconnect from mechanical ECAL assembly, giving a little breathing space Next date to aim for is system test in Jul 2004 Cost overrun can probably be gained back from other sources Summary