Difference between revisions of "FA125 Meeting May 13, 2016"

From GlueXWiki
Jump to: navigation, search
(Created page with "May 13, 2016 FA125 meeting = Connection = # [https://halldweb.jlab.org/wiki/index.php/Connect_to_Bluejeans_Meetings Instructions for Bluejeans meeting connection] # Meeting...")
 
(→‎DRAFT Minutes NOT FINISHED YET read at your own risk)
Line 22: Line 22:
  
 
#Objectives: David reminded us that the objectives for the runs in 2018 include a rate on the target of 5e7 photons/second and the DAQ running at 100kHz (a photon flux of 1e8 Hz was mentioned originally, but this was reduced to 5e7).  The DAQ livetime was not mentioned but is assumed to be 90%.  
 
#Objectives: David reminded us that the objectives for the runs in 2018 include a rate on the target of 5e7 photons/second and the DAQ running at 100kHz (a photon flux of 1e8 Hz was mentioned originally, but this was reduced to 5e7).  The DAQ livetime was not mentioned but is assumed to be 90%.  
−
#Current performance: Cody's tests show the FA125 running at sustained rates (continuously, so 0% livetime) with the current parameters of  
+
#Current performance: Cody's tests show the FA125 running at sustained rates (continuously, so 0% livetime) with the current parameters of window size = 200, integrating to the end of the window, 16 pedestal samples, search for 1 peak, for short mode, trigger in to data out:
−
Window size = 200, WE>200, NP/NP2=4, Npeaks=1
+
#*0% occupancy (no hits) = 4.9uS = ~204kHz
−
<pre>
+
#*17% occupancy (1 hit per chip) = 5.9uS = ~170kHz
−
Short mode processing time (trig to out)
+
#*100% occupancy (6 hits per chip, on all 12 chips) = 8.8uS = ~113kHz
−
 
+
#*Just algorithm = 4.68uS  
−
0% occupancy (no hits) = 4.9uS = ~204kHz
+
#*The card can buffer up to 4 triggers, so higher burst rates will be obtainable.
−
17% occupancy (1 hit per chip) = 5.9uS = ~170kHz
+
−
100% occupancy (6 hits per chip, on all 12 chips) = 8.8uS = ~113kHz
+
−
 
+
−
Just algorithm = 4.68uS  
+
−
</pre>
+
−
The card can buffer up to 4 triggers, so higher burst rates will be obtainable.
+
 
#Busy signal (from Cody):  
 
#Busy signal (from Cody):  
−
##Data from 4 hits can be buffered before the busy signal is asserted.  If the data from the first hit is still processing, the busy signal would switch on when a 5th trigger is received.  This 5th set of data would be processed, but data from 6th and later triggers would be rejected if the busy signal is still on. The busy signal is cleared when one set of data has been processed and there are 4 or fewer triggers (aka sets of hit data) in the buffer.   
+
#*Data from 4 hits can be buffered before the busy signal is asserted.  If the data from the first hit is still processing, the busy signal would switch on when a 5th trigger is received.  This 5th set of data would be processed, but data from 6th and later triggers would be rejected if the busy signal is still on. The busy signal is cleared when one set of data has been processed and there are 4 or fewer triggers (aka sets of hit data) in the buffer.   
−
##Each fadc has its own busy signal.
+
#*Each fadc has its own busy signal.
−
##The busy signal is transmitted through the backplane; no extra wiring is needed.  
+
#*The busy signal is transmitted through the backplane; no extra wiring is needed.  
−
##The propagation delay time is unknown at present.  This is the time for the busy signal to go through the backplane to the SD cards to the TI board in the same crate and then through fibre optic to the TS crate.  It is probably about 1us.  Cody will measure this.  The level 1 holdoff should be larger than the propagation delay.
+
#*The propagation delay time is unknown at present.  This is the time for the busy signal to go through the backplane to the SD cards to the TI board in the same crate and then through fibre optic to the TS crate.  It is probably about 1us.  Cody will measure this.  The level 1 holdoff should be larger than the propagation delay.
−
##Any card in the system (ie any fadc from any detector) asserting busy will cause the TS to stop sending triggers until the busy has cleared.   
+
#*Any card in the system (ie any fadc from any detector) asserting busy will cause the TS to stop sending triggers until the busy has cleared.   
−
##Holdoff times. The level 1 holdoff should be set larger than the propagation delay. It would be possible for the TS firmware to monitor the busy signal and count the number of triggers it has sent out but it does not do this at present. Only a minimum holdoff would be needed between the first 3 triggers (probably on the order of 10 to a few 100 ns, less than the propagation delay).  
+
#*Holdoff times. The level 1 holdoff should be set larger than the propagation delay. It would be possible for the TS firmware to monitor the busy signal and count the number of triggers it has sent out but it does not do this at present. Only a minimum holdoff would be needed between the first 3 triggers (probably on the order of 10 to a few 100 ns, less than the propagation delay).
 +
