1. Who is UMA ? Peter Fischer, I. Peric, F. Giesen, V. Kreidl Lehrstuhl für Schaltungstechnik und Simulation Institut für Technische Informatik Universität Mannheim Presentation given at the EUDET / JRA-1 Brainstorming, 3.11.2005, DESY

2. Mannheim introductionPeter Fischer, Uni Mannheim, Page 2 UMA = University of Mannheim Mannheim University Faculty of Mathematics & computer science circuit design & simulation Institute for computer engineering (‘Technische Informatik’) … …… … … …

3. Mannheim introductionPeter Fischer, Uni Mannheim, Page 3 Institute competence  7 chairs (‘Lehrstühle’) = research groups  Some research interests: –Special purpose FPGA coprocessors –Trigger processors (R. Männer) –Virtual reality medical training systems –Reliable communication, DSL –High speed computer links for clusters –computer vision & image processing –Optoelectronics –Circuit design, Sensor readout  Student education: –Diploma ‘Technische Informatik’ –One main focus: hardware design with competence in FPGAs, analog circuit design, full custom layout, digital synthesis, automated design flows.

4. Mannheim introductionPeter Fischer, Uni Mannheim, Page 4 My group & research projects  Group has been started 3 years ago – myself coming from Bonn  Still small, growing ‘naturally’  Presently: 1 Postdoc (Ivan Peric), 3 PhD students, 2 - 5 diploma students  Projects: –DEPFET pixel detectors, mainly steering & readout chips –pixel chips for hybrid detectors –monolithic pixel sensors –high rate time measurement for PET –front end and time stamping for CBM –differential logic –transconductors with low gm –light weight, high speed serial links

5. Mannheim introductionPeter Fischer, Uni Mannheim, Page 5 Involvement in JRA-1  Validation of Infrastructure with a DEPFET matrix detector  Mannheim involvement is 24 PM (12 from EUDET)  This task is a common enterprise between Bonn / MPI / Mannheim  Sharing of the required work will be defined in the first project year.  Integration with telescope prototype start in second project year

6. Mannheim introductionPeter Fischer, Uni Mannheim, Page 6 Present DEPFET ‘Mini-DAQ’  PC based, Windows based. Very light weight and simple to add components.  Hardware interface to our telescope:PCI  Hardware Interface to the DEPFET:USB  Software is divided into many parallel tasks: –Producer tasks read the hardware –a Writer task bundles events, writes to file and sends subsets for monitoring –Online - Monitoring tasks display various information. They request a fraction of the data from the writer –A buffer monitor task and a main controller –‘Reader’ can re-inject data into Monitoring  Central data flow element: ‘shared buffers’ –Used between Producers and Writer and between Writer and Monitors –Events have unambiguous ID in the buffers for later sorting –Mutexes are used to control access of the buffers –Uses begin-of-run, data, end-of-run events.

7. Mannheim introductionPeter Fischer, Uni Mannheim, Page 7 Present DEPFET ‘Mini-DAQ’ Hardware file Writer telescope ‘producer’ task DEPFET ‘producer’ task other ‘producer’ tasks Monitoring 1 buffer

8. Mannheim introductionPeter Fischer, Uni Mannheim, Page 8 Advantages of our small DAQ  Pipelined operation  Small tasks keep units simple  Clearly defined interface at buffer ends  Extensions are simple  Can send buffers through TCP/IP (work in progress) to relief main DAQ computer  Several small monitoring tasks can run in parallel  Preprocessed data (tracks) can be included into the data flow and be used by monitoring tasks  Still needed: –Overall control task –Better control over detector configuration –Logfile –…

9. Mannheim introductionPeter Fischer, Uni Mannheim, Page 9 Some requirements for DAQ from the user side  Trigger hardware must guarantee same event ID’s in all detectors  Must be able to inject dummy triggers  Would be nice to get event time w.r. to main clock (TDC)  Integration of new devices or groups of devices must be simple  Access to all detector data (raw or preprocessed) for monitoring must be simple  System should not require very special hardware  Stand alone operation must be possible (in lab, for beam preparation)  Questions: –should both OSs (WIN, LINUX) be possible ? - nice GUIs are simpler in Windows, - multi tasking may be simpler in Linux –what hardware interfaces should be supported ? I would prefer serial links. Is the speed high enough ?