2. Pixel DAQ status G. Chiodini, S. Magni, D. Menasce, L. Uplegger, D. Zhang

3. July 17th, 2002DAQ status and propsects2 Talk layout What has been accomplished so far Choices we made What we have learned during this phase of code development What’s needed for the next step Short range program Medium term program Long term program

4. July 17th, 2002DAQ status and propsects3 What has been accomplished so far At the last group meeting we stated that we were able to read- back pixel events with our DAQ system. The pixel (a preFPIX2Tb), though, was NOT initialized using our new DAQ (this functionality was not yet implemented at that time), but using instead a separate, stand-alone program. Good news is that we are now able to both initialize a preFPIX2Tb pixel AND read events out from our integrated DAQ. This is a significant step forward, since read-out only involves interaction between our DAQ software and the ALTERA FPGA firmware on the PTA card, while initialization involves additional interaction with the mezzanine card firmware (XYLINX FPGA).

5. July 17th, 2002DAQ status and propsects4 Problem: Bad news is that during these tests we accidentally burned the only preFPIX2Tb chip we had at our disposal. At this point we have a problem, since no other chip is currently available for testing, and code development is really hard to do when we are deprived of the possibility of concurrent testing.

6. July 17th, 2002DAQ status and propsects5 Possible way out There are several options on how to proceed: 1.Do nothing, wait for new chips to be made available (that’s obviously ridiculous…) 2. Move on to FPIX1 (we have a chip in Milano). In this case, though, we need the mezzanine firmware which is not yet available for this model (help needed from Brad). 3. Postpone further tests to September 1 st, when we will all be at FNAL working with Brad and Gabriele to complete the project, and in the meanwhile concentrate on auxiliary issues (a list of those will be discussed shortly…)

7. July 17th, 2002DAQ status and propsects6 Choices we made (I) Before discuss options to proceed, let’s see what choices have been made till now 1. We still use the JungoDriver software as the core driver for the PCI card (license issues) 2. We use the Qt library for the GUI of the DAQ and for related tasks (no license issues, C++ code, easy integration with the JungoDriver and the rest of the overall DAQ framework) 3.All initialization files are written as XML (ASCII + tags) files: we use xerces (for reasons specified next) as a validator and parser (no license issues, C++ code, easy integration with all the above other libraries).

8. July 17th, 2002DAQ status and propsects7 Choices we made (II) A few words about xerces and our motivation for it’s adoption An xml file is just one possible instance among several possible initialization files: the constant of motion, in this case, is a dictionary to express what fields (tags) an xml file can or cannot contain, what each field is meant to represent, what is the relationship among components and so-forth … we need a uniquely defined syntax to represent an xml file a DTD (Data Translation Dictionary) is a file that formally defines a syntax for an xml file. Our initialization files are defined by means of a DTD file that closely mimics the hardware it is supposed to represent.