#*The TS has the firmware to handle the busy signals from the fadcs but this has not been implemented yet.  
 
#VME readout (from Sergey):
 
#VME readout (from Sergey):
−
##The VME readout has a reasonable livetime up to 100kHz.
+
#*The VME readout has a reasonable livetime up to 100kHz.
−
##It takes some time to get the data off the fadc board through the backplane. The amount of transfers are limited by the 4MB DMA protocol buffer size. The buffer must be emptied when it is filled and the 4MB is a consequence of the DMA protocol.  It takes 170us to transfer this buffer with the blocklevel=20.  The buffer size is set for 100% occupancy, blocklevel has to be no more than 40 for the CDC in order to fit a crateful of hits into the DMA buffer.  Setting up the DMA transfer takes 100 us, transfer is much shorter (~50us). The DMA buffer is on the ROC.  (So increasing the number of crates would increase the total buffers available).  
+
#*BlockLevel is the number of triggers (events) which accumulate on the fadc125 board before VME readout. After VME readout,  all of them will be written into one evio block of data.
−
##Using the busy signal should improve the livetime as the trigger holdoff can be reduced to min, not a conservative (worst case) value as at present.  The current bottleneck is tagger fadcs (because of the cable length?).     
+
#*BufferLevel is the number of blocks allowed to be stored on the fadc125 before further triggers from the TS are inhibited.
−
 
+
#*The output buffer on the fadc can hold up to 262k 32bit words, but in practice we do not reach this amount because the ROC (one per crate) buffer is 4MB.  The ROC data buffer size is limited to 4MB by the DMA protocol and it must be emptied when it is full. 
−
#Hit occupancy & search (Naomi):
+
##It takes some time to get the data off the fadc board through the backplane. The amount of transfers are limited by the 4MB DMA protocol buffer size. It takes 170us to transfer this buffer with the blocklevel=20.  The buffer size is set for 100% occupancy, blocklevel has to be no more than 40 for the CDC in order to fit a crateful of hits into the DMA buffer.  Setting up the DMA transfer takes 100 us, transfer is much shorter (~50us). The DMA buffer is on the ROC.  (So increasing the number of crates would increase the total buffers available).  
−
Run data hit occupancy plots are mostly 0 or 1 per trigger, with an occasional 6 (100%), will produce some plots.  An idea to improve the hit search by inspecting every other sample instead of every sample (as we require 2 consecutive samples over threshold) but this has some overheads per possible hit and because of this it would not be an improvement if the threshold was skimming the noise.
+
#*Using the busy signal should improve the livetime as the trigger holdoff can be reduced to the minimum necessary, not a conservative (worst case) value as at present.  The current bottleneck is the tagger fadcs (because of the cable length?).     
−
 
