Pixel DAQ status

1
Pixel DAQ status

• G. Chiodini, S. Magni, D. Menasce,
• L. Uplegger, D. Zhang

2
Talk layout

• What has been accomplished so far
• Choices we made
• What we have learned during this phase of code
  development
• Whats needed for the next step
• Short range program
• Medium term program
• Long term program

3
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).

4
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.

5
Possible way out

• There are several options on how to proceed

• Do nothing, wait for new chips to be made
  available
• (thats 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 1st ,
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)
6
Choices we made (I)

• Before discuss options to proceed, lets 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)

• 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).

7
Choices we made (II)
A few words about xerces and our motivation for
its 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.
8
Choices we made (III)
The syntax of a dtd-file is specified by the XML
protocol (available at http//www.w3.org/TR/REC-x
ml).
Lets 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.
9
A slot in a branch
Chip IDA
PTA
Mezzanine
Clock Memory limit Pre Fetch
Clock
10
The overall hardware
1
Initialization File (XML)
Pulser (GPIB device)
High/Low Voltage CAEN Power Supply (TCP-IP device)
11
Choices we made (III)
ltDAQConfigurationsgt ltGPIB
Version0.0.1 CommentPulseGeneratorgt
lt/GPIBgt ltCAEN Version0.0.1
CommentPowerSupplygt lt/CAENgt lt/DAQConfigurati
onsgt
ltDAQgt ltBranch Bus1 Sloti Status1
Commentgt lt/Branchgt
ltBranch Bus2 Slotj Status1 Commentgt
lt/Branchgt lt/DAQgt
12
The DTD-XML relationship
lt!ELEMENT DAQConfigurations (DAQ, GPIB, CAEN)
gt lt!ELEMENT DAQ ( DaqHome,
LogFile, DaqMode,
FakeData, Branch ) gt

DAQcfg.dtd
DAQcfg.xml
lt!DOCTYPE DAQConfigurations SYSTEM
DAQcfg.dtdgt ltDAQConfigurationsgt ltDAQ
Version0.0.1 Commentgt
ltDaqHome Value
Comment /gt ltLogFile Value Comment
/gt ltDaqMode Value Comment /gt
ltFakeData Interspill10 /gt ltBranch Bus
Slotgt lt/Branchgt ltBranch Bus
Slotgt lt/Branchgt lt/DAQgt lt/DAQConfigurations
gt
13
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

14
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.

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).
The parser/validator we decided to use is xerces,
available at http//xml.apache.org/xerces-c (as
usual, it is public domain 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
15
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.

16
The xml GUI
17
The xml GUI
18
The xml GUI
19
The xml GUI
20
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, thats why we are taking
  advantage of this test beam
• to learn these tools. Still, the prime
  directive is very clear
• Take data

21
Whats 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. Well have a meeting next week
  about this subject.

22
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.

23
Short range program
24
Short range program
25
Short range program
26
Short range program
27
Short range program
28
Medium range program

• We will all be at Fermilab September 1st 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

29
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
Gabrieles code). We have already started
work to this regard.