9. July 17th, 2002DAQ status and propsects8 Choices we made (III) The syntax of a dtd-file is specified by the XML protocol (available at http://www.w3.org/TR/REC-xml).http://www.w3.org/TR/REC-xml Let’s see in the following example how we decided to implement the syntax of our xml initialization file: the idea is that tags in the xml file should have an almost direct correspondence with hardware components in the system.

10. July 17th, 2002DAQ status and propsects9 A slot in a branch Branch bus # 1 slot # 1 Mezzanine Mezzanine PTA Clock … Chip ID=“B” Kill mask Inject mask V i (bp) V iff … Control voltages Chip ID=“A” Kill mask Inject mask V i (bp) V iff … Control voltages Clock Memory limit Pre Fetch … FPGA

11. July 17th, 2002DAQ status and propsects10 The overall hardware 1 2 3 Pulser (GPIB device) Pulser (GPIB device) High/Low Voltage CAEN Power Supply (TCP-IP device) High/Low Voltage CAEN Power Supply (TCP-IP device) Initialization File (XML) Initialization File (XML)

12. July 17th, 2002DAQ status and propsects11 Choices we made (III) …………………………………… …………………………………… Pulse Generator Pulse Generator Power Supply Power Supply

13. July 17th, 2002DAQ status and propsects12 The DTD-XML relationship <!ELEMENT DAQ ( DaqHome, LogFile, DaqMode, FakeData*, Branch+ ) > DAQcfg.xml DAQcfg.dtd Optional field More than one instance allowed (but at least one)

14. July 17th, 2002DAQ status and propsects13 The parser/validator (I) Once a DTD has been defined and a possible instance of an XML file (based on the chosen DTD) has been implemented, we already have two important benefits: People working on the GUI to manage the xml file communicate with people using the xml in the DAQ part just by means of the DTD definition. Should a new field be required, with specific fields and sub-fields, all is needed in order to share this info among the parties involved in the code development is just the DTD file itself, which uniquely defines what is and what is not allowed to be present in an xml file based on that particular grammar. - Code development is made easier - The DTD already represents the full documentation needed

15. July 17th, 2002DAQ status and propsects14 The parser/validator (II) The order in which fields are declared in the xml file is irrelevant: the parser automatically transfers fields and associated values in memory. This makes easy to add/remove elements in the configuration file without modifying the code. The parser/validator we decided to use is xerces, available at http://xml.apache.org/xerces-c (as usual, it is public domainhttp://xml.apache.org/xerces-c software, which easily integrates with Qt and JungoDriver). The Qt library also provides a parser, but the current version has no validation features, so we decided to use xerces More important, errors in the xml file are detected by the parser/validator with no need to stuff the code with consistency checks (the developer of the code is relieved from the tedious task of providing consistency check all along).

16. July 17th, 2002DAQ status and propsects15 The xml GUI An xml initialization file is usually rather long and has a complex inner structure. A user should NOT need to be aware of any syntax detail, so we are providing a GUI interface (this is work of Dehong Zhang). This is still work in progress, but a rudimentary example already works and can be used.

17. July 17th, 2002DAQ status and propsects16 The xml GUI

18. July 17th, 2002DAQ status and propsects17 The xml GUI

19. July 17th, 2002DAQ status and propsects18 The xml GUI

20. July 17th, 2002DAQ status and propsects19 The xml GUI

21. July 17th, 2002DAQ status and propsects20 What we learned Xml files are easy to define, to parse and to validate. Though not strictly necessary, the validation feature has proven to be really useful, particularly so for large initialization files. Validation is useful during the design phase of the code (when changes are still frequent) and in those cases when a user needs to modify an xml file with a plain text editor. Xerces integrates smoothly with both Qt and JungoDriver. - The learning curve, though, is steep. - To produce good quality software needs a lot of time and practice, that’s why we are taking advantage of this test beam to learn these tools. Still, the prime directive is very clear Take data

22. July 17th, 2002DAQ status and propsects21 What’s needed for the next step In order to make new progress, we need a number of hardware components which at present are not available: 1. At least two preFPIX2 chips (three would be better, since an important component of the DAQ to test on real data is the event builder, only tested for now with fake injected patterns) 2. At least two FPIX1 chips (same reason as above). In this case though the mezzanine firmware still is not available Still missing is the component that writes events to disk: we need to define the data-structure of those output files. Once this is done we think that providing this functionality should be rather easy. We’ll have a meeting next week about this subject.

23. July 17th, 2002DAQ status and propsects22 Short range program Since none of these components is likely to become available before August, we are currently concentrating on the development of auxiliary components needed to manage the pixel setup. One of these components is a set of interfaces to the GPIB devices such as the power supply and the pulse generator. The important part is not the GUI itself, but the core code that handles communication with a GPIB interface: to this extent we developed an abstract interface to GPIB devices and implemented an instance for the Tektronix PS2521S Power Supply unit (we have one at Feynman and another identical one in Milano). The GUI is important when we want to address the one in Fermilab from Milano.

24. July 17th, 2002DAQ status and propsects23 Short range program

25. July 17th, 2002DAQ status and propsects24 Short range program

26. July 17th, 2002DAQ status and propsects25 Short range program

27. July 17th, 2002DAQ status and propsects26 Short range program

28. July 17th, 2002DAQ status and propsects27 Short range program

29. July 17th, 2002DAQ status and propsects28 Medium range program We will all be at Fermilab September 1 st to work with Gabriele, Brad and Dehong on the final commissioning of the hardware/ software needed to reach the bare-bone requirement of being able to record real built events to disk. We plan to spend three weeks to setup things in order to be able after that to continue useful work from Milano. For this plan to be fruitful, we need to have available the pixel devices mentioned before for testing

30. July 17th, 2002DAQ status and propsects29 Long range program Once the minimum goal of reading out event to disk has been completely and satisfactorily been reached (hopefully by the end of September), we can concentrate on new issues: - Complete the GUI to handle the data-taking process - provide appropriate documentation - think about good strategies to handle the (presumably) large number of initialization conditions that will be generated We have some ideas about that, but we still need to have discussion with all the other people involved. - Re-implement the calibration code in the new DAQ framework context (this is old Gabriele’s code). We have already started work to this regard.