December 17, 2013 Tracking FADC

From GlueXWiki
Jump to: navigation, search

Meeting Time and Place

Tuesday December 17, 2013 at 1:30pm At Jefferson Lab, the meeting will be held in F326

Connections

To connect from the outside, please use ESNET

  1. ) ESNET: 8542553
  2. )To connect by telephone, dial:
  • You can look up toll-free number at http://www.readytalk.com/intl
  • US and Canada: (866)740-1260 (toll free)
  • International: (303)248-0285 (toll call)
  • enter access code followed by the # sign: 3421244#

Agenda

  1. Announcements
  2. FADC Status Update
  3. Data formats [[1]]
  4. Quality factor(s)

Minutes

Present: Curtis, Naomi (CMU), Cody, Ed Jastrzembski, Beni, Dave L (JLab).

  1. FADC Status Update
    1. Cody:
      • full crate tests have been finished with one crate, this involves filling the crate with fadcs and passing tokens using the SD and fast mode readout (A25 bus, not serial mode) to get raw data mode output from all cards using Bryan Moffit's libraries.
      • he took Ed's code for the fadc250 VME interface and combined it with Hai's fadc250 code for the BCAL readout, then stripped out the extra parts (reduced 16 channels to 6 for each FPGA) and changed the daisy-chain readout to make it suitable for the fadc125. This is working with raw-mode readout.
      • he is now working on the VME programming to enable the firmware to be downloaded onto the FPGAs via the backplane rather than having to use the JTAG cable to each flash one at a time.
      • he has made a clock divider down to 40MHz which can be used if necessary, not used so far.
    2. Naomi:
      • She has made a simple pedestal-subtracting threshold crossing finder with interpolation which synthesizes (compiles into a downloadable hardware description for the FPGA) and meets the timing constraint of clock period = 8ns. This is a start.
      • She also has code which upsamples ADC data and then performs a threshold crossing finder, this runs in simulation but only synthesizes if the timing constraints are removed. Still working on this. The code is registered and pipelined but maybe there is something else to improve. Ed said look at multi-cycle timing.
    3. Ed:
      • Hai was planning to rewrite the flash 250 firmware because having the time and integral parts separated was not optimal. The rewrite would enable us to use our preferred data format with time and integral in the same word. Until then we will have to use the flash 250 data formats and timing algorithm.
      • He expects Hai to start work in the spring and finish in the fall.
      • There is a restricted window readout mode which we could use to read out a number of samples surrounding a threshold-crossing.
      • The fa250 code finds (first) peak height, so if we would like that output (Naomi would) it is already calculated.
  2. Data formats
    • Drift chamber peak integration needs to start at variable time but end at a fixed time after the trigger.
    • Subtraction of pedestal at trigger time from the later data is dangerous because the tail from an earlier pulse might still be present at the trigger time.
    • Naomi looked at minimum CDC peak time, it is around ~5 samples, there were virtually no CDC signals of shorter duration, but the leading edge gradient is much more useful to distinguish hits from noise, LE gradient is ~ 30 adc units/sample for a hit and much less for noise, can look up better numbers if needed.
    • The fa250 has a threshold for sparsification but this works such that one channel over threshold prompts output from all channels.
    • Beni suggested running our timing algorithms in the ROC.
    • Beni mentioned that Lubomir might need to make an FFT of the upsampled pulse data to remove noise.
    • We need an estimate of cosmic data rates.
  3. Quality factor(s)
    • Discuss these at the next meeting with the aim of finalizing the data format document for Ed and Hai to use.
  4. Next meeting: Jan 14