+
#*Hit occupancy & search (Naomi):
−
<pre>
+
Run data hit occupancy plots are mostly 0 or 1 per trigger, with an occasional 6 (100%); Naomi will provide some plots.  An idea to improve the hit search by inspecting every other sample instead of every sample (as we require 2 consecutive samples over threshold) but this has some overheads per possible hit and because of this it would not be an improvement if the threshold was skimming the noise.
−
random trig from TI, block trigs, measure ratio of ack/declined
+
#Test plans
−
might be limited to 250khz. 
+
#*We need to make sure that the firmware is up to date on the TI and TS, and look out for possible customizations in the present code. Sergey will look to see if any updates are needed. We only need to use one crate for testing.  Sergey will notify Sascha when updating the firmware.
−
 
+
#*Cody will measure the delay times with Ben Raydo and Sergey.
−
 
+
#*Cody usually tests using a low threshold (so that all channels see hits) and masking off channels to give a defined occupancy.
−
Beni : pmt+light leak more realistic trigger.
+
#*The TI produces a random trigger, could measure ration of acknowledged: declined, but the trigger might be limited to 250khz. 
−
 
+
#*Beni will provide a more realistic 'true random' trigger using a PMT with a small light leak.
−
Cody sets low thres & masks channels so have defined occupancy.
+
#*An alternative is to use trig2 (?) produced from a trigger analog pulser and vary the time between trig1 and trig2.
−
 
+
#*Fernando needs to be notified before the CDC LV is switched on, we do not need HV.
−
 
+
#*The fa125 readback mode was disabled when short of space but could be re-enabled for a test version with one readout mode. It was not clear if this would be beneficial.
−
Sergey says TS firmware busy is implemented but not tested.  Will look to see which versions of the TI and TS firmware we have.  They may have been customised.
+
−
Sergey will look to see which versions we have.
+
−
 
+
−
can update firmware  
+
−
set registers in TS.
+
−
 
+
−
 
+
−
Cody & Ben will measure delay times.  w Sergey.
+
−
 
+
−
notify fernando switch on LV only
+
−
masking
+
−
distribution of random triggers
+
−
beni set up true random pmt trigger
+
−
 
+
−
notify sascha before cody & sergey will update one crate.
+
−
 
+
−
dave abbott also wants to test newer stuff
+
−
 
+
−
 
+
−
readback mode disabled when short of space but could be reenabled for test version w one mode.
+
−
 
+
−
trig2. trigger analog pulser, vary time of trig1&2
+
−
 
+
−
 
+
−
</pre>
+

Revision as of 11:58, 18 May 2016

May 13, 2016 FA125 meeting

Connection

  1. Instructions for Bluejeans meeting connection
  2. Meeting ID: 290664653

Headline text

  1. To join via a Web Browser, go to the page [1] https://bluejeans.com/290664653.

Agenda

  1. Objectives
  2. Current performance
  3. Busy signal details
  4. Testing plans

DRAFT Minutes NOT FINISHED YET read at your own risk

