PHENIX Upgrades Electronics Oversight

1. PHENIX Upgrades Electronics Oversight John Haggerty Brookhaven National Laboratory John Haggerty

2. What is this about? • The scope of upgrade electronics projects is actually quite large by any measure (dollars, number of channels, number of designs, number of new ideas that must be worked out) • The upgrades are likely to be different enough from PHENIX I that it looks like it needs coordination to answer questions both from the subsystems and from management • This set of ideas is a response to that, but is probably not the final resolution, but a set of ideas that we are looking to implement starting in the next few months • There are still unanswered questions, like, “How do we do this while we’re trying to start up new runs?” and many others John Haggerty

3. Upgrade Electronics By some measures, there is almost as much new electronics in the PHENIX upgrades as there was in PHENIX: • HBD • TOF.W RPC’s • Silicon • SVX4-based strips • Pixel • Forward muon trigger • Muon RPC’s • Nosecone Calorimeter • DCM II John Haggerty

4. PHENIX Upgrade Detectors in Inner Region (from Ed O’Brien) barrel VTX |h| < 1.2 NCC 0.9 < h < 3.0 Provides displaced vertex & jet measurement over 2p VTX: silicon vertex tracker (Barrel and EndCap) NCC: nose cone calorimeter HBD: hadron blind detector endcap VTX 1.2 < h < 2.7 HBD VTX NCC MuonTrig MuonTrig John Haggerty

5. EF&I Evolves into Detector Electronics Group There are a variety of tasks for an internal PHENIX group that stays on top of electronic development meant to go into PHENIX: • All the electronics has infrastructure needs which have historically been provided by EF&I: LV, HV, cables, fibers, safety systems • We have also provided a variety of common electronics—GTM’s, glink daughterboards, ARCNET boards and software, glink fanouts, LED drivers, and so on • In addition, we have run internal reviews and stayed on top of design nuances by meeting with the designers so they don’t take us by surprise when they get delivered here • In some cases, money has to be moved around which requires some judgments, and we have sometimes done things like procure components at BNL • We can help prepare for the inevitable external reviews, including safety reviews • We can offer valuable advice at no charge John Haggerty

6. Methods • The only way I know to track this kind of distributed project is to travel around and meet with the principal designers (engineers and physicists) and have them explain what they’re doing and how it’s going; I think it works best to meet in person at the institution where the development is taking place • For a project well under way, every month is about right, and written minutes to PHENIX project management is useful as a way to track progress • More formal Design Reviews are a good idea, in which the designers have to present their design, explain it, defend it, and listen to suggestions, although by the time of what we called the Final Design Review (production readiness), it was too late to change anything of substance • Less formal “chain tests” were essential to educate the DAQ group in using the electronics, developing readout software, and making sure that the device actually works • Workshops which bring together designers from different systems would benefit all systems John Haggerty

7. Who? • We should be able to draw on a larger group for the periodic meetings than we had before (Chi, Glenn, and me) • On the other hand, we don’t want such distributed responsibility that nobody feels any accountability • Each major electronics upgrade project needs a lead engineer and a lead physicist who ask and answer technical questions about the system and has a reasonably clear idea of how it fits into PHENIX • Each may need a manager, too, to track cost and schedule • We can draw upon the expertise locally at BNL (Steve Boose, Paul Giannotti, Instrumentation Division, Andre Sukhanov) and outside (Chi, John Lajoie, and others) for this group John Haggerty

8. Common Electronics • Control and configuration by Ethernet • Fiber and transceiver standards • A new/modified GTM? • Power supplies and grounding • A single architecture for monitoring and control (Ethernet?) John Haggerty

9. Ethernet in PHENIX Upgrades • For the next generation of PHENIX FEM’s, Steve Boose has been working on selecting an Ethernet based controller; same basic features as GAB, but additional capabilities possible, like an additional slow path for reading data • Desirable features: • Small footprint, low profile (to fit in VME slot spacing 0.7 in) • Enough CPU and memory to handle ethernet traffic and control • Comfortable development environment • “Open” design so that schematics can be dropped into designs • Some disadvantages: • Fatter cable; connectors probably have to be bigger RJ45 • More software complexity • Point-to-point wiring and hubs necessary • Current best idea is Freescale’s Motorola Coldfire 5282 board • Schematic freely published; free binary monitor (RTXC) • Linux inside: http://www.uclinux.org/ports/coldfire/ • About $300 CML-5282 Motorola Coldfire development board (3.5”x4”) (www.axman.com) John Haggerty

10. Workshop? • One thing that didn’t work o well the first time around was how some things had to be explained repeatedly (i.e., the DCM protocol) • Maybe a workshop which gets all the lead engineers and physicists together to present to each other their plans would be useful • Nevis? Early 2006? John Haggerty

11. Next Steps • Still a work in progress • Start by organizing meetings and talking to people • Regular reporting to DC and Ed John Haggerty