1 / 10

Common DAQ Design options and CPU-based sparsification D. Haas

Common DAQ Design options and CPU-based sparsification D. Haas. Outline Inputs from Strasbourg/Bonn Communication Critical points to solve State Machines/Interconnections Event processing Conclusions. Common DAQ - Inputs. Existing system from Strasbourg:

geoff
Download Presentation

Common DAQ Design options and CPU-based sparsification D. Haas

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. Common DAQ Design optionsand CPU-based sparsification D. Haas Outline Inputs from Strasbourg/Bonn Communication Critical points to solve State Machines/Interconnections Event processing Conclusions

  2. Common DAQ - Inputs • Existing system from Strasbourg: • Single PC, WinXP, Borland C++ • simple writing of acquired data on disk • Existing system from Bonn/Mannheim: • Single PC, WinXP, Borland C++ • more flexible producer/writer system • Both lack communication interface to other PCs D. Haas, JRA-1 Review, 4. April 2006, Page 2

  3. Adding communication  • Use existing solutions in HEP community and adapt DAQ accordingly • XDAQ with SOAP, I2O are good candidatesBUT: XDAQ is *nix only (Linux, BSD, Mac OS) • SOAP, I2O can communicate between different platforms • SOAP is XML based, slow (Commands) • I2O fast, binary format system (Data) • Build custom solution based on simple TCP/IP socket communication D. Haas, JRA-1 Review, 4. April 2006, Page 3

  4. Adding communication  • Use maximum of existing DAQ and add only necessary communication layer and ‘central’ control • Looks feasible for the Bonn system (but needs to be checked) • Or: Use minimum of existing DAQ (HW-level, readout, eventually event-format) and add own system around • seems more realistic for Strasbourg system D. Haas, JRA-1 Review, 4. April 2006, Page 4

  5. Present Bonn DEPFET DAQ Hardware Hardware Hardware telescope ‘producer’ task DEPFET ‘producer’ task other ‘producer’ tasks DAQ buffers Writer task file Monitoring buffers Monitoring task 1 Monitoring task 2 D. Haas, JRA-1 Review, 4. April 2006, Page 5

  6. Proposed Bonn Future DAQ DUT DAQ PC - WIN (beam area, via VNC) main PC - WINDOWS (counting room) USB DUT1 hardware Producer TCP Mon 1 PCI DUT2 hardware Producer writer MON PC - LINUX (remote) telescope DAQ PC - LIN (beam area, via VNC) VME telescope hardware Producer Mon 2 TCP TCP CAMAC TDC hardware Producer     D. Haas, JRA-1 Review, 4. April 2006, Page 6

  7. Critical points to solve • Communication via TCP/IP: • Add separate Controller TasksMessaging via SOAPData transfer via I2O • Main PC • Implement Global Controller Task (Run Control) • Monitoring • Use rootd for Monitoring (OS independent) • Write separate monitoring buffers/files D. Haas, JRA-1 Review, 4. April 2006, Page 7

  8. State machines/Interconnections • Currently starting to define the state machines for controller processes • Interconnections will be similar to Bonn proposal D. Haas, JRA-1 Review, 4. April 2006, Page 8

  9. Event processing • Initially, CPU has to provide CDS and sparsification for Strasbourg board • Mixed Data Mode should be foreseen (raw data + sparsified data) for easy debugging and analysis • Sparsification should be done on chip later • CPU has to take care of clusterization and complete event building (tracking) D. Haas, JRA-1 Review, 4. April 2006, Page 9

  10. Conclusions • Code from Strasbourg and Bonn in our hands now • Analysis of the code and design of the framework will start after this review • Emlyn Corrin will join our group in July • Global run control should be OS-independent D. Haas, JRA-1 Review, 4. April 2006, Page 10

More Related