Participants: Naomi, Cody, David, Sergey, Beni, Lubomir


  1. Objectives: David reminded us that the objectives for the runs in 2018 include a rate on the target of 5e7 photons/second and the DAQ running at 100kHz (a photon flux of 1e8 Hz was mentioned originally, but this was reduced to 5e7). The DAQ livetime was not mentioned but is assumed to be 90%.
  2. Current performance: Cody's tests show the FA125 running at sustained rates (continuously, so 0% livetime) with the current parameters of window size = 200, integrating to the end of the window, 16 pedestal samples, search for 1 peak, for short mode, trigger in to data out:
    • 0% occupancy (no hits) = 4.9uS = ~204kHz
    • 17% occupancy (1 hit per chip) = 5.9uS = ~170kHz
    • 100% occupancy (6 hits per chip, on all 12 chips) = 8.8uS = ~113kHz
    • Just algorithm = 4.68uS
    • The card can buffer up to 4 triggers, so higher burst rates will be obtainable.
  3. Busy signal (from Cody):
    • Data from 4 hits can be buffered before the busy signal is asserted. If the data from the first hit is still processing, the busy signal would switch on when a 5th trigger is received. This 5th set of data would be processed, but data from 6th and later triggers would be rejected if the busy signal is still on. The busy signal is cleared when one set of data has been processed and there are 4 or fewer triggers (aka sets of hit data) in the buffer.
    • Each fadc has its own busy signal.
    • The busy signal is transmitted through the backplane; no extra wiring is needed.
    • The propagation delay time is unknown at present. This is the time for the busy signal to go through the backplane to the SD cards to the TI board in the same crate and then through fibre optic to the TS crate. It is probably about 1us. Cody will measure this. The level 1 holdoff should be larger than the propagation delay.
    • Any card in the system (ie any fadc from any detector) asserting busy will cause the TS to stop sending triggers until the busy has cleared.
    • Holdoff times. The level 1 holdoff should be set larger than the propagation delay. It would be possible for the TS firmware to monitor the busy signal and count the number of triggers it has sent out but it does not do this at present. Only a minimum holdoff would be needed between the first 3 triggers (probably on the order of 10 to a few 100 ns, less than the propagation delay).
    • The TS has the firmware to handle the busy signals from the fadcs but this has not been implemented yet.
  4. VME readout (from Sergey):
    • The VME readout has a reasonable livetime up to 100kHz.
    • BlockLevel is the number of triggers (events) which accumulate on the fadc125 board before VME readout. After VME readout, all of them will be written into one evio block of data.
    • BufferLevel is the number of blocks allowed to be stored on the fadc125 before further triggers from the TS are inhibited.
    • The output buffer on the fadc can hold up to 262k 32bit words, but in practice we do not reach this amount because the ROC (one per crate) buffer is 4MB. The ROC data buffer size is limited to 4MB by the DMA protocol and it must be emptied when it is full.
    1. It takes some time to get the data off the fadc board through the backplane. The amount of transfers are limited by the 4MB DMA protocol buffer size. It takes 170us to transfer this buffer with the blocklevel=20. The buffer size is set for 100% occupancy, blocklevel has to be no more than 40 for the CDC in order to fit a crateful of hits into the DMA buffer. Setting up the DMA transfer takes 100 us, transfer is much shorter (~50us). The DMA buffer is on the ROC. (So increasing the number of crates would increase the total buffers available).
    • Using the busy signal should improve the livetime as the trigger holdoff can be reduced to the minimum necessary, not a conservative (worst case) value as at present. The current bottleneck is the tagger fadcs (because of the cable length?).
    • Hit occupancy & search (Naomi):

Run data hit occupancy plots are mostly 0 or 1 per trigger, with an occasional 6 (100%); Naomi will provide some plots. An idea to improve the hit search by inspecting every other sample instead of every sample (as we require 2 consecutive samples over threshold) but this has some overheads per possible hit and because of this it would not be an improvement if the threshold was skimming the noise.

  1. Test plans
    • We need to make sure that the firmware is up to date on the TI and TS, and look out for possible customizations in the present code. Sergey will look to see if any updates are needed. We only need to use one crate for testing. Sergey will notify Sascha when updating the firmware.
    • Cody will measure the delay times with Ben Raydo and Sergey.
    • Cody usually tests using a low threshold (so that all channels see hits) and masking off channels to give a defined occupancy.
    • The TI produces a random trigger, could measure ration of acknowledged: declined, but the trigger might be limited to 250khz.
    • Beni will provide a more realistic 'true random' trigger using a PMT with a small light leak.
    • An alternative is to use trig2 (?) produced from a trigger analog pulser and vary the time between trig1 and trig2.
    • Fernando needs to be notified before the CDC LV is switched on, we do not need HV.
    • The fa125 readback mode was disabled when short of space but could be re-enabled for a test version with one readout mode. It was not clear if this would be beneficial.
Retrieved from "https://halldweb1.jlab.org/wiki/index.php?title=FA125_Meeting_May_13,_2016&oldid=75111"