https://wiki.anl.gov/wiki_gsdaq/api.php?action=feedcontributions&feedformat=atom&user=Copp GammaSphere DAQ - User contributions [en] 2024-03-29T13:53:17Z User contributions MediaWiki 1.39.5 https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_GEBSort_and_Analysis_Codes&diff=2423 ANL GEBSort and Analysis Codes 2021-10-18T19:57:26Z <p>Copp: </p> <hr /> <div>== README.bin_dgs ''October, 2021'' ==<br /> This is copied from the README.bin_dgs written by Torben in October, 2021 to incorporate Shaofei's latest Pole Zero correction algorithm.<br /> <br /> === Intro ===<br /> <br /> Bin_dgs.c has three algorithms from Shaofei: 0, 1 and 2. You specify which one to use in the chatfile.<br /> <br /> Algo 0 is the one we have used so far and requires m1begin...m2end data to be in the header. That is true for header types 3/4 and 5/6.<br /> The new data format 7/8 will not have this information; but algo's 2 and 3 should work just fine. <br /> <br /> Instructions for using algo 0 is on the wiki and will not be discussed here (go to [[analysis codes]]). Here we discuss algo 2 first. The instructions will be rather terse; but you should be able to copy/paste most of it to get a good start.<br /> <br /> To get the GEBSort package<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> ==== GEBSort chat file: ====<br /> <br /> # parameters for bin_dgs<br /> # algo 0: old SZ. Requires: header type 3/4 or 5/6<br /> # algo 1: simple SZ algo. Requires: dgs_PZ<br /> # algo 2: high rate algo. Requires: dgs_PZ, dgs_factor, t1 and t2 <br /> # extrapolation below t2. Factor sampled bt t2...t1 (t1&gt;t2)<br /> <br /> dgs_algo 2<br /> dgs_MM 200<br /> dgs_KK 141<br /> dgs_SZ_t1 50<br /> dgs_SZ_t2 20<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> dgs_factor dgs_factor.dat<br /> <br /> to find M and K, look in the .save file of your data.<br /> Here is an example:<br /> <br /> caput GLBL:DIG:d_window 0.06<br /> caput GLBL:DIG:k_window 0.20<br /> caput GLBL:DIG:m_window 2.00<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> # fe 0.06+0.20+0.80+0.20+0.15 = 1.41 or 141 10ns unit<br /> ^<br /> +------ this one is extra<br /> <br /> ==== Source/cal sort: ====<br /> <br /> Make a link to where the data is, and where to find GEBSORT<br /> <br /> rm GTDATA; ln -s /run/media/tl/20200719_1530/user/gsfma370/100 GTDATA<br /> rm GEBSORT; ln -s /home/tl/d6/GEBSort GEBSORT<br /> <br /> Clean so we don't find old stuff<br /> <br /> rm *.spe *.var<br /> rm dgs_pz.cal<br /> rm dgs_ehi.cal<br /> rm dgs_factor.dat<br /> rm test.root<br /> <br /> Find basic PZ. You may want to edit the file if you know better than the SZ_basic_PZ program. The first argument to the program is 1/lambda. 200 is the M we are using here.<br /> <br /> GEBSORT/SZ_basic_PZ 3251.342285 200 1.000 &gt; dgs_pz.cal<br /> <br /> Find the extrapolation factor values (content of go_one.sh is below)<br /> <br /> ./go_one.sh<br /> GEBSORT/SZ_factor test.root factor dgs_factor.dat<br /> <br /> Energy calibration. You may have to find the coefficients for some detectors by hand (blame the detector)<br /> <br /> ./go_one.sh<br /> rootn.exe<br /> dload(&quot;test.root&quot;)<br /> .x GEBSORT/get_eraw.cc<br /> .q<br /> GEBSORT/dgs_ecal dgs_ehi.cal 207Bi 900 1.0<br /> <br /> Final sort with PZ, ecal, and factor<br /> <br /> ./go_one.sh<br /> <br /> rootn.exe<br /> dload(&quot;test.root&quot;)<br /> d2(&quot;EhiCln&quot;)<br /> pjx(&quot;EhiCln&quot;,&quot;xx&quot;)<br /> d1(&quot;xx&quot;,0,1200)<br /> d2(&quot;vdcXsum1_081&quot;)<br /> d2(&quot;eXdtev&quot;)<br /> d2(&quot;dtev&quot;)<br /> d3(&quot;vdcXsum1&quot;)<br /> d2(&quot;factor&quot;)<br /> .x GEBSORT/get_ecln.cc<br /> .q<br /> <br /> Use gf3 and d_ecal.cmd to see all detectors that are enabled and verify their spectra look good.<br /> <br /> ''Go back to [[Advanced User Guides]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_GEBSort_and_Analysis_Codes&diff=2422 ANL GEBSort and Analysis Codes 2021-10-18T19:56:27Z <p>Copp: </p> <hr /> <div>== README.bin_dgs ''October, 2021'' ==<br /> This is copied from the README.bin_dgs written by Torben in October, 2021 to incorporate Shaofei's latest Pole Zero correction algorithm.<br /> <br /> === Intro ===<br /> <br /> Bin_dgs.c has three algorithms from Shaofei: 0, 1 and 2. You specify which one to use in the chatfile.<br /> <br /> Algo 0 is the one we have used so far and requires m1begin...m2end data to be in the header. That is true for header types 3/4 and 5/6.<br /> The new data format 7/8 will not have this information; but algo's 2 and 3 should work just fine. <br /> <br /> Instructions for using algo 0 is on the wiki and will not be discussed here (go to [[analysis codes]]). Here we discuss algo 2 first. The instructions will be rather terse; but you should be able to copy/paste most of it to get a good start.<br /> <br /> To get the GEBSort package<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> ==== GEBSort chat file: ====<br /> <br /> # parameters for bin_dgs<br /> # algo 0: old SZ. Requires: header type 3/4 or 5/6<br /> # algo 1: simple SZ algo. Requires: dgs_PZ<br /> # algo 2: high rate algo. Requires: dgs_PZ, dgs_factor, t1 and t2 <br /> # extrapolation below t2. Factor sampled bt t2...t1 (t1&gt;t2)<br /> <br /> dgs_algo 2<br /> dgs_MM 200<br /> dgs_KK 141<br /> dgs_SZ_t1 50<br /> dgs_SZ_t2 20<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> dgs_factor dgs_factor.dat<br /> <br /> to find M and K, look in the .save file of your data.<br /> Here is an example:<br /> <br /> caput GLBL:DIG:d_window 0.06<br /> caput GLBL:DIG:k_window 0.20<br /> caput GLBL:DIG:m_window 2.00<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> # fe 0.06+0.20+0.80+0.20+0.15 = 1.41 or 141 10ns unit<br /> ^<br /> +------ this one is extra<br /> <br /> ==== Source/cal sort: ====<br /> <br /> Make a link to where the data is, and where to find GEBSORT<br /> <br /> rm GTDATA; ln -s /run/media/tl/20200719_1530/user/gsfma370/100 GTDATA<br /> rm GEBSORT; ln -s /home/tl/d6/GEBSort GEBSORT<br /> <br /> Clean so we don't find old stuff<br /> <br /> rm *.spe *.var<br /> rm dgs_pz.cal<br /> rm dgs_ehi.cal<br /> rm dgs_factor.dat<br /> rm test.root<br /> <br /> Find basic PZ. You may want to edit the file if you know better than the SZ_basic_PZ program. The first argument to the program is 1/lambda. 200 is the M we are using here.<br /> <br /> GEBSORT/SZ_basic_PZ 3251.342285 200 1.000 &gt; dgs_pz.cal<br /> <br /> Find the extrapolation factor values (content of go_one.sh is below)<br /> <br /> ./go_one.sh<br /> GEBSORT/SZ_factor test.root factor dgs_factor.dat<br /> <br /> Energy calibration. You may have to find the coefficients for some detectors by hand (blame the detector)<br /> <br /> ./go_one.sh<br /> rootn.exe<br /> dload(&quot;test.root&quot;)<br /> .x GEBSORT/get_eraw.cc<br /> .q<br /> GEBSORT/dgs_ecal dgs_ehi.cal 207Bi 900 1.0<br /> <br /> Final sort with PZ, ecal, and factor<br /> <br /> ./go_one.sh<br /> <br /> rootn.exe<br /> dload(&quot;test.root&quot;)<br /> d2(&quot;EhiCln&quot;)<br /> pjx(&quot;EhiCln&quot;,&quot;xx&quot;)<br /> d1(&quot;xx&quot;,0,1200)<br /> d2(&quot;vdcXsum1_081&quot;)<br /> d2(&quot;eXdtev&quot;)<br /> d2(&quot;dtev&quot;)<br /> d3(&quot;vdcXsum1&quot;)<br /> d2(&quot;factor&quot;)<br /> .x GEBSORT/get_ecln.cc<br /> .q<br /> <br /> Use gf3 and d_ecal.cmd to see all detectors that are enabled and verify their spectra look good.<br /> <br /> ''Go back to</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2421 ANL Digitizer Firmware for Advanced Users 2021-10-18T19:51:14Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> === Pipeline Structure ===<br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> The channel pipelines have two basic modes of operation, Leading-Edge Discriminator and Constant-Fraction Discriminator. Data in both modes reads out as a packet consisting of ''header'' followed by ''waveform''. <br /> <br /> ==Readout Data Format==<br /> VME data readout is always 32-bit words. A ''header type'' value in the ''header'' indicates which mode the channel was in when the data was taken. A ''header length'' field indicates how many 32-bit words are in the ''header'', and a separate ''packet length'' field states the total length of ''header'' plus ''waveform''. <br /> <br /> === Data Header ===<br /> The header format for the ANL digitizer was updated with ''header types'' 7 &amp; 8 for the August 2021 release. Header type 7 corresponds to LED mode, and header type 8 corresponds to CFD mode of operation. All data read from the digitizer is 32 bits wide, and the header is 14 words long.<br /> <br /> ''Go Back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2420 ANL Digitizer Firmware for Advanced Users 2021-10-18T19:46:34Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> === Pipeline Structure ===<br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> The channel pipelines have two basic modes of operation, Leading-Edge Discriminator and Constant-Fraction Discriminator. Data in both modes reads out as a packet consisting of ''header'' followed by ''waveform''. <br /> <br /> ==Readout Data Format==<br /> VME data readout is always 32-bit words. A ''header type'' value in the ''header'' indicates which mode the channel was in when the data was taken. A ''header length'' field indicates how many 32-bit words are in the ''header'', and a separate ''packet length'' field states the total length of ''header'' plus ''waveform''. <br /> <br /> === [[Data Header]] ===<br /> The header format for the ANL digitizer was updated with ''header types'' 7 &amp; 8 for the August 2021 release. Header type 7 corresponds to LED mode, and header type 8 corresponds to CFD mode of operation. All data read from the digitizer is 32 bits wide, and the header is 14 words long.<br /> <br /> ''Go Back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2419 ANL Digitizer Firmware for Advanced Users 2021-10-18T19:11:29Z <p>Copp: /* Pipeline Structure */</p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> === Pipeline Structure ===<br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> ''Go Back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2418 ANL Digitizer Firmware for Advanced Users 2021-10-18T19:10:36Z <p>Copp: /* Digitizer Channel Design Overview */</p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> === [[Pipeline Structure]] ===<br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> ''Go Back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2417 ANL Digitizer Firmware for Advanced Users 2021-10-18T16:31:31Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> ''Go Back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=DGS_Commander_EDM_Screens&diff=2416 DGS Commander EDM Screens 2021-10-18T16:30:59Z <p>Copp: </p> <hr /> <div>This is an interactive image map of the DGS Commander EPICS screens. Click on text (these are buttons on the GUI) to proceed to the next screen. This allows you to explore the entire DAQ system without accidentally changing something during experimental operation.<br /> <br /> &lt;imagemap&gt;<br /> Image:DGSCommander Screen.png|frame|center|alt=Test Image Map<br /> rect 11 96 114 130 [[Run Control Start/Stop]]<br /> rect 14 162 113 196 [[Run Control Save/NoSave]]<br /> rect 139 92 296 129 [[Run Control Trigger]]<br /> rect 139 158 297 190 [[Run Control Digitizers]]<br /> rect 138 217 295 250 [[Run Control Count Rates]]<br /> <br /> rect 319 93 474 128 [[Run Control Global Control]]<br /> rect 317 155 476 190 [[Run Control VME Status]]<br /> rect 318 215 475 250 [[Run Control Live Time Stamps]]<br /> <br /> rect 497 94 656 150 [[Run Control Terminals]]<br /> rect 498 156 657 190 [[Run Control Misc. Controls]]<br /> rect 497 215 657 251 [[Run Control Scripts]]<br /> <br /> rect 673 44 785 75 [[Run Control Aux Main]]<br /> rect 673 88 785 121 [[Run Control VXI Boards]]<br /> rect 673 135 785 167 [[Run Control Ge High Volt.]]<br /> rect 673 183 785 215 [[Run Control Ge CFD]]<br /> rect 673 227 785 261 [[Run Control Side Channel]]<br /> &lt;/imagemap&gt;<br /> <br /> ''Go Back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_GEBSort_and_Analysis_Codes&diff=2415 ANL GEBSort and Analysis Codes 2021-10-14T17:05:00Z <p>Copp: Created page with &quot;== README.bin_dgs ''October, 2021'' == This is copied from the README.bin_dgs written by Torben to incorporate Shaofei's latest Pole Zero correction algorithm. === Intro ===...&quot;</p> <hr /> <div>== README.bin_dgs ''October, 2021'' ==<br /> This is copied from the README.bin_dgs written by Torben to incorporate Shaofei's latest Pole Zero correction algorithm.<br /> <br /> === Intro ===<br /> <br /> Bin_dgs.c has three algorithms from Shaofei: 0, 1 and 2. You specify which one to use in the chatfile.<br /> <br /> Algo 0 is the one we have used so far and requires m1begin...m2end data to be in the header. That is true for header types 3/4 and 5/6.<br /> The new data format 7/8 will not have this information; but algo's 2 and 3 should work just fine. <br /> <br /> Instructions for using algo 0 is on the wiki and will not be discussed here (go to [[analysis codes]]). Here we discuss algo 2 first. The instructions will be rather terse; but you should be able to copy/paste most of it to get a good start.<br /> <br /> To get the GEBSort package<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git<br /> <br /> ==== GEBSort chat file: ====<br /> <br /> # parameters for bin_dgs<br /> # algo 0: old SZ. Requires: header type 3/4 or 5/6<br /> # algo 1: simple SZ algo. Requires: dgs_PZ<br /> # algo 2: high rate algo. Requires: dgs_PZ, dgs_factor, t1 and t2 <br /> # extrapolation below t2. Factor sampled bt t2...t1 (t1&gt;t2)<br /> <br /> dgs_algo 2<br /> dgs_MM 200<br /> dgs_KK 141<br /> dgs_SZ_t1 50<br /> dgs_SZ_t2 20<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> dgs_factor dgs_factor.dat<br /> <br /> to find M and K, look in the .save file of your data.<br /> Here is an example:<br /> <br /> caput GLBL:DIG:d_window 0.06<br /> caput GLBL:DIG:k_window 0.20<br /> caput GLBL:DIG:m_window 2.00<br /> caput GLBL:DIG:k0_window 0.80<br /> caput GLBL:DIG:d3_window 0.20<br /> # fe 0.06+0.20+0.80+0.20+0.15 = 1.41 or 141 10ns unit<br /> ^<br /> +------ this one is extra<br /> <br /> ==== Source/cal sort: ====<br /> <br /> Make a link to where the data is, and where to find GEBSORT<br /> <br /> rm GTDATA; ln -s /run/media/tl/20200719_1530/user/gsfma370/100 GTDATA<br /> rm GEBSORT; ln -s /home/tl/d6/GEBSort GEBSORT<br /> <br /> Clean so we don't find old stuff<br /> <br /> rm *.spe *.var<br /> rm dgs_pz.cal<br /> rm dgs_ehi.cal<br /> rm dgs_factor.dat<br /> rm test.root<br /> <br /> Find basic PZ. You may want to edit the file if you know better than the SZ_basic_PZ program. The first argument to the program is 1/lambda. 200 is the M we are using here.<br /> <br /> GEBSORT/SZ_basic_PZ 3251.342285 200 1.000 &gt; dgs_pz.cal<br /> <br /> Find the extrapolation factor values (content of go_one.sh is below)<br /> <br /> ./go_one.sh<br /> GEBSORT/SZ_factor test.root factor dgs_factor.dat<br /> <br /> Energy calibration. You may have to find the coefficients for some detectors by hand (blame the detector)<br /> <br /> ./go_one.sh<br /> rootn.exe<br /> dload(&quot;test.root&quot;)<br /> .x GEBSORT/get_eraw.cc<br /> .q<br /> GEBSORT/dgs_ecal dgs_ehi.cal 207Bi 900 1.0<br /> <br /> Final sort with PZ, ecal, and factor<br /> <br /> ./go_one.sh<br /> <br /> rootn.exe<br /> dload(&quot;test.root&quot;)<br /> d2(&quot;EhiCln&quot;)<br /> pjx(&quot;EhiCln&quot;,&quot;xx&quot;)<br /> d1(&quot;xx&quot;,0,1200)<br /> d2(&quot;vdcXsum1_081&quot;)<br /> d2(&quot;eXdtev&quot;)<br /> d2(&quot;dtev&quot;)<br /> d3(&quot;vdcXsum1&quot;)<br /> d2(&quot;factor&quot;)<br /> .x GEBSORT/get_ecln.cc<br /> .q<br /> <br /> Use gf3 and d_ecal.cmd to see all detectors that are enabled and verify their spectra look good.<br /> <br /> ''Go back to</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2414 Analysis codes 2021-10-14T16:47:05Z <p>Copp: </p> <hr /> <div>== Typical run procedure ==<br /> ''Original content prior to the 2021 Gammasphere Upgrade Project.''<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd gtreceiver; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = Acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save or runxx.info file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ calibration file is generated, <br /> <br /> run GEBSort again<br /> <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_eraw.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> To extract the calibrated spectra<br /> <br /> .x get_ecln.cc<br /> <br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''<br /> <br /> ''Go back to [[ANL GEBSort and Analysis Codes]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Advanced_User_Guides&diff=2413 Advanced User Guides 2021-10-14T16:43:50Z <p>Copp: </p> <hr /> <div>== [[DGS Commander EPICS Screens]] ==<br /> The DGS Commander (sometimes referred to as DGS Main Controller) is a GUI (Graphical User Interface) generated by EPICS (Experimental Physics and Industrial Controls System). DGS Main Controller is the Home Screen that provides access to all essential monitors and controls for the Gammasphere array. The [[DGS Commander EPICS Screens]] link has an interactive image map that provides a walkthrough of subsequent screens.<br /> <br /> == [[ANL GEBSort and Analysis Codes]] ==<br /> This section expands upon [[analysis codes]]. All information can be found in the README files. The main topics of discussion include bin_dgs.c, GEBSort.chat, etc.<br /> <br /> == [[ANL Digitizer Firmware for Advanced Users]] ==<br /> This section is intended for users of the experiment setups at ATLAS who will be working with the firmware and adjusting parameters; a separate document, ''Waveform Digitizers at the ATLAS experiments'', is available for those interested in a general overview of the digital data acquisition systems without reference to technical details. This advanced guide also glosses over many details of the firmware to present a view sufficient for non-expert users. Experts are referred to the document ''[[ANL Digitizer Firmware for Experts]]'' for details.<br /> <br /> ''Click here for more [[firmware documentation]]''<br /> <br /> == [[triggers and digitizers]] ==<br /> This section presents a brief overview of how to set up the Master Trigger and Router Trigger modules.<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digital_Gammasphere_Upgrade_Project&diff=2412 Digital Gammasphere Upgrade Project 2021-10-05T14:37:14Z <p>Copp: </p> <hr /> <div>== Gammasphere Setup in Area 4 ==<br /> <br /> The panoramic image of Gammasphere is interactive. Click on text to go to the link.<br /> <br /> &lt;imagemap&gt;<br /> Image:AREA4 Panorama Text.jpg|frame|center|alt=Test Image Map<br /> rect 180 10 360 66 [[LN system]]<br /> rect 410 200 650 260 [[Gammasphere Detectors]]<br /> rect 110 315 245 375 [[DAQ system]]<br /> &lt;/imagemap&gt;<br /> <br /> As of September, 2021, two major milestones have been accomplished for the Gammashpere Upgrade:<br /> # Odd GS 81-109 have [[The Slope Box Extension]] upgrade equipped on each detector module (HPGe + BGO + SB = detector module).<br /> # VXI 5 has been decommissioned, allowing grey cables for GS 81-109 to be removed from array.<br /> # A passive Collector Box is in use with a new Router Cable Plant, allowing one VME crate (containing three IOCs) to be removed from the shack. Fiber Optic cable connects Router 3 to Master Trigger inside the shack.<br /> <br /> == [[User Guides for Experiments]] ==<br /> The ''User Guides for Experiments'' contain brief walkthroughs that are used for EVERY experiment with Digital Gammashpere. It outlines the directory structure, start/stop data collection runs, merging and sorting data, calibrating the HPGe detectors, etc. These are meant for all ATLAS Users who take shifts for experiments.<br /> <br /> == [[Advanced User Guides]] ==<br /> The ''Advanced User Guides'' contain more detailed guides on how to setup an experiment for Digital Gammasphere. This is intended for frequent/returning users, ANL postdocs, and graduate students on extended visits who assist in maintaining and operating Gammasphere. These guides cover more advanced topics for ATLAS Users who have experience running experiments and desire a deeper understanding of Gammasphere's systems and supporting software/firmware/devices.<br /> <br /> == [[Expert Documentation]] ==<br /> The ''Expert Documentation'' section contains downloads of highly detailed documentation and procedures developed by onsite experts. These are not meant for training personnel in experimental operations. ATLAS Users who are Principal Investigators may obtain understanding of certain functionality specific to their proposed experiment. Some of these topics are still in the developing/testing/implementing phases of new hardware/firmware/software for Gammasphere.</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digital_Gammasphere_and_the_SBX_Upgrade&diff=2411 Digital Gammasphere and the SBX Upgrade 2021-10-05T14:34:04Z <p>Copp: </p> <hr /> <div>== Gammasphere Setup in Area 4 ==<br /> <br /> The panoramic image of Gammasphere is interactive. Click on text to go to the link.<br /> <br /> &lt;imagemap&gt;<br /> Image:AREA4 Panorama Text.jpg|frame|center|alt=Test Image Map<br /> rect 180 10 360 66 [[LN system]]<br /> rect 410 200 650 260 [[Gammasphere Detectors]]<br /> rect 110 315 245 375 [[DAQ system]]<br /> &lt;/imagemap&gt;<br /> <br /> As of September, 2021, two major milestones have been accomplished for the Gammashpere Upgrade:<br /> # Odd GS 81-109 have [[The Slope Box Extension]] upgrade equipped on each detector module (HPGe + BGO + SB + SBX = One Detector Module).<br /> # VXI 5 has been taken offline, allowing for removal of odd GS 81-109 grey cables.<br /> # A passive Collector Box is in use with a new Router Cable Plant, allowing one VME crate (containing three IOCs) to be removed from the shack. Fiber optic cable connects Router 3 to Master Trigger in the shack.<br /> <br /> == [[User Guides for Experiments]] ==<br /> The ''User Guides for Experiments'' contain brief walkthroughs that are used for EVERY experiment with Digital Gammashpere. It outlines the directory structure, start/stop data collection runs, merging and sorting data, calibrating the HPGe detectors, etc. These are meant for all ATLAS Users who take shifts for experiments.<br /> <br /> == [[Advanced User Guides]] ==<br /> The ''Advanced User Guides'' contain more detailed guides on how to setup an experiment for Digital Gammasphere. This is intended for frequent/returning users, ANL postdocs, and graduate students on extended visits who assist in maintaining and operating Gammasphere. These guides cover more advanced topics for ATLAS Users who have experience running experiments and desire a deeper understanding of Gammasphere's systems and supporting software/firmware/devices.<br /> <br /> == [[Expert Documentation]] ==<br /> The ''Expert Documentation'' section contains downloads of highly detailed documentation and procedures developed by onsite experts. These are not meant for training personnel in experimental operations. ATLAS Users who are Principal Investigators may obtain understanding of certain functionality specific to their proposed experiment. Some of these topics are still in the developing/testing/implementing phases of new hardware/firmware/software for Gammasphere.</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digital_Gammasphere_and_the_SBX_Upgrade&diff=2410 Digital Gammasphere and the SBX Upgrade 2021-10-05T14:32:55Z <p>Copp: /* Gammasphere Setup in Area 4 */</p> <hr /> <div>== Gammasphere Setup in Area 4 ==<br /> <br /> The panoramic image of Gammasphere is interactive. Click on text to go to the link.<br /> <br /> &lt;imagemap&gt;<br /> Image:AREA4 Panorama Text.jpg|frame|center|alt=Test Image Map<br /> rect 180 10 360 66 [[LN system]]<br /> rect 410 200 650 260 [[Gammasphere Detectors]]<br /> rect 110 315 245 375 [[DAQ system]]<br /> &lt;/imagemap&gt;<br /> <br /> As of September, 2021, two major milestones have been accomplished for the Gammashpere Upgrade:<br /> # Odd GS 81-109 have [[The Slope Box Extension]] upgrade equipped on each detector module (HPGe + BGO)<br /> # VXI 5 has been taken offline, allowing for removal of odd GS 81-109 grey cables.<br /> # A passive Collector Box is in use with a new Router Cable Plant, allowing one VME crate (containing three IOCs) to be removed from the shack. Fiber optic cable connects Router 3 to Master Trigger in the shack.<br /> <br /> == [[User Guides for Experiments]] ==<br /> The ''User Guides for Experiments'' contain brief walkthroughs that are used for EVERY experiment with Digital Gammashpere. It outlines the directory structure, start/stop data collection runs, merging and sorting data, calibrating the HPGe detectors, etc. These are meant for all ATLAS Users who take shifts for experiments.<br /> <br /> == [[Advanced User Guides]] ==<br /> The ''Advanced User Guides'' contain more detailed guides on how to setup an experiment for Digital Gammasphere. This is intended for frequent/returning users, ANL postdocs, and graduate students on extended visits who assist in maintaining and operating Gammasphere. These guides cover more advanced topics for ATLAS Users who have experience running experiments and desire a deeper understanding of Gammasphere's systems and supporting software/firmware/devices.<br /> <br /> == [[Expert Documentation]] ==<br /> The ''Expert Documentation'' section contains downloads of highly detailed documentation and procedures developed by onsite experts. These are not meant for training personnel in experimental operations. ATLAS Users who are Principal Investigators may obtain understanding of certain functionality specific to their proposed experiment. Some of these topics are still in the developing/testing/implementing phases of new hardware/firmware/software for Gammasphere.</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digital_Gammasphere_and_the_SBX_Upgrade&diff=2409 Digital Gammasphere and the SBX Upgrade 2021-10-05T14:30:15Z <p>Copp: </p> <hr /> <div>== Gammasphere Setup in Area 4 ==<br /> <br /> The panoramic image of Gammasphere is interactive. Click on text to go to the link.<br /> <br /> &lt;imagemap&gt;<br /> Image:AREA4 Panorama Text.jpg|frame|center|alt=Test Image Map<br /> rect 180 10 360 66 [[LN system]]<br /> rect 410 200 650 260 [[Gammasphere Detectors]]<br /> rect 110 315 245 375 [[DAQ system]]<br /> &lt;/imagemap&gt;<br /> <br /> As of September, 2021, two major milestones have been accomplished for the Gammashpere Upgrade:<br /> # Odd GS 81-109 have [[The Slope Box Extension]] upgrade equipped, allowing VXI 5 to be taken offline.<br /> # A passive Collector Box is in use with a new Router Cable Plant, allowing one VME crate (containing three IOCs) to be removed from the shack.<br /> <br /> == [[User Guides for Experiments]] ==<br /> The ''User Guides for Experiments'' contain brief walkthroughs that are used for EVERY experiment with Digital Gammashpere. It outlines the directory structure, start/stop data collection runs, merging and sorting data, calibrating the HPGe detectors, etc. These are meant for all ATLAS Users who take shifts for experiments.<br /> <br /> == [[Advanced User Guides]] ==<br /> The ''Advanced User Guides'' contain more detailed guides on how to setup an experiment for Digital Gammasphere. This is intended for frequent/returning users, ANL postdocs, and graduate students on extended visits who assist in maintaining and operating Gammasphere. These guides cover more advanced topics for ATLAS Users who have experience running experiments and desire a deeper understanding of Gammasphere's systems and supporting software/firmware/devices.<br /> <br /> == [[Expert Documentation]] ==<br /> The ''Expert Documentation'' section contains downloads of highly detailed documentation and procedures developed by onsite experts. These are not meant for training personnel in experimental operations. ATLAS Users who are Principal Investigators may obtain understanding of certain functionality specific to their proposed experiment. Some of these topics are still in the developing/testing/implementing phases of new hardware/firmware/software for Gammasphere.</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Experts&diff=2408 ANL Digitizer Firmware for Experts 2021-10-05T14:26:51Z <p>Copp: </p> <hr /> <div>For a download copy of ''ANL Digitizer Firmware for Experts'' see [[firmware documentation]].<br /> <br /> == Details of Each Digitizer Channel ==<br /> <br /> <br /> ''Go back to [[Advanced User Guides]]''<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Experts&diff=2407 ANL Digitizer Firmware for Experts 2021-10-05T14:25:15Z <p>Copp: </p> <hr /> <div>For a download copy of ''ANL Digitizer Firmware for Experts'' see [[firmware documentation]].<br /> <br /> == Details of Each Digitizer Channel ==<br /> <br /> <br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Trigger_and_Digitizer_Setup&diff=2406 Trigger and Digitizer Setup 2021-10-05T14:24:06Z <p>Copp: </p> <hr /> <div>Triggers and digitizers<br /> <br /> Digital Gammasphere uses the same trigger and digitizer modules that Gretina does, but the firmware is completely different.<br /> <br /> == Setting up Triggers in Digital Gammasphere ==<br /> <br /> The general rule for setting up triggering in Digital Gammasphere (and DFMA, and GRETINA) is that when initializing, you have to work your way down from the Master Trigger to the digitizer to lock timestamps, BUT THEN you must WORK YOUR WAY BACK UP to get triggers working. This &quot;working your way back up&quot; occurs in the following steps:<br /> <br /> &lt;OL&gt;<br /> &lt;li&gt;Set up digitizers to transmit actual discriminator data to the Routers.&lt;/li&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;This should happen by default. Common problems are accidentally disabling the SERDES or setting the bit that sends SYNC patterns instead of real data.&lt;/li&gt;<br /> &lt;/ul&gt;&lt;/li&gt;<br /> &lt;li&gt;Set up the digitizers to assert the discriminator bit for an appropriate time (e.g. 100ns).&lt;/li&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;This number is set channel-by-channel in every digitizer. A script is recommended.&lt;/li&gt;<br /> &lt;/ul&gt;&lt;/li&gt;<br /> &lt;li&gt;Verify that the Routers lock onto the data from all digitizers. Use the counters of the Router to insure that no channel is dropping in and out of lock.&lt;/li&gt;<br /> &lt;li&gt;Ignore the X-plane and Y-plane map registers. These are used in DFMA only.&lt;/li&gt;<br /> &lt;li&gt;Load the CLEAN_DIRTY_CONTROL register of each Router (address 0x8CC) with the appropriate mapping. The Router will report two sums to the Master called the 'X' sum and the 'Y' sum. The CLEAN_DIRTY_CONTROL register selects which sum reports which condition. Bits 7:4 control the 'Y' sum and bits 3:0 control the 'X' sum. The allowable selections are<br /> &lt;ul&gt;<br /> &lt;li&gt;0001 to send the 'clean' sum&lt;/li&gt;<br /> &lt;li&gt;0010 to send the 'dirty' sum&lt;/li&gt;<br /> &lt;li&gt;0100 to send the 'module' sum&lt;/li&gt;<br /> &lt;/ul&gt;&lt;/li&gt;<br /> &lt;li&gt;Then load each Router's TSCATTER_DELAY register (address 0x08C8) with the time after the Ge hit during which the corresponding BGO hit can mark the Ge hit as 'dirty' - that is, the Scattering Time.&lt;/li&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;A value of 30 (or 600ns) is typical. Each count is 20ns.&lt;/li&gt;<br /> &lt;/ul&gt;&lt;/li&gt;<br /> &lt;li&gt;You may use the Channel FIFOs of the Router to look at the actual data coming from each digitizer. You should expect to see the 10 digitizer bits in bits 9:0.&lt;/li&gt;<br /> &lt;li&gt;You may use Monitor FIFO 4 of the Router to look at the actual data being sent from the Router to the Master. You should expect to see the 'X' sum &lt;/li&gt;<br /> &lt;li&gt;Repeat all steps above for every Router in the system.&lt;/li&gt;<br /> &lt;li&gt;Now proceed to setting up the Master Trigger. First verify using the channel FIFOs that the Master is getting the data from the Routers.&lt;/li&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;A common error is to forget to turn off the SYNC bit in the LINK_LRU_CTRL register of the Router, so that the data isn't actually sent to the Master.&lt;/li&gt;<br /> &lt;/ul&gt;&lt;/li&gt;<br /> &lt;li&gt;Next, set the multiplicity thresholds for the 'X' and 'Y' sums within the Master Trigger.&lt;/li&gt;<br /> &lt;li&gt;Then enable the appropriate trigger algorithms in the Master Trigger by setting bits in the Trigger Mask register.&lt;/li&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;Enabling both the SumX and SumY triggers at the same time has the effect of an OR; if either sum is satisfied a trigger occurs.&lt;/li&gt;<br /> &lt;li&gt;If both trigger types are enabled and both sums are satisfied two triggers are issued, but since they have the sime timestamp it is highly likely that both will select the same event.&lt;/li&gt;<br /> &lt;/ul&gt;&lt;/li&gt;<br /> &lt;/ol&gt;<br /> <br /> == Setting up Triggers in DFMA ==<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Follow the same outline as above, but at step (4) you must load the X-plane and Y-plane mapping registers.&lt;/li&gt;<br /> &lt;li&gt;At step (5) you must load CLEAN_DIRTY_CONTROL register with zero.&lt;/li&gt;<br /> &lt;li&gt;Step (6) is skipped as this value only applies to DGS.&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Firmware_documentation&diff=2405 Firmware documentation 2021-10-05T14:23:31Z <p>Copp: </p> <hr /> <div>==firmware documentation==<br /> <br /> &quot;user manual&quot; type documentation is provided here. Newer versions may be present on the DGS Subversion repository as updating of this page is a manual process.<br /> <br /> * [[file:DGS_trigger_system_firmware_user_guide.pdf]] was uploaded by JTA on 20180501.<br /> <br /> * [[file:MYRIAD_Module_Specification.pdf]] was uploaded by JTA on 20180501.<br /> <br /> * [[file:ANL_Firmware_for_LBL_Digitizer.pdf]] was uploaded by JTA on 20180501.<br /> <br /> * [[file:20160418_trig_command_link.pdf]] was uploaded by JTA on 20180501.<br /> <br /> * [[file:CPLD_sum_logic.pdf]] was uploaded by JTA on 20180501.<br /> <br /> * [[file:Interfacing_Digital_Gammasphere_with_other_detectors_and_systems.pdf]] was uploaded by JTA on 20180501.<br /> <br /> * [[file:TripletPulseNotesTake2.pdf]] was uploaded by JTA on 20180501. This document demonstrates using the Digitizer Tester to show the effects of integration time and readout length settings on complex waveforms.<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digitizer_Channel_Design_Overview&diff=2404 Digitizer Channel Design Overview 2021-10-05T14:22:11Z <p>Copp: </p> <hr /> <div>== Channel Design Overview ==<br /> The 10 channels of the firmware are implemented as continuously running data pipelines. Data enters the pipeline every tick of the clock from the ADC, proceeds through the pipeline and eventually falls off the back end. If conditions are satisfied data samples at the back end are copied into a buffer known as the Channel FIFO. <br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time. <br /> <br /> Other delay buffers in the pipeline provide delays for calculation of discriminator functions. When a discriminator hit occurs, various time values and data sums are stored as a header. Headers are stored in an Event Header FIFO that holds the headers so long as the associated waveform data is still in pipeline.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> === Channel Interactions ===<br /> When an event is selected for readout, the header from the Event Header FIFO is combined with the matching set of ADC data samples from the Channel FIFO, and this package of data is sent to the board-wide Accepted Event FIFO that services all 10 channels. The Accepted Event FIFO is drained by a state machine that copies the data to the FIFO memory external to the FPGA unless the external FIFO cannot be written to because it is too full; in that case the data is lost and counted as a dropped event. Because there are 10 Channel FIFOs that fill simultaneously from all 10 channels but only one Accepted Event FIFO, large event sizes combined with sufficient rate may result in dropped events because the channels block each other from access to the Accepted Event FIFO.<br /> <br /> == Channel Pipeline Structure ==<br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information. This is all read out in the header of the data as explained in the next section.<br /> <br /> Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Analysis_codes&diff=2403 Analysis codes 2021-10-05T14:21:21Z <p>Copp: </p> <hr /> <div>== Typical run procedure ==<br /> <br /> Traditionally you will have a directory structure as<br /> <br /> data/ <br /> GEBSort/ <br /> LOG_FILES/ <br /> Merged/<br /> ROOT_FILES/<br /> <br /> You can make this directory structure in two ways:<br /> <br /> Option1 (preferred):<br /> <br /> cd to disk you want to use<br /> tar -zxvf ~dgs/dgs_template.tgz<br /> mv template gsfmannn<br /> cd gsfmannn<br /> <br /> where nnn is the run number.<br /> You now have a directory with all you should need. <br /> To make sure things are up to date, you should<br /> <br /> (cd GEBSort; git pull)<br /> (cd GEBSort; make -B)<br /> (cd trackMain; git pull)<br /> (cd trackMain; make -B)<br /> (cd gtreceiver; git pull)<br /> (cd gtreceiver; make -B)<br /> <br /> Option2 (manual):<br /> <br /> you can checkout the software as<br /> <br /> git clone https://gitlab.phy.anl.gov/tlauritsen/trackMain.git <br /> (cd trackMain; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/GEBSort.git <br /> (cd GEBSort; make -B)<br /> git clone https://gitlab.phy.anl.gov/tlauritsen/gtreceiver.git <br /> (cd gtreceiver; make -B)<br /> <br /> Where, of course, for DGS you do not need the tracking part. It is only shown for completeness<br /> <br /> = Acquire and sort data =<br /> <br /> To acquire the data, cd to the 'data' directory.<br /> You start and stop the runs as:<br /> <br /> start_run.sh 123<br /> stop_run.sh<br /> <br /> To merge the data from a run, in the same directory, type<br /> <br /> gebmerge.sh 123<br /> <br /> That will take the run 123 files in the data directory and make a merged file in the <br /> Merged directory and the log file in the LOG_FILES directory<br /> <br /> Before the sort, you should look at the GEBSort.chat file. Lines you may need to change are<br /> <br /> bin_none<br /> bin_dgs<br /> beta 0.0<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> The cal files are the calibration files. See below for how to generate them.<br /> <br /> To sort the data, cd to the GEBSort directory and<br /> <br /> gebsort.sh 123<br /> <br /> The root file will be placed in the ROOT_FILES directory as run123.root<br /> To look at the root file, you would do<br /> <br /> rootn.exe<br /> dload(&quot;../ROOT_FILES/run123.root&quot;)<br /> ...display...<br /> <br /> ---------------------------------------------------<br /> <br /> == Calibrations for bin_dgs in GEBSort_nogeb ==<br /> <br /> GEBSort_nogeb is the program that can analyze data from DGS, DFMA and GRETINA.<br /> This is how you set up the code for DGS use:<br /> <br /> for efficiency, make sure only bin_dgs<br /> is enabled in the GEBSort chat file<br /> <br /> To produce the PZ spectra and 2D [sum2-sum1] vs [sum1] matrices needed to determine the PZ fudge factor (FF)<br /> you must enable <br /> <br /> #define ALL2DS 1<br /> <br /> in bin_dgs.c and recompile . We do not always want these spectra as they take up a lot of space, but for now we need them<br /> <br /> You now specify the PZ and ecal files in the GEBSort.chat file with these lines:<br /> <br /> enabled &quot;1-110&quot;<br /> dgs_MM 350<br /> dgs_PZ dgs_pz.cal<br /> dgs_ecal dgs_ehi.cal<br /> <br /> Before you start sorting data, you need to check that the map.dat file is up to date and reflects the array as it is configured.<br /> <br /> For DGS data, enable bin_dgs in the GEBSort.chat file. <br /> To find the PZ values to use,<br /> sort some data from a 207Bi source. Then extract the pz spectra<br /> in .spe format with the get_pz.cc script<br /> <br /> GEBSort_nogeb ....<br /> rootn.exe<br /> dload(&quot;bi.root&quot;)<br /> .x get_pz.cc<br /> <br /> Now run (you may have to compile):<br /> <br /> dgs_pz 350 141 dgs_pz.cal 1.003<br /> <br /> where 350 141 are the M and K values you find in the runxx.save or runxx.info file. Specify the values in 10 nsec units. In this case I saw these lines in the run_xxx.save or run_xxx.info file:<br /> <br /> GLBL:DIG:d_window 0.06 <br /> GLBL:DIG:k_window 0.20 <br /> GLBL:DIG:m_window 3.50<br /> GLBL:DIG:k0_window 0.80<br /> GLBL:DIG:d3_window 0.20<br /> GLBL:DIG:raw_data_window 0.32<br /> ... etc<br /> <br /> For the K value: sum up all the K and D values! In this case: 0.06+0.20+0.80+0.20 = 1.26 us or 126 in 10 nsec units. <br /> Notice that what is considered the 'K value' also includes the D values (per SZ 6/25/18) as well as a D2 which is fixed at 0.15 (per JTA 6/26/18) and not in the listing above because the user cannot control it. Thus, in total, K in this example is 1.41 us or 141 in 10 ns units. The M value is 3.50 us or 350 in 10 nsec units. The 1.003 is a modification factor that needs to be determined by looking at energy vs baseline spectra.<br /> <br /> Only the GLOBAL m, k and d values matter. Thus, just look at <br /> the GLBL: lines in the listing. THIS NEEDS TO BE CONFIRMED.<br /> <br /> Do not execute the caput commands in the .save file. For the<br /> purpose here, the lines are just information.<br /> <br /> you already specified the M value in GEBSort.chat<br /> <br /> After you executed dgs_pz, a d_pz.cmd file was generated. Use that cmd file in gf3 to check the pz spectra. Some might be really bad and dgs_pz might not have been able to find a good PZ value. If that is the case, to get around this problem, you may set the PZ for these detectors to the average value of the ones that had good PZ spectra. You would simply edit the dgs_pz.cal file.<br /> <br /> Now, after the PZ calibration file is generated, <br /> <br /> run GEBSort again<br /> <br /> When you resort, the PZ values in dgs_pz.cal are read in and used.<br /> Extract the new clean, uncalibrated, ehi spectra as <br /> <br /> .x get_eraw.cc<br /> <br /> and run the calibration program (you may have to compile)<br /> <br /> dgs_ecal dgs_ehi.cal 207Bi 600 1.0<br /> or<br /> dgs_ecal2 dgs_ehi.cal 207Bi 600 1.0<br /> <br /> you can also use &quot;88Y&quot;, &quot;60Co&quot; for the source. The calibration in this case will be 1.0keV/ch (last argument).<br /> The last parameter specifies the lowest channel the program will search for peaks in to avoid any noise at low energies.<br /> dgs_ecal2 has been developed lately and may be better at handling difficult peaks. Feel fre to try this new version.<br /> <br /> Next when you run GEBSort_nogeb, both the new PZ values in dgs_pz.cal and the gain and offset values in dgs_ehi.cal are read in and used.<br /> Take a good look at the spectra. Sometimes the dgs_pz and dgs_ecal programs can be fooled by noise or strange features in the spectra, so a few PZ and ecal parameters might have to be specified by hand.<br /> <br /> To extract the calibrated spectra<br /> <br /> .x get_ecln.cc<br /> <br /> <br /> '''The energy processing in bin_dgs follows algorithms that were developed by Shoufei Zhu.'''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=IOC_Code_Design&diff=2402 IOC Code Design 2021-10-05T14:20:23Z <p>Copp: </p> <hr /> <div>== Intro ==<br /> When an IOC (Input/Output Controller) has a pile of buffers from a digitizer or trigger module, each is pointed to by a '''pointer''' in one of three VxWorks queues:<br /> * qFree<br /> * qWritten<br /> * qSender<br /> The queues are lists of '''pointers''' that are used by the state machines inLoop, outLoop, and minisender to interact with the buffers. Each machine takes a '''pointer''' from a queue (if not empty) and uses the '''pointer''' to move data in/out of a buffer. When a machine is finished using the pointer to work with the buffer, the machine ''moves only the pointer'' from one queue to another. The state machines do not ever copy buffers.<br /> === State Machines ===<br /> # inLoop: Takes a pointer from qFree, fills the buffer pointed to with VME data, then moves the pointer to qWritten.<br /> # outLoop: Takes the pointer from qWritten, checks the data for sanity, and (if ok) moves the pointer to qSender.<br /> # minisender: Waits for gtReceiver to ask for data. When this occurs, minisender takes a pointer from qSender, formats the buffer into packets, then sends it to gtReceiver. The pointer is returned to qFree when finished.<br /> === Flow Control Connections and Error Handling ===<br /> Flow control is accomplished by modulating how inLoop fills buffers<br /> ===== inLoop: =====<br /> Every time inLoop checks the digitizer, it looks at all the flags associated with the board-wide FIFO and reads the FIFO depth from the firmware.<br /> * Will pause scanning for a variable time if the number of buffers in qFree &lt; 10. The delay time is linearly proportional to the number of free buffers.<br /> * Does not enforce any kind of flow control. ''Throttle'' should be used to ensure no events are needlessly dropped if the FIFO becomes too full, and inLoop must reset the FIFO to resynchronize to the event boundaries in the data.<br /> * Requires that the digitizer firmware implements an event-bounded FIFO depth count (for versions newer than ~2019).<br /> ===== outLoop: =====<br /> Checks buffers filled by inLoop for structure errors (does not start with 0xAAAAAAAA, length errors, timestamp of current event is later than timestamp of last event). There is a compile-time option as to whether or not outLoop will try to realign after a length error before continuing scanning, or just exit checking after the first error. These errors are counted, but they do not stop data from being passed from qWritten to qSender. <br /> * Has no flow control connections.<br /> * The support function ''CheckAndMoveBuffers'' will disable the transfer of buffers from qWritten to qSender if a software error results in no free buffers.<br /> * In this state, prevents queue overrun by immediately recycling from qWritten back to qFree, resulting in loss of data in qWritten.<br /> ===== minisender: =====<br /> Constantly polls for data request packets from gtReceiver. A zero length packet from gtReceiver is not considered an error and minisender will just retry continuously.<br /> * Does not participate and does not respond to flow control.<br /> === Interface between State Machines and the control system (EPICS) ===<br /> ===== inLoop: =====<br /> inLoop monitors and responds to the PVs '''Online_CS_StartStop, DAQBx_1_CS_Ena, DAQBx_2_CS_Ena, DAQx_3_CS_Ena, DAQBx_4_CS_Ena'''. It ''asserts data to'' the PVs '''VMEx:MDIG1_CV_Running''', '''DAQCx_CV_InLoop1''', and '''DAQCx_CV_InLoop2'''.<br /> # '''VMEx:MDIG1_CV_Running''' is an internal communication PV between inLoop and outLoop. If set, outLoop understands that inLoop is running.<br /> # '''DAQCx_CV_InLoop1''' provides inLoop's measurement of the total Mbytes/sec it is transferring, for monitoring.<br /> # '''DAQCx_CV_InLoop2''' provides inLoop's measurement of the number of informational &quot;type F&quot; headers per second it is generating.<br /> ===== outLoop: =====<br /> outLoop monitors and responds to the PVs '''Online_CS_SaveData, Online_CS_StartStop, VMEx:MDIG1_CV_Running, DAQCx_CS_TraceBd, DAQCx_CS_TraceChan, DAQCx_CS_TraceHorns'''. It ''asserts data to'' a large number of PVs<br /> # '''DAQCV_CV_BuffersAvail''' and '''DAQCx_CV_NumSendBuffers''' are the buffer counts of qFree and qSender.<br /> # '''DAQCx_CV_OutLoop1,2,3,4''' are the number of lost buffers per digitizer.<br /> # '''DAQCx_OL_DataRate0,1,2,3''' are the read rates in kBytes/sec per digitizer.<br /> # '''DAQCx_OL_Data0,1,2,3''' are the total data amounts in Mbytes per digitizer.<br /> # '''DAQCV_OL_NumxxBuffers report the number of buffer counts (xx = Written, xx = Lost).<br /> # '''DAQCx_OL_BufLostPercent''' is what you think it is.<br /> # '''DAQCx_CV_SendRate''' is the sender data rate in kbytes/sec.<br /> # '''DAQCx_CV_TraceLen''' is the length of the diagnostic trace sent.<br /> ===== minisender: =====<br /> minisender monitors and responds to the PVs '''Online_CS_StartStop''' and '''Online_CS_SaveData'''. It does not assert any monitoring or statistics data to PVs, as the load from outLoop covers everything.<br /> <br /> [[File:IOC State Diagram for inLoop.jpg]]<br /> <br /> == Digitizer FIFO and Throttle ==<br /> There are two FIFO depth counters in the digitizer. The &quot;live depth&quot; contains the actual exact count of how many words are in the FIFO. The &quot;event bound depth&quot; updates only when each full accepted event has been fully transferred to the FIFOs, so it lags behind the &quot;live depth&quot; by some fraction of an event at all times. inLoop uses the &quot;event bound depth&quot; when reading out the digitizer so that every buffer read by inLoop is guaranteed to always contain only full and complete events. This eliminates any need to waste CPU cycles trying to stitch together two parts of an event from different buffers.<br /> The digitizer can assert a &quot;throttle request&quot; bit to the trigger based upon any of the FIFO chip hardware flags or the programmable flag based upon the &quot;live depth&quot; counter. The &quot;throttle request&quot; stays on for as long as the condition persists.<br /> <br /> [[File:Digitizer FIFO and Throttle.jpg]]<br /> <br /> The &quot;Digitizer FIFO and Throttle&quot; picture shows the board-wide FIFO buffer of the digitizer module and its relationship to the firmware. This piece of the firmware is global across all 10 channels. The readout machine shoves data into the FIFO (a separate pair of 16-bit wide chips outside the FPGA) whenever data from any channel is available. Inside all the channel data is 16 bits, but the readout machine takes pairs of words and writes them simultaneously into both FIFO chips to make the 32-bit words that the IOC reads out. <br /> <br /> There is an ‘emergency stop’ built into the firmware that monitors the almost full flag bit of the FIFO. Assuming no shorted or open solder joints in the board, and assuming the firmware is working properly, this ensures that the FIFO can never actually go full. However, the almost full flag from the FIFO chips is at a fixed boundary that has no relationship to event boundaries, so letting the FIFO get to almost full is bad in that there will be a partial event at the end. If this occurs the digitizer must be reset. inLoop looks for this condition and should respond to it by issuing a Type F header with a subtype of 0xF, then automatically resetting the digitizer – however, there may be a one-line bug here in the IOC code that uses full, not almost full. This automatic reset will cause some data loss, but the digitizer will resynchonize.<br /> == Throttle within the Trigger ==<br /> Every digitizer has one throttle bit it can assert to the router trigger, as each digitizer has only one board-wide FIFO. This can be set on a digitizer by digitizer basis using the x/16ths FIFO fullness selection to balance throttling between busy and not-busy digitizers.<br /> <br /> Each router trigger has one throttle request bit it can assert to the master trigger. The router throttle request is the OR of all the digitizer throttle requests after applying assertion time filtering. Assertion time filtering is controlled by registers in each router trigger; the value defines the minimum number of 20.48usec periods that a digitizer’s throttle request must be continuously asserted before the router will deign to pass it on to the master trigger. The time filter value is global across all channels of the router.<br /> <br /> The purpose of assertion time filtering is to prevent over-throttling of triggers from digitizers that are only in the throttle request state for very short times. Masked links cannot create throttle requests. The router trigger takes the OR of all filtered throttle requests. If the OR is ‘1’, then the router will assert a throttle request to the master trigger for a minimum time defined by a 2nd register.<br /> [[File:Trigger Throttle.jpg]]<br /> <br /> The master trigger takes the OR of all throttle requests from the router triggers. This OR is a potential source of trigger veto but must be explicitly enabled by the end user. Inside the master trigger there is AND-OR logic for trigger veto that selectively enables which potential vetoes are allowed to make a veto (AND). The master trigger will not issue triggers if any of the allowed veto types occurs (OR), but the triggers are still calculated irrespective of veto. In the veto state all trigger types are blocked, there is no selective veto per trigger type.<br /> <br /> The veto state lasts for as long as the OR of all enabled trigger vetoes is present, there is no minimum veto time. The master trigger’s diagnostic counters count both triggers that were issued and triggers that could have been issued, allowing estimation of the live time percentage by the ratio of the issuance rate divided by the calculated rate per trigger type.<br /> ==== Throttle: Putting it all Together ====<br /> Initially the FIFO fullness threshold for assertion of the digitizer throttle request should be based upon the incoming data rate to the digitizer’s board-wide FIFO (event size per channel multiplied by event rate per channel multiplied by # of active channels) relative to the readout rate (assume 10Mbytes/sec divided by the number of digitizers in the crate). If the readout rate is sufficient, set the throttle threshold at 15/16th of the FIFO depth. But if the incoming rate exceeds the readout rate, the throttle threshold should be set at the depth of FIFO that the readout rate can support steady-state. This latter case is where the throttle is important.<br /> <br /> With the throttle threshold appropriately set the throttle assertion time from a given digitizer can be estimated to be the time it takes to read out all the other digitizers in the crate. The router trigger throttle filtering time should then be set to about half this time so that the router trigger only passes “real” throttle requests and not transient requests on to the master trigger. The minimum router throttle assertion time to the master can typically be short as the router throttle assertion time should be determined mostly by digitizer settings.<br /> <br /> Lastly, make certain that the master trigger is set to use the collected throttle request as a source of trigger veto. The system should then run smoothly.<br /> <br /> If the system runs in fits and starts, or seems to be over-throttled, measurements with an oscilloscope can be taken using the NIM outputs of the trigger modules. NIM OUT 2 of any router trigger can be set to drive a copy of the time-filtered throttle request from any of the digitizers by use of a control register, allowing the activity from each digitizer to be examined. At the same time NIM_OUT1 can be configured to pulse any time a trigger accept occurs to verify that the master trigger is responding to the throttle.<br /> <br /> The trigger modules implement diagnostic FIFOs in addition to the data FIFO that has TDC information. With appropriate software effort dumps of these diagnostic FIFOs can provide additional information. The trigger implements sixteen diagnostic FIFOs named CHAN_FIFO1 through CHAN_FIFO8, plus a second set MON_FIFO1 through MON_FIFO8. MON_FIFO7 is the TDC data FIFO. “CHAN” FIFOs monitor the individual SerDes links; “MON” FIFOs monitor board-wide actions. In the master trigger, MON_FIFO3 records a short record consisting of the bit-map of which router triggers are asserting throttle request and the current timestamp every time the bit-map of router throttle requests changes. The diagnostic FIFOs other than MON_FIFO7 are short, containing only 256 words each, but dumps of MON_FIFO3 can be used to diagnose whether throttle assertion times are rational from router to router. MON_FIFO3 has many other modes that alternatively monitor other trigger features, so proper setup before reading this FIFO is required.<br /> == Software Connections to the EPICS Control Code ==<br /> # The readout machines inLoop.st, outLoop.st and MiniSender.st are all saved in the same source folder as all the rest of the DGS EPICS code is found: /global/devel/gretTop/9-22/dgsDriver/dgsDriverApp/src.<br /> # The .st files have a set of support code files : inLoopSupport.c, outLoopSupport.c, SendReceiveSupport.c.<br /> # There are a set of more general support files as well: profile.c (code execution profiling), QueueManagement.c (VxWorks queue routines), readDigFIFO.c (FIFO reader specific to digitizers) and readTrigFIFO.c (FIFO reader specific to triggers).<br /> # The files devGdata.c and devGVME.c are the lowest-level data structure and VME read/write routines used by both the readout software and the EPICS software.<br /> # there are two added .h files DGS_DEFS.h and DBG_PRINT_CONTROL.h whose #defined constants are used in the readout code.<br /> # All files beginning with asyn... or drvAsyn... are the EPICS control and monitoring software that connect PVs to registers, but these do not directly affect anything in the readout code and the readout code does not directly affect anything in the control/monitoring code. Were it not for shared low-level VME access in devGdata.c and devGVME.c, and the specifically mentioned PV dependencies of the state machines listed earlier, readout code is effectively independent of control/monitoring code.<br /> ==== Some Things Similar to GammaWare ====<br /> # File DGS_DEFS.h defines a C data structure “daqBoard” that contains a set of information about each board found in the VME crate. <br /> # There is an array struct daqBoard daqBoards[GVME_MAX_CARDS] that creates an array of these data structures, so there’s one “daqBoard” data structure per board in the crate.<br /> # This structure is similar in some respects to the Board[crate][slot] 2-d array of structures of GammaWare, although the underlying data structure here in the IOC is simpler than the one in GammaWare. Both enumerate all the registers in the board and provide some pointers such as the pointer to the FIFO data, so they have some common concepts.<br /> == Brief Comparison of EPICS Code: DGS IOC vs. SBX Pickoff ==<br /> # The two EPICS implementations are seemingly much more different than they are alike, but that is driven by a PV database format design decision rather than by actual hardware/firmware differences.<br /> # The DGS implementation for something you read will have a line of the form field(INP,&quot;@asynMask($(PORT),0,0xaaaa2000,1)reg_board_id&quot;) to read a whole register, or field(INP,&quot;@asynMask($(PORT),0,0xaaaa1010,1)reg_board_id&quot;) for a PV that reads some set of bits within a register. <br /> # The SBX implementation for those same things will read field(INP, &quot;#B0 C0x9D00 N29 A0 F0 @&quot;) for a whole register, or field(INP, &quot;#B0 C0 N28 A0x0300 F8 @&quot;) for something that reads a group of bits. These achieve the same thing by different means. In the DGS version, the string asynMask($(PORT),0,0xaaaa2000,1)reg_board_id is parsed by C code that then does a search for reg_board_id in a list of register “parameters” stored in EPICS, and the coding 0xaaaa2000 means perform bit-group extraction (aaaa) of a field 32 bits long (20, it’s hex) starting at bit 0 (00). In the SBX version, the N29 A0 F0 part of the INP string means “register at address 29 (N29), use all bits (A0), don’t shift (F0).<br /> # Both formats are extractable from an Excel spreadsheet describing the registers as implemented by the firmware, because in the end all that’s happening is that there’s a “field” that has a name, an address, a starting bit and a number of contiguous bits that the “field” represents.<br /> # the latest version of the Excel spreadsheet Visual Basic for Applications code written this year uses formatting templates to extract out that same data in whatever text-substitution on a line-by-line basis you want, so it will work for both schemes.<br /> A note from John Anderson: &quot;I personally like the SBX model better as a hardware guy as the DGS model from Tim Madden seems to have a couple layers of excess indirection for no functional gain. However, after analyzing how it works, the conclusion is that there is no gain to be realized from changing it, but there’s risk of breaking stuff, so the risk/reward analysis conclusion is “don’t touch it”.&quot;<br /> === Compiling the Code (Skip here for commands to compile IOC code) ===<br /> # Log into con6 as dgs<br /> # cd /global/devel/gretTop/9-22/dgsIoc<br /> # make -B<br /> # cd ../dgsDrivers<br /> # make -B<br /> # cd ../dgsIoc<br /> # make<br /> # Log out of con6<br /> # Log into dgs1 as dgs<br /> # cd /global/devel/gretTop/9-22/dgsIoc<br /> # ./Copy_from_sandbox.sh (This last command copies the munch file from con6 to dgs1, making it available to the MVME5500s.)<br /> === Code-Generated Headers ===<br /> inLoop generates special headers in software that it injects into the data stream to provide useful information. All headers have a 4-bit header type code that has values from 0 to F (hexadecimal). inLoop-generated headers by fiat all have a type of 0xF, so are called “type F” headers. Furthering this definition, when readout of FIFOs from trigger modules is fully deployed the data from trigger modules will have type 0xE, or “type E” headers.<br /> <br /> Digitizer firmware used from 2017 to 2021 has header types of 0x5 (LED) and 0x6 (CFD). Digitizer firmware released September 2021 uses type 0x7 (LED) and 0x8 (CFD).<br /> <br /> All type 0xF headers have the same length but use bits 3:0 of word 1 as a header subtype. The subtype says why the header was generated. The GEO ADDR and PACKET DATA fields identify which board caused the type F header, and the timestamp identifies when the type F header was generated. <br /> [[File:InLoop Header.jpg]]<br /> <br /> === Code-Generated Headers for Trigger Modules ===<br /> The master trigger module implements a time-to-digital converter (TDC) that provides a measurement of the delta-T between an external clock source applied to NIM input 2 relative to the clock of the master trigger itself. The TDC is implemented in firmware and is expected to provide ~500ps accuracy. Every time the signal at NIM input 2 has an edge the delta-T between edges is measured, but only those measurements that occur near trigger accepts are saved. The user selects one of the trigger algorithms of the master trigger to be the source of the TDC sampling, and a TDC sample is saved to a FIFO in the master trigger every time the selected algorithm fires. <br /> <br /> The TDC data is provided as a set of data values related to four TDC sub-units that run at four phases of a 250MHz clock. Each phase is offset by ~1ns from the next. Each sub-unit has its own counter value that runs at the 250MHz clock plus a tapped delay line vernier that will record a “thermometer code” value (string of 1s followed by string of 0s) indicative of how far the edge of the input signal propagated down the delay line when the 250MHz clock sampled it. When a reading is taken a pipeline sequence of conversion logic takes the “thermometer code” and determines the numerical index of the delay line tap (0 to 63) that the edge propagated to. This value, plus the 250MHz counter, provides the interpolation data for that sub-unit. For all hits at least two sub-units will record a counter + vernier value and for the majority three sub-units will have valid values depending upon the exact timing of the input signal. To determine the time of the hit, the data from all four sub-units is examined, those not valid are discarded and those remaining are averaged. There are spreadsheets showing how the conversion to one time value is done.<br /> <br /> Data read from the trigger module is only 16 bits wide. Every hit creates an event in the trigger FIFO that is fourteen 16-bit words long. The subroutines of readTrigFIFO.c will reformat that into a type E header of the format shown here.<br /> [[File:Trigger Header Format.jpg|Trigger Header Format]]<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=General_Design_of_the_Firmware&diff=2401 General Design of the Firmware 2021-10-05T14:19:40Z <p>Copp: </p> <hr /> <div>== [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == Event Data Nomenclature ==<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> === Discriminator Modes ===<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> === Pileup and Discriminator Hold-Off ===<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed.<br /> *The ''first'' hit of a pileup train is still called the ''accepted hit'' but all '''subsequent''' hits within a pileup train are called ''extended events''.<br /> <br /> The ''pileup inspection time'' is the minimum separation between ''discriminator hits'' before pileup is declared to exist.<br /> *The firmware can withstand a maximum of 16 events piled up on top of each other before the pileup inspection time of the first event expires. Should this be exceeded the digitizer enters the ''General Error'' state and all data processing within the channel stops until the digitizer is reset.<br /> <br /> Each channel implements a ''discriminator hold-off'' time that is the amount of time after a ''discriminator hit'' that the discriminator is blocked from marking another hit. This is related to the rise time of the signal so that only one ''discriminator hit'' is marked per rise.<br /> *If the user sets the ''discriminator hold-off'' time to a value less than the ''pileup inspection time'', the digitizer will enter the ''Pileup Too Short'' error state and must be manually reset with adjusted parameters.<br /> <br /> === Diagnostic Counters ===<br /> A primary diagnostic by which operation of the firmware may be monitored is by per-channel counters that monitor discriminator hits, accepted hits, accepted events and dropped events. Discriminator setup errors, or analog input issues, often result in no discriminator hits. If pileup rejection is enabled the ratio of accepted hits to discriminator hits provides immediate feedback regarding the percentage of events that are piled up. When using the “TTCL” mode (selection of events by the trigger) the ratio of accepted events to accepted hits may be used to determine if the trigger settings and/or digitizer trigger time windows are set appropriately. Recording any dropped events at all typically indicates that '''the amount of waveform data requested per event is too large for the event rate''' and that the readout of the digitizer over VME can’t keep up with the input data.<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=A_Short_Introduction_to_Data_Acquisition_Hardware&diff=2400 A Short Introduction to Data Acquisition Hardware 2021-10-05T14:18:59Z <p>Copp: </p> <hr /> <div>=== &quot;Master&quot; and &quot;Slave&quot; Digitizers ===<br /> The digitizer modules may be used in pairs where one digitizer is labeled the “master” and the other is labeled the “slave”. In this configuration the two digitizers have ''different versions of firmware''. The “master” digitizer alone connects to the trigger system. A ribbon cable connects the “master” digitizer to the “slave” digitizer. The “slave” digitizer channels are normally configured to use signals from the “master” digitizer as part of the logic determining if discriminators within the “slave” channels will fire or not, or whether events within the “slave” are marked for readout or not.<br /> <br /> === Clocking and Timestamps ===<br /> The ADC chips run at a frequency of 100MHz (100 MSamp/sec). The device may run from its own internal oscillator or may receive a clock from an external trigger system and synchronize to that clock. A clock distribution from the trigger allows many digitizer modules to run synchronous to each other.<br /> <br /> The digitizer module uses a 48-bit timestamp counter run from the 100MHz clock. When connected to the trigger system, the trigger may issue a command to synchronously reset the timestamp in all digitizers. Events read out of the digitizer are tagged with a timestamp for sorting and analysis.<br /> <br /> === Connection to External Trigger System ===<br /> Digitizer modules may connect to a trigger system for synchronization and event selection purposes. A separate cable plant connects digitizer modules to trigger modules; on the digitizer end the cable uses the same RJ45 connector as Ethernet, but the signal levels and usage '''''are not Ethernet'''''. '''Do not connect the digitizer to an Ethernet port, this will damage the digitizer module'''.<br /> <br /> The digitizer can run standalone without being connected to a trigger system. In this configuration every digitizer board has independent and unsynchronized clocks. Timestamps for event sorting are not useful across multiple modules as there is no synchronism, but within one board timestamps are still sensible.<br /> <br /> ''See '''MyRIAD_USER_Manaual''' or '''MyRIAD_Abridged_User_Notes''' in [[Original Content prior to the ''Gammasphere Upgrade Project'']] for detailed information on External Trigger systems''.<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2399 ANL Digitizer Firmware for Advanced Users 2021-10-05T14:18:42Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Advanced_User_Guides&diff=2398 Advanced User Guides 2021-10-05T14:18:19Z <p>Copp: </p> <hr /> <div>== [[DGS Commander EPICS Screens]] ==<br /> The DGS Commander (sometimes referred to as DGS Main Controller) is a GUI (Graphical User Interface) generated by EPICS (Experimental Physics and Industrial Controls System). DGS Main Controller is the Home Screen that provides access to all essential monitors and controls for the Gammasphere array. The [[DGS Commander EPICS Screens]] link has an interactive image map that provides a walkthrough of subsequent screens.<br /> <br /> == [[ANL Digitizer Firmware for Advanced Users]] ==<br /> This section is intended for users of the experiment setups at ATLAS who will be working with the firmware and adjusting parameters; a separate document, ''Waveform Digitizers at the ATLAS experiments'', is available for those interested in a general overview of the digital data acquisition systems without reference to technical details. This advanced guide also glosses over many details of the firmware to present a view sufficient for non-expert users. Experts are referred to the document ''[[ANL Digitizer Firmware for Experts]]'' for details.<br /> <br /> ''Click here for more [[firmware documentation]]''<br /> <br /> == [[triggers and digitizers]] ==<br /> This section presents a brief overview of how to set up the Master Trigger and Router Trigger modules.<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digitizers&diff=2397 Digitizers 2021-10-05T14:17:54Z <p>Copp: </p> <hr /> <div>== Introduction ==<br /> The experiments at Argonne National Laboratory (Gammasphere, FMA, DSSD, HELIOS) have instrumented their detectors with digital data acquisition systems using the digitizer module developed for the GRETINA experiment. Although the hardware is the same the differing architectures of the experiments and different detector structures necessitate completely new and unique firmware in both the digitizer and trigger modules. A generic firmware design from which specific variants for each of the Argonne Tandem Linear Accelerator System (ATLAS) experiments can be derived is described herein. It is our hope that this firmware development, where all channels are independent and equal, may be utilized in other experiments as well. As of 2018, Digital Gammasphere (DGS), Digital FMA (DFMA), HELIOS (Helical Orbit Spectrometer) plus the X-Array all use this firmware.<br /> <br /> The digitizer module design and the original GRETINA firmware developed for it are products of Lawrence Berkeley National Laboratory (LBNL). The trigger module and its firmware are products of Argonne National Laboratory (ANL). We at Argonne thank our LBNL collaborators for sharing the source code and schematics of the digitizer module, both of which were invaluable references in this totally new firmware development.<br /> <br /> Data from the ADCs of the digitizer is signed 14-bit values that arrive at 100MHz (10ns period). Each digitizer module implements ten channels that implement independent input and energy integration blocks. The purpose of the input and energy integration firmware block, implemented as a pipeline, is to receive the data, internally trigger on edges of signals and calculate the energy of the input signal. Following each energy integrator is a pending event queue and event acceptance logic block that places accepted events into channel-specific FIFO buffers. At the back end, a channel readout machine collects all data from the channels and stuffs accepted events into a large external readout FIFO, accessible over the VME backplane.<br /> <br /> Two versions of firmware have been developed, a Master build and a Slave build. These operate identically in virtually all ways save that the Master build directly interfaces to the trigger system and the Slave build receives its clock and control signals from the trigger over a front panel cable driven by the Master. The bulk of this &quot;Beginner Guide&quot; describes the Master design.<br /> <br /> == Hardware Interface Notes ==<br /> While this is a firmware manual, some general reference information regarding how signals are connected to the digitizer is in order. The detector system this firmware was designed for is named Gammasphere. The Gammasphere consists of many (up to 110) individual detector modules. Each of the individual modules contains a central piece of high-purity Germanium (HPGe) surrounded on the sides by six Bismuth Germanate (BGO) shield scintillators and at the back by a 7th BGO ‘backplug’. Each detector module contains its own preamplifier electronics for the HPGe and BGO sections that create electrical signals in response to interactions with gamma-rays. Each detector module also contains a liquid nitrogen dewar with volume (~2L) sufficient to keep the detection elements cold for hours.<br /> <br /> === Interface to [[Gammasphere Detectors]] ===<br /> The signals from detectors are processed through external analog interface modules before connection to the digitizer. In the case of Digital Gammasphere ‘pickoff cards’ differentiate the single-ended input Ge Center signal to remove the long ramp and reset associated with the transistor-reset preamplifiers. As of 2021, the Gammasphere hardware is being upgraded. The original control/monitoring/power system developed in the 1990s, and the ‘pickoff cards’ designed in the early 2000s, plus all cabling are being replaced. [[The Slope Box Extension]] is a new system that provides all the features originally envisioned for the ‘pickoff’ cards that were not implemented in the original design, plus completely replaces the old control/monitoring/power system. As of August 2021, approximately 17% of Gammasphere has been converted to Slope Box Extension hardware. <br /> <br /> Irrespective of old system or new, the signals are all driven differentially into the digitizer with a variable DC offset. The signal applied to all digitizer channels is unipolar with the dominant time constant defined by the RC timing of the channel. The time constant of the pickoff card for the Ge Center channel is nominally 50us; detectors with Slope Box Extension systems have programmable time constants. The BGO and Ge Side signals are natively unipolar as driven by the detector and so are simply amplified and converted to differential; the time constants of the BGO and Ge Side signals are similar to those of the Ge Center channel. Typically the differential signals are offset by approximately 1.5V so that the un-driven signal rests near but not at the one rail of the digitizer module’s input range (i.e. around ADC channel 2000 for Ge Center signals). This allows the maximum dynamic range for the unipolar signals. The fourth signal from each detector is called the BGO pattern. This last signal can be used to monitor the individual BGO tubes that form the BGO sum signal and can also monitor the Ge Center at a different gain for calibration purposes. It also has a mode in which the signal is driven by seven comparators, each with a fixed and binary-weighted analog swing, to provide a mix of tube activity indicator and time-over-threshold energy information from all 7 BGO channels simultaneously. Please refer to [[The Slope Box Extension]] documentation for additional information on how these signals are formed.<br /> <br /> ''For more information on digitizer firmware see [[Advanced User Guides]]''<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=User_Guides_for_Experiments&diff=2396 User Guides for Experiments 2021-10-05T14:17:24Z <p>Copp: </p> <hr /> <div><br /> For directory structure, energy and pole/zero calibration see [[typical DGS run procedures]].<br /> <br /> ==Digital Gammasphere Shift Notes==<br /> This section provides a walkthrough of a typical 8-hour shift using DGS. The main workspace looks like this:<br /> [[File:DGS shift notes1.png|center|DGS main workspace ]]<br /> <br /> === General Things to Watch ===<br /> *Run Control box in DGS Main Controller (top right) must show &quot;Start; Save; Sort&quot; during a run. Otherwise, data is not being recorded.<br /> *TCP/IP rates (center grey boxes) should be changing, and Buffs Avail should be &lt;400 when data is being written to disk.<br /> *VME 01-11 (left white boxes) show values that change in MDIG(n) and SDIG(n) fields. These are Timestamps that should be very close in value when digitizers are all Locked.<br /> *Trigger Rate (bottom right) should be &lt;50 kHz running in &quot;singles&quot; multiplicity (X Threshold = 0). TRIGGER RATE VARIES BY EXPERIMENT DEPENDING ON MULTIPLICITY, BEAM INTENSITY, AND OTHER FACTORS.<br /> <br /> The second desktop in the above image (bottom right button) has several white terminal windows, one for each VME (IOC receiver), plus a terminal window with a dgs@dgs1 prompt for start/stop commands. Each VME terminal should update every 15 seconds showing the data in Mb/sec written to disk.<br /> <br /> === Actions During Shift ===<br /> It is highly recommended to start a new run approximately every hour. If there is an incident that results in corrupt data for that run, less data would be lost.<br /> In /dgsdata directory, stop the current run<br /> ./stop_run.sh<br /> Wait 5-10 sec for all Buffs Avail to display 400 in the Big Summary<br /> ./start_run.sh ###<br /> where ### is the next run number.<br /> <br /> Log in the logbook or elog the stop/start times, current trigger rate, and beam current (or no change in beam current). If you have been advised to check the capacity of the current disk type<br /> df -h<br /> <br /> ==== Check Histograms for Quality Control====<br /> Digital Gammsphere does not display &quot;live&quot; histograms for users. Users are responsible for checking histograms to ensure sensible data is being collected. Data can be merged, sorted, and displayed in ROOT while it is being collected. See [[analysis codes]] for details.<br /> <br /> Contact the person ON CALL if data is nonsensical.<br /> <br /> ==Troubleshooting During Shift==<br /> This section describes the most common issues that can occur during a shift and how to fix it.<br /> <br /> === When VME(s) Crash ===<br /> The first indication of a VME crashing is the TCP/IP rate drops to 0.0 and Buffs Avail continuously fall below 380 without recovering on their own. Stopping the current run and starting a new run before the Buffs Avail reach zero can prevent a crash. If Buffs Avail fall to 0.0, that VME has crashed and needs to be restarted. Check the terminal windows of the IOC receivers and look for an error message (ie something other than Mb/sec written to disk).<br /> <br /> *First, stop the current run. <br /> *Second, attempt to reboot the affected receiver by clicking Terminals in DGS Main Controller, then choose the VME (IOC 1 through 11) to be rebooted, which opens a new terminal window.<br /> <br /> [[File:DGS shift notes2.png|center|DGS Main Controller with Terminals and Scripts buttons highlighted]]<br /> <br /> ''{insert VME 01 terminal window with reboot countdown here}''<br /> <br /> *Third, in the terminal window that opens, hit &quot;return&quot; to get a prompt. Then hit Ctrl+X to see a countdown for the IOC to reboot. <br /> Ctrl+X<br /> Wait for the reboot to finish (takes over 1 min) and ignore any error messages (these are non-fatal warnings). A prompt appears when complete, and the window can be closed. If no auto-boot message appears, or there is no prompt at all, then a hard reboot (power cycling the VME crate) is required to reboot the IOC.<br /> <br /> [[File:DGS shift notes3.png|center|Dropdown list of the Scripts button in DGS Main Controller]]<br /> <br /> *Fourth, click &quot;Scripts&quot; in DGS Main Controller. Run &quot;Lock All Setup&quot; (takes over 1 min) and check the Trigger Summary screen found under &quot;Trigger&quot; in DGS Main Controller. This is also displayed at the bottom of Big Summary and it should look EXACTLY like this:<br /> <br /> [[File:DGS shift notes4.png|center|Trigger Summary window found under &quot;Trigger&quot; in DGS Main Controller]]<br /> <br /> *Fifth, click &quot;Scripts&quot; and run &quot;Digitizer Setup&quot; script (takes over 1 min). This issues a series of commands setting digitizer channel PVs. At this point, Buffs Avail should read 400 again, and a new run can be started. <br /> <br /> === Power Cycling the DAQ ===<br /> If the &quot;soft&quot; reboot was not successful, a hard reboot of the VME crates is necessary, which requires power cycling. If the remote PCU is operational, go to [[[Network Accessible Power Control Units of DGS]].<br /> <br /> If access to Area 4 is necessary, check the monitor above the cage entrance for room status on ARIS 2.0. The Farday cup must be put &quot;IN&quot; if the area is locked, contact the operators (2-4115 from ANL landline) to request assistance. Click here for the procedure to [[Sweep Area 4]].<br /> <br /> Go to the DGS racks (either inside the shack or next to the hemisphere) and cycle the power on the crashed VME crate.<br /> <br /> [[File:DGS shift notes5.png|center|Power switch on VME crate]]<br /> <br /> Turn off the crate and wait 30 sec before turning the power back on. Leave the shack and [[Sweep Area 4]].<br /> <br /> Back in the Data Room, reboot the Trigger IOC. Click &quot;Terminals&quot; in DGS Main Controller and select Trigger IOC. This is like rebooting a VME IOC, a terminal window opens, hit &quot;return&quot; for a prompt, then use Ctrl+X to initiate the auto-reboot countdown<br /> Ctrl+X<br /> This takes over 1 min. As stated above, ignore any error messages, close the window once the prompt reappears. Next run &quot;Lock All Setup&quot;, followed by &quot;Digitizer Setup&quot;. Same as stated above.<br /> <br /> If there is still a problem, contact the person ON CALL for the shift.<br /> <br /> ==Other Guides for New Users==<br /> *[[Digitizer Guide for Beginners]]<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=DGS_Commander_EDM_Screens&diff=2395 DGS Commander EDM Screens 2021-10-05T14:15:44Z <p>Copp: </p> <hr /> <div>This is an interactive image map of the DGS Commander EPICS screens. Click on text (these are buttons on the GUI) to proceed to the next screen. This allows you to explore the entire DAQ system without accidentally changing something during experimental operation.<br /> <br /> &lt;imagemap&gt;<br /> Image:DGSCommander Screen.png|frame|center|alt=Test Image Map<br /> rect 11 96 114 130 [[Run Control Start/Stop]]<br /> rect 14 162 113 196 [[Run Control Save/NoSave]]<br /> rect 139 92 296 129 [[Run Control Trigger]]<br /> rect 139 158 297 190 [[Run Control Digitizers]]<br /> rect 138 217 295 250 [[Run Control Count Rates]]<br /> <br /> rect 319 93 474 128 [[Run Control Global Control]]<br /> rect 317 155 476 190 [[Run Control VME Status]]<br /> rect 318 215 475 250 [[Run Control Live Time Stamps]]<br /> <br /> rect 497 94 656 150 [[Run Control Terminals]]<br /> rect 498 156 657 190 [[Run Control Misc. Controls]]<br /> rect 497 215 657 251 [[Run Control Scripts]]<br /> <br /> rect 673 44 785 75 [[Run Control Aux Main]]<br /> rect 673 88 785 121 [[Run Control VXI Boards]]<br /> rect 673 135 785 167 [[Run Control Ge High Volt.]]<br /> rect 673 183 785 215 [[Run Control Ge CFD]]<br /> rect 673 227 785 261 [[Run Control Side Channel]]<br /> &lt;/imagemap&gt;<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=DAQ_system&diff=2394 DAQ system 2021-10-05T14:15:24Z <p>Copp: </p> <hr /> <div>The DAQ system consists of VME crates, IOC Modules, Digitizers and Trigger Modules. There are two types of Digitizer (Master and Slave) and well as Trigger (Master and Router).<br /> <br /> == [[DGS Commander EPICS Screens]] ==<br /> This section contains an image map of DGS Commander and all subsequent EPICS screens<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=The_Slope_Box&diff=2393 The Slope Box 2021-10-05T14:15:01Z <p>Copp: </p> <hr /> <div>== The Slope Box ==<br /> <br /> The slope box (or ''sloped box'', take your pick) is the interface between the control &amp; monitoring system and the detector. The slope box takes DC power from the VXI system and generates the bias voltage for the Ge detector (typically around 3500V) plus also the lesser bias voltage for the BGO detectors (~750V - 800V). The HV supplies of the slope box are programmable through EPICS. A demand HV value is written to a DAC in the slope box and the HV is a multiple of the DAC voltage. The slope box also has a multiplexed ADC that measures detector temperature, actual HV being applied and values of the various power supplies.<br /> <br /> In the current (as of April 2019) implementation of Gammasphere, the slope box is intimately associated with the VXI modules in the 'shack'. The VXI modules provide DC voltage and a serial interface to the slope box, and a processor board (an IOC, in EPICS parlance) converts changes in control process variables into serial messages to the slope box. These messages include commands to set the DAC or to read out the ADC.<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=The_Slope_Box_Extension&diff=2392 The Slope Box Extension 2021-10-05T14:14:17Z <p>Copp: </p> <hr /> <div>The Slope Box Extension (SBX) unit contains a '''power board''' and '''pickoff card''' along with an optional '''Raspberry Pi''' computer. These electronics replace ALL utility of the VXI system while providing additional functionality previously unavailable. <br /> <br /> The R-Pi contains an EPICS database allowing users to read and write PVs: <br /> *The Slope Box for detector controls and monitoring (HV, Temps, etc.)<br /> *The SBX Pickoff for control of signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.)<br /> <br /> &lt;imagemap&gt;<br /> Image:PickoffControl Screen.png|frame|center|alt=Test Image Map<br /> &lt;/imagemap&gt;<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Gammasphere_Detectors&diff=2391 Gammasphere Detectors 2021-10-05T14:13:54Z <p>Copp: </p> <hr /> <div>This image is interactive. Click text to go to the link.<br /> <br /> &lt;imagemap&gt;<br /> Image:SBX Array.jpg|frame|center|alt=Test Image Map<br /> rect 465 210 675 265 [[The Slope Box]]<br /> rect 80 315 475 365 [[The Slope Box Extension]]<br /> &lt;/imagemap&gt;<br /> <br /> == Gammasphere detectors ==<br /> <br /> The detectors in Gammasphere are high purity germanium detectors sensitive to x- and gamma-rays from a few dozen keV to ~10MeV energy. All Gammasphere detectors are Compton shielded using bismuth germanate (BGO) shields. Six planar BGO detectors form a hexagonal shield array around the HPGe detector sides and a 7th BGO shield behind (at farther radius from the interaction point) is used as a &quot;back plug&quot;. The germanium detector itself is of the coaxial type. Incident gamma-rays typically deposit charge in the germanium that is read out through the center contact.<br /> <br /> Should the gamma-ray scatter within the Ge portion of the detector the scatter will normally be detected by interaction with the BGO shields. Thus we define a 'clean' event as one that excites the Ge but none of the surrounding BGO of a given detector and a 'dirty' event as one in which both the Ge and BGO light up. Within the digitizing data acquisition system, the sum of all 7 BGO signals is applied to one digitizer channel and the Ge center contact is digitized by another channel in the same digitizer. A discriminator threshold is applied to both signals and the Router trigger module looks at the time relationship between Ge discriminator bits and the associated BGO Sum discriminator bits. If the two discriminator bits are close enough in time the event is marked as 'dirty'.<br /> <br /> === Segmented Detectors ===<br /> <br /> Many of the Ge detectors in Gammasphere are segmented. In these the Ge portion of the detector is split in half resulting in three Ge contacts (Center, Side A, Side B). Only one of the side connections is brought out to the digitizers as the charge that would be in the other side is given by subtraction of the measured side from the center contact.<br /> <br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=LN_system&diff=2390 LN system 2021-10-05T14:13:30Z <p>Copp: </p> <hr /> <div>==Access to the LN fill system from outside==<br /> <br /> To access the LN fill EPICS pages from outside, do the following<br /> <br /> * ssh -X username@sonata.phy.anl.gov (or ssh -x gamop@ln2con, where findhose works)<br /> <br /> * ssh -X dgs@dgs1<br /> <br /> * launch the LN EPICS control pages by typing 'lnmain'<br /> <br /> If you do not have an account on sonata, the (green) gateway machine to onenet, you should talk to Ken Teh about getting an account on the machine<br /> <br /> ==the lnfill console window==<br /> <br /> type<br /> <br /> cu -s 9600 -l /dev/ttyS0<br /> <br /> on ln2con<br /> <br /> ==When do I have to reboot the lnfill IOC?==<br /> <br /> When there is a valve overtime, it is necessary to reboot the IOC for the alarm to the dialer to reengage. <br /> <br /> If it is just a temperature alarm, it is not necessary to reboot the IOC<br /> <br /> ==How do I fill one detector remotely?==<br /> <br /> This is typically done if a detector warms up before the next fill or after a problem like a clogged bayonet has been fixed.<br /> <br /> Locate the EPCICS control screen for the detector in question, then<br /> <br /> * open the valve for tank you want to use<br /> * and the associated exhaust valve for the line<br /> * wait for the temperature at the exhaust valve to bottom out (meaning that there is now liquid there)<br /> * put the exhaust valve back into 'auto mode' again<br /> * open the valve to the detecor you want to fill<br /> * wait for the temp at the detector return to bottom out (meaning that there is now liquid there)<br /> * return the detector valve to 'auto mode'<br /> * return the tank valve to 'auto mode'<br /> o [[Analog Gammasphere]]<br /> <br /> ==what do I do about overtimes?==<br /> <br /> * clean bayonet <br /> * check for leaks in line<br /> <br /> when you have solved problem, do a manual fill and don't forget to reboot the IOC<br /> <br /> ==what do I do about undertimes?==<br /> <br /> * fill manually after the tank fill!? Or bad sensor? NOT SURE<br /> * reboot lnfill<br /> <br /> ==case of blown fuse on AB==<br /> <br /> If a number of detectors have overtime in the same manifold, there may be a<br /> blown fuse on an AB module. Look for red 'fuse'. Replace fuse and locate the bad valve.<br /> Then switch to a another fill line and disable the bad valve that caused the short<br /> <br /> ==det no and fill line==<br /> <br /> on ln2con you can say 'findhose' to determine what fill line belongs to the detector that is warming up<br /> <br /> ==How to set the temperature thresholds==<br /> <br /> To see the current temperature and the alarms limits, as gamop on<br /> ln2con, do this (shown for det 107)<br /> <br /> cd /home/gamop/lnfill_logs<br /> <br /> set_hilo_lim 107<br /> MOD107_DV_TEMP.HIHI 91<br /> MOD107_DV_TEMP.HIGH 86<br /> MOD107_DV_TEMP 78.4094<br /> MOD107_DV_TEMP.LOW 66<br /> MOD107_DV_TEMP.LOLO 61<br /> <br /> to change the limits so HIGH is 78+10, LOW is 78-10, HIHI=78+20 and LOLO<br /> is 78-20, type this:<br /> <br /> set_hilo_lim 107 78<br /> Old : MOD107_DV_TEMP.HIHI 91 <br /> New : MOD107_DV_TEMP.HIHI 98 <br /> Old : MOD107_DV_TEMP.HIGH 86 <br /> New : MOD107_DV_TEMP.HIGH 88 <br /> Old : MOD107_DV_TEMP.LOW 66 <br /> New : MOD107_DV_TEMP.LOW 68 <br /> Old : MOD107_DV_TEMP.LOLO 61 <br /> New : MOD107_DV_TEMP.LOLO 58 <br /> <br /> after that you will see:<br /> <br /> set_hilo_lim 107<br /> MOD107_DV_TEMP.HIHI 98<br /> MOD107_DV_TEMP.HIGH 88<br /> MOD107_DV_TEMP 78.2947<br /> MOD107_DV_TEMP.LOW 68<br /> MOD107_DV_TEMP.LOLO 58<br /> <br /> One should set these limits when the detectors are nice and cold.<br /> <br /> ==misc==<br /> <br /> * do not start a full fill of GS from 8pm to midnight while GT is present<br /> * if a detector starts to warm up less that an hour before the next fill, it is best to leave it alone and wait for the fill. That is to avoid fill under-times at the regular fill which will just cause other problems<br /> <br /> ''Go back to [[Digital Gammasphere Upgrade Project]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digital_Gammasphere_Upgrade_Project&diff=2389 Digital Gammasphere Upgrade Project 2021-10-05T14:12:57Z <p>Copp: Created page with &quot;== Gammasphere Setup in Area 4 == As of September, 2021, two major milestones have been accomplished for the Gammashpere Upgrade: # Odd GS 81-109 have The Slope Box Extensio...&quot;</p> <hr /> <div>== Gammasphere Setup in Area 4 ==<br /> As of September, 2021, two major milestones have been accomplished for the Gammashpere Upgrade:<br /> # Odd GS 81-109 have [[The Slope Box Extension]] upgrade equipped, allowing VXI 5 to be taken offline.<br /> # A passive Collector Box is in use with a new Router Cable Plant, allowing one VME crate (containing three IOCs) to be removed from the shack.<br /> <br /> The panoramic image of Gammasphere is interactive. Click on text to go to the link.<br /> <br /> &lt;imagemap&gt;<br /> Image:AREA4 Panorama Text.jpg|frame|center|alt=Test Image Map<br /> rect 180 10 360 66 [[LN system]]<br /> rect 410 200 650 260 [[Gammasphere Detectors]]<br /> rect 110 315 245 375 [[DAQ system]]<br /> &lt;/imagemap&gt;<br /> <br /> == [[User Guides for Experiments]] ==<br /> The ''User Guides for Experiments'' contain brief walkthroughs that are used for EVERY experiment with Digital Gammashpere. It outlines the directory structure, start/stop data collection runs, merging and sorting data, calibrating the HPGe detectors, etc. These are meant for all ATLAS Users who take shifts for experiments.<br /> <br /> == [[Advanced User Guides]] ==<br /> The ''Advanced User Guides'' contain more detailed guides on how to setup an experiment for Digital Gammasphere. This is intended for frequent/returning users, ANL postdocs, and graduate students on extended visits who assist in maintaining and operating Gammasphere. These guides cover more advanced topics for ATLAS Users who have experience running experiments and desire a deeper understanding of Gammasphere's systems and supporting software/firmware/devices.<br /> <br /> == [[Expert Documentation]] ==<br /> The ''Expert Documentation'' section contains downloads of highly detailed documentation and procedures developed by onsite experts. These are not meant for training personnel in experimental operations. ATLAS Users who are Principal Investigators may obtain understanding of certain functionality specific to their proposed experiment. Some of these topics are still in the developing/testing/implementing phases of new hardware/firmware/software for Gammasphere.</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Main_Page&diff=2388 Main Page 2021-10-05T14:12:25Z <p>Copp: </p> <hr /> <div><br /> These are the wiki pages for the Digital and the analog Gammasphere Data Acquisition systems (GS DAQs). Procedures for running the DAQs and the data format will be documented here.<br /> <br /> The GS DAQ serves the Gammasphere detector array (http://www.phy.anl.gov/gammasphere/), located at the ATLAS accelerator (http://www.phy.anl.gov/atlas), home of the CAlifornium Rare Isotope Breeder Upgrade (CARIBU http://www.phy.anl.gov/atlas/caribu/).<br /> <br /> Contact mailto:torben@anl.gov for comments on, and write access to, these wiki pages<br /> <br /> ==[[Digital Gammasphere Upgrade Project]]==<br /> <br /> ==[[Original Content prior to the ''Gammasphere Upgrade Project'']]==<br /> The intro section contains an interactive block diagram of the DGS system prior to the ''2021 Upgrade Project''.<br /> <br /> o [[intro]]<br /> <br /> o [[list of experimental runs/analysis]]<br /> <br /> o [[typical DGS run procedures]]<br /> <br /> o [[analysis codes]]<br /> <br /> o [[some problems and their solutions]]<br /> <br /> o [[Beginner Guide to Digitizer Firmware]]<br /> <br /> o [[computers and networks]]<br /> <br /> o [[receivers/GEBMerge/GEBsort]]<br /> <br /> o [[Raspberry Pi camera use]]<br /> <br /> o [[handeling removable disks under ESATA]]<br /> <br /> o [[data formats]]<br /> <br /> o [[triggers and digitizers]]<br /> <br /> o [[Digitizer Tester]]<br /> <br /> o [[The DGS/DFMA EPICS Implementation]]<br /> <br /> o [[firmware documentation]]<br /> <br /> o [[Tim Madden software documentation]]<br /> <br /> ==Hardware==<br /> This section outlines the hardware of Gammasphere including detectors and signal processing electronics. There is an interactive picture that is linked to detailed explanations of each detector after the ''2021 Upgrade Project''. It also contains details of the Liquid Nitrogen (LN) fill system.<br /> <br /> o [[LN system]]<br /> <br /> === Support Devices ===<br /> * [[Network Accessible Power Control Units of DGS]]<br /> <br /> * [https://wiki.anl.gov/wiki_gsdaq/images/4/40/MyRIAD_User_Manaual.pdf MyRIAD_User_Manaual]<br /> * [https://wiki.anl.gov/wiki_gsdaq/images/1/16/MyRIAD_Abridged_User_Notes.pdf MyRIAD_Abridged_User_Notes]<br /> <br /> * [[Attempts at Inventory]]<br /> * [[CrateAndBoardMapping]]<br /> <br /> ==Analog Gammasphere==<br /> <br /> o [[Analog Gammasphere]]<br /> <br /> o [[JohnSandbox]]<br /> <br /> ==On-Site Experts Only==<br /> <br /> o [[Building the entire system]]<br /> <br /> o [[Linking Systems Together]]<br /> <br /> o [[Updating Firmware in Digitizers and Triggers]]<br /> <br /> o [[IOC Code Design]]<br /> <br /> ===Digitizer hardware features you probably don't know about===<br /> <br /> * The digitizer has a [[DAC output]].<br /> * The digitizer has a buffer amplifier that drives a copy of the analog signal going into channel 9 to outputs on the front panel. This is a simple analog buffer, no shaping, sampling or anything else.<br /> *<br /> <br /> ==contact list==<br /> <br /> Mike Carpenter, mailto:carpenter@anl.gov<br /> <br /> John Anderson, mailto:jta@anl.gov<br /> <br /> Michael Oberling, mailto:moberling@anl.gov<br /> <br /> Torben Lauritsen, mailto:torben@anl.gov<br /> <br /> Darek Seweryniak, mailto:seweryniak@anl.gov<br /> <br /> Pat Copp, mailto:copp@anl.gov<br /> <br /> Amel Korichi, mailto:korichi@csnsm.in2p3.fr<br /> <br /> <br /> {{Template:Standard Footer}}</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2387 ANL Digitizer Firmware for Advanced Users 2021-09-29T16:49:00Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]).<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2386 ANL Digitizer Firmware for Advanced Users 2021-09-29T16:46:09Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. <br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=General_Design_of_the_Firmware&diff=2385 General Design of the Firmware 2021-09-29T16:42:23Z <p>Copp: </p> <hr /> <div>== [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == Event Data Nomenclature ==<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> === Discriminator Modes ===<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> === Pileup and Discriminator Hold-Off ===<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed.<br /> *The ''first'' hit of a pileup train is still called the ''accepted hit'' but all '''subsequent''' hits within a pileup train are called ''extended events''.<br /> <br /> The ''pileup inspection time'' is the minimum separation between ''discriminator hits'' before pileup is declared to exist.<br /> *The firmware can withstand a maximum of 16 events piled up on top of each other before the pileup inspection time of the first event expires. Should this be exceeded the digitizer enters the ''General Error'' state and all data processing within the channel stops until the digitizer is reset.<br /> <br /> Each channel implements a ''discriminator hold-off'' time that is the amount of time after a ''discriminator hit'' that the discriminator is blocked from marking another hit. This is related to the rise time of the signal so that only one ''discriminator hit'' is marked per rise.<br /> *If the user sets the ''discriminator hold-off'' time to a value less than the ''pileup inspection time'', the digitizer will enter the ''Pileup Too Short'' error state and must be manually reset with adjusted parameters.<br /> <br /> === Diagnostic Counters ===<br /> A primary diagnostic by which operation of the firmware may be monitored is by per-channel counters that monitor discriminator hits, accepted hits, accepted events and dropped events. Discriminator setup errors, or analog input issues, often result in no discriminator hits. If pileup rejection is enabled the ratio of accepted hits to discriminator hits provides immediate feedback regarding the percentage of events that are piled up. When using the “TTCL” mode (selection of events by the trigger) the ratio of accepted events to accepted hits may be used to determine if the trigger settings and/or digitizer trigger time windows are set appropriately. Recording any dropped events at all typically indicates that '''the amount of waveform data requested per event is too large for the event rate''' and that the readout of the digitizer over VME can’t keep up with the input data.<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2384 ANL Digitizer Firmware for Advanced Users 2021-09-29T16:37:53Z <p>Copp: /* Digitizer Channel Design Overview */</p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information.<br /> *Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=Digitizer_Channel_Design_Overview&diff=2383 Digitizer Channel Design Overview 2021-09-29T16:35:13Z <p>Copp: Created page with &quot;== Channel Design Overview == The 10 channels of the firmware are implemented as continuously running data pipelines. Data enters the pipeline every tick of the clock from th...&quot;</p> <hr /> <div>== Channel Design Overview ==<br /> The 10 channels of the firmware are implemented as continuously running data pipelines. Data enters the pipeline every tick of the clock from the ADC, proceeds through the pipeline and eventually falls off the back end. If conditions are satisfied data samples at the back end are copied into a buffer known as the Channel FIFO. <br /> <br /> In the middle of the pipeline multiple delay buffers with accumulators provide running sums of the data spanning programmable ranges of time. <br /> <br /> Other delay buffers in the pipeline provide delays for calculation of discriminator functions. When a discriminator hit occurs, various time values and data sums are stored as a header. Headers are stored in an Event Header FIFO that holds the headers so long as the associated waveform data is still in pipeline.<br /> <br /> [[File:Dig pic 44.png|center|Figure 2: 10 channel data flow diagram.]]<br /> <br /> === Channel Interactions ===<br /> When an event is selected for readout, the header from the Event Header FIFO is combined with the matching set of ADC data samples from the Channel FIFO, and this package of data is sent to the board-wide Accepted Event FIFO that services all 10 channels. The Accepted Event FIFO is drained by a state machine that copies the data to the FIFO memory external to the FPGA unless the external FIFO cannot be written to because it is too full; in that case the data is lost and counted as a dropped event. Because there are 10 Channel FIFOs that fill simultaneously from all 10 channels but only one Accepted Event FIFO, large event sizes combined with sufficient rate may result in dropped events because the channels block each other from access to the Accepted Event FIFO.<br /> <br /> == Channel Pipeline Structure ==<br /> The pipeline structure found in every channel is shown as Figure 3. The signal enters at the left and propagates to the right with time, backwards of a traditional oscilloscope image. When the edge of the signal reaches the middle, where the discriminator logic lies, the discriminator fires, capturing all the sum values shown plus timestamp and status information. This is all read out in the header of the data as explained in the next section.<br /> <br /> Note the discriminator in the middle of the design across buffer ‘d’, and the coarse discriminator placed well earlier in the pipeline.<br /> <br /> [[File:Dic pic 40.png|center|Figure 3: Pipeline structure of channel showing progression of waveform with time.]]<br /> <br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=General_Design_of_the_Firmware&diff=2382 General Design of the Firmware 2021-09-29T16:24:34Z <p>Copp: </p> <hr /> <div>== Event Data Nomenclature ==<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> === Discriminator Modes ===<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> === Pileup and Discriminator Hold-Off ===<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed.<br /> *The ''first'' hit of a pileup train is still called the ''accepted hit'' but all '''subsequent''' hits within a pileup train are called ''extended events''.<br /> <br /> The ''pileup inspection time'' is the minimum separation between ''discriminator hits'' before pileup is declared to exist.<br /> *The firmware can withstand a maximum of 16 events piled up on top of each other before the pileup inspection time of the first event expires. Should this be exceeded the digitizer enters the ''General Error'' state and all data processing within the channel stops until the digitizer is reset.<br /> <br /> Each channel implements a ''discriminator hold-off'' time that is the amount of time after a ''discriminator hit'' that the discriminator is blocked from marking another hit. This is related to the rise time of the signal so that only one ''discriminator hit'' is marked per rise.<br /> *If the user sets the ''discriminator hold-off'' time to a value less than the ''pileup inspection time'', the digitizer will enter the ''Pileup Too Short'' error state and must be manually reset with adjusted parameters.<br /> <br /> === Diagnostic Counters ===<br /> A primary diagnostic by which operation of the firmware may be monitored is by per-channel counters that monitor discriminator hits, accepted hits, accepted events and dropped events. Discriminator setup errors, or analog input issues, often result in no discriminator hits. If pileup rejection is enabled the ratio of accepted hits to discriminator hits provides immediate feedback regarding the percentage of events that are piled up. When using the “TTCL” mode (selection of events by the trigger) the ratio of accepted events to accepted hits may be used to determine if the trigger settings and/or digitizer trigger time windows are set appropriately. Recording any dropped events at all typically indicates that '''the amount of waveform data requested per event is too large for the event rate''' and that the readout of the digitizer over VME can’t keep up with the input data.<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=General_Design_of_the_Firmware&diff=2381 General Design of the Firmware 2021-09-29T16:22:31Z <p>Copp: </p> <hr /> <div>== Event Data Nomenclature ==<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> === Discriminator Modes ===<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> === Pileup and Discriminator Hold-Off ===<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed.<br /> *The ''first'' hit of a pileup train is still called the ''accepted hit'' but all '''subsequent''' hits within a pileup train are called ''extended events''.<br /> <br /> The ''pileup inspection time'' is the minimum separation between ''discriminator hits'' before pileup is declared to exist.<br /> *The firmware can withstand a maximum of 16 events piled up on top of each other before the pileup inspection time of the first event expires. Should this be exceeded the digitizer enters the ''General Error'' state and all data processing within the channel stops until the digitizer is reset.<br /> <br /> Each channel implements a ''discriminator hold-off'' time that is the amount of time after a ''discriminator hit'' that the discriminator is blocked from marking another hit. This is related to the rise time of the signal so that only one ''discriminator hit'' is marked per rise.<br /> *If the user sets the ''discriminator hold-off'' time to a value less than the ''pileup inspection time'', the digitizer will enter the ''Pileup Too Short'' error state and must be manually reset with adjusted parameters.<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2380 ANL Digitizer Firmware for Advanced Users 2021-09-29T16:15:47Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''''Event Data Nomenclature''''', '''''Discriminator Modes''''', '''''Pileup Rejection''''', and '''''Diagnostic Counters'''''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> == [[Digitizer Channel Design Overview]] ==<br /> This section covers mid-level descriptions of '''''Digitizer Channel Design''''', '''''Channel Interactions''''', and '''''Pipeline Structure'''''<br /> <br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2379 ANL Digitizer Firmware for Advanced Users 2021-09-29T16:07:57Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> This section introduces mid-level descriptions for the topics of '''Event Data Nomenclature''', '''Discriminator Modes''', '''Pileup Rejection''', and '''Diagnostic Counters'''.<br /> <br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> === Event Data Nomenclature ===<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> ==== Discriminator Modes ====<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> ==== Pileup and Discriminator Hold-Off ====<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=General_Design_of_the_Firmware&diff=2378 General Design of the Firmware 2021-09-29T16:03:13Z <p>Copp: Created page with &quot;=== Event Data Nomenclature === Signal edges marked by discriminator firings are named ''discriminator hits''. *''Discriminator hits'' become accepted hits after passing thro...&quot;</p> <hr /> <div>=== Event Data Nomenclature ===<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> ==== Discriminator Modes ====<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> ==== Pileup and Discriminator Hold-Off ====<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2377 ANL Digitizer Firmware for Advanced Users 2021-09-29T16:00:30Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> == [[General Design of the Firmware]] ==<br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> === Event Data Nomenclature ===<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> ==== Discriminator Modes ====<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> ==== Pileup and Discriminator Hold-Off ====<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=A_Short_Introduction_to_Data_Acquisition_Hardware&diff=2376 A Short Introduction to Data Acquisition Hardware 2021-09-29T15:58:41Z <p>Copp: </p> <hr /> <div>=== &quot;Master&quot; and &quot;Slave&quot; Digitizers ===<br /> The digitizer modules may be used in pairs where one digitizer is labeled the “master” and the other is labeled the “slave”. In this configuration the two digitizers have ''different versions of firmware''. The “master” digitizer alone connects to the trigger system. A ribbon cable connects the “master” digitizer to the “slave” digitizer. The “slave” digitizer channels are normally configured to use signals from the “master” digitizer as part of the logic determining if discriminators within the “slave” channels will fire or not, or whether events within the “slave” are marked for readout or not.<br /> <br /> === Clocking and Timestamps ===<br /> The ADC chips run at a frequency of 100MHz (100 MSamp/sec). The device may run from its own internal oscillator or may receive a clock from an external trigger system and synchronize to that clock. A clock distribution from the trigger allows many digitizer modules to run synchronous to each other.<br /> <br /> The digitizer module uses a 48-bit timestamp counter run from the 100MHz clock. When connected to the trigger system, the trigger may issue a command to synchronously reset the timestamp in all digitizers. Events read out of the digitizer are tagged with a timestamp for sorting and analysis.<br /> <br /> === Connection to External Trigger System ===<br /> Digitizer modules may connect to a trigger system for synchronization and event selection purposes. A separate cable plant connects digitizer modules to trigger modules; on the digitizer end the cable uses the same RJ45 connector as Ethernet, but the signal levels and usage '''''are not Ethernet'''''. '''Do not connect the digitizer to an Ethernet port, this will damage the digitizer module'''.<br /> <br /> The digitizer can run standalone without being connected to a trigger system. In this configuration every digitizer board has independent and unsynchronized clocks. Timestamps for event sorting are not useful across multiple modules as there is no synchronism, but within one board timestamps are still sensible.<br /> <br /> ''See '''MyRIAD_USER_Manaual''' or '''MyRIAD_Abridged_User_Notes''' in [[Original Content prior to the ''Gammasphere Upgrade Project'']] for detailed information on External Trigger systems''.<br /> <br /> ''Go back to [[ANL Digitizer Firmware for Advanced Users]]''<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=A_Short_Introduction_to_Data_Acquisition_Hardware&diff=2375 A Short Introduction to Data Acquisition Hardware 2021-09-29T15:57:17Z <p>Copp: Created page with &quot;=== &quot;Master&quot; and &quot;Slave&quot; Digitizers === The digitizer modules may be used in pairs where one digitizer is labeled the “master” and the other is labeled the “slave”. I...&quot;</p> <hr /> <div>=== &quot;Master&quot; and &quot;Slave&quot; Digitizers ===<br /> The digitizer modules may be used in pairs where one digitizer is labeled the “master” and the other is labeled the “slave”. In this configuration the two digitizers have ''different versions of firmware''. The “master” digitizer alone connects to the trigger system. A ribbon cable connects the “master” digitizer to the “slave” digitizer. The “slave” digitizer channels are normally configured to use signals from the “master” digitizer as part of the logic determining if discriminators within the “slave” channels will fire or not, or whether events within the “slave” are marked for readout or not.<br /> <br /> === Clocking and Timestamps ===<br /> The ADC chips run at a frequency of 100MHz (100 MSamp/sec). The device may run from its own internal oscillator or may receive a clock from an external trigger system and synchronize to that clock. A clock distribution from the trigger allows many digitizer modules to run synchronous to each other.<br /> <br /> The digitizer module uses a 48-bit timestamp counter run from the 100MHz clock. When connected to the trigger system, the trigger may issue a command to synchronously reset the timestamp in all digitizers. Events read out of the digitizer are tagged with a timestamp for sorting and analysis.<br /> <br /> === Connection to External Trigger System ===<br /> Digitizer modules may connect to a trigger system for synchronization and event selection purposes. A separate cable plant connects digitizer modules to trigger modules; on the digitizer end the cable uses the same RJ45 connector as Ethernet, but the signal levels and usage '''''are not Ethernet'''''. '''Do not connect the digitizer to an Ethernet port, this will damage the digitizer module'''.<br /> <br /> The digitizer can run standalone without being connected to a trigger system. In this configuration every digitizer board has independent and unsynchronized clocks. Timestamps for event sorting are not useful across multiple modules as there is no synchronism, but within one board timestamps are still sensible.<br /> <br /> ''See '''MyRIAD_USER_Manaual''' or '''MyRIAD_Abridged_User_Notes''' in [[Original Content prior to the ''Gammasphere Upgrade Project'']] for detailed information on External Trigger systems''.</div> Copp https://wiki.anl.gov/wiki_gsdaq/index.php?title=ANL_Digitizer_Firmware_for_Advanced_Users&diff=2374 ANL Digitizer Firmware for Advanced Users 2021-09-29T15:57:04Z <p>Copp: </p> <hr /> <div>== [[A Short Introduction to Data Acquisition Hardware]] ==<br /> To fully understand how the firmware works the hardware environment must be explained. This section briefly introduces the concept of '''Master and Slave digitizers''', '''Clocking and Timestamps''', and '''Connecting the Trigger to External Systems'''.<br /> <br /> The digitizer module contains two FPGAs, one for VME interface and firmware maintenance purposes, and the other for ADC data processing, as shown in Figure 1.<br /> <br /> [[File:Dig pic 43.png|center|Figure 1: Overall block diagram of digitizer module.]]<br /> <br /> === Input Signals ===<br /> Signals at the digitizer input are differential. The input range is limited. While the ADC chip the module uses nominally has a +/-2V differential input (that is, + to – may range from -2V to +2V) the input buffer circuitry does not have sufficient power supply voltage headroom to support this full range. The device works very well for signals that range between -1.5V to +1.5V differential, but signal compression occurs beyond those limits. Linearity studies performed at ANL show that the device is almost perfectly linear for an input range of '''-1.2V to +1.2V''' but small deviations from linearity are discernable from 1.2V to 1.5V with marked deviations occurring past 1.5V.<br /> <br /> In terms of ADC counts, since the ADC chip is designed to span 16,384 codes over 4 volts, this means that the conversion is 4096 counts per volt. Thus<br /> * For absolute best linearity, limit the DC offset and signal range to no more than ±(1.2 * 4096), or ±4916 counts, from the nominal 0V level of 8192 counts (3276 to 13108).<br /> *For all but the most stringent requirements, a more relaxed range of ±(1.5 * 4096), or ±6144 counts, will suffice (2048 to 14336).<br /> *If the physical setup exceeds these bounds, non-linearity will distort waveform shapes.<br /> <br /> === &quot;Master&quot; and &quot;Slave&quot; Digitizers ===<br /> The digitizer modules may be used in pairs where one digitizer is labeled the “master” and the other is labeled the “slave”. In this configuration the two digitizers have ''different versions of firmware''. The “master” digitizer alone connects to the trigger system. A ribbon cable connects the “master” digitizer to the “slave” digitizer. The “slave” digitizer channels are normally configured to use signals from the “master” digitizer as part of the logic determining if discriminators within the “slave” channels will fire or not, or whether events within the “slave” are marked for readout or not.<br /> <br /> === Clocking and Timestamps ===<br /> The ADC chips run at a frequency of 100MHz (100 MSamp/sec). The device may run from its own internal oscillator or may receive a clock from an external trigger system and synchronize to that clock. A clock distribution from the trigger allows many digitizer modules to run synchronous to each other.<br /> <br /> The digitizer module uses a 48-bit timestamp counter run from the 100MHz clock. When connected to the trigger system, the trigger may issue a command to synchronously reset the timestamp in all digitizers. Events read out of the digitizer are tagged with a timestamp for sorting and analysis.<br /> <br /> === Connection to External Trigger System ===<br /> Digitizer modules may connect to a trigger system for synchronization and event selection purposes. A separate cable plant connects digitizer modules to trigger modules; on the digitizer end the cable uses the same RJ45 connector as Ethernet, but the signal levels and usage '''''are not Ethernet'''''. '''Do not connect the digitizer to an Ethernet port, this will damage the digitizer module'''.<br /> <br /> The digitizer can run standalone without being connected to a trigger system. In this configuration every digitizer board has independent and unsynchronized clocks. Timestamps for event sorting are not useful across multiple modules as there is no synchronism, but within one board timestamps are still sensible.<br /> <br /> ''See '''MyRIAD_USER_Manaual''' or '''MyRIAD_Abridged_User_Notes''' in [[Original Content prior to the ''Gammasphere Upgrade Project'']] for detailed information on External Trigger systems''.<br /> <br /> == General Design of the Firmware ==<br /> The ANL version of digitizer firmware implements ten independent data acquisition pipelines in ten channels. Pileup detection &amp; rejection is performed locally within the digitizer. Selective readout of events is achieved using an external trigger system. Waveform readout of all events is possible, with up to 1024 ADC samples per channel per event, although this will limit the event rate as the VME backplane reaches its bandwidth limit. A down-sampling mode allows readout of averaged samples where each waveform sample in the readout may be the average of 2n ADC samples, from 2 to 128 (n = 0, 1, 2,…, 6, 7). Increased event rates are obtained by limiting the amount of waveform data read out per event.<br /> <br /> Each '''channel pipeline''' consists of a series of memory buffers used for delay. Discriminator logic recognizes edges within the input signal and causes data values to be sampled. When sampling occurs, the timestamp value is saved. The discriminator logic may be configured as either leading-edge (slope) or constant-fraction architecture, sensitive to either positive-only, negative-only or both edges. The discriminator implements a programmable hold-off time to ensure that the discriminator fires only once per edge. A discriminator firing captures timing and data sums simultaneously. This data is buffered so that discriminator re-arms very quickly. Firing rates over 1MHz can be supported, yet readout is limited to the IOCs total bandwidth ([[IOC Code Design]]). No information reduction occurs in pileup conditions due to the fast discriminator recovery time.<br /> <br /> All sampled values and sums are formatted into an '''event header''' that is followed by a programmable number of waveform samples. The header contains various fields, including the timestamp of the event, the timestamp of the last time the discriminator of that channel fired, the timestamp of the peak, energy information, plus some energy/time information carried over from the previous discriminator firing. Flag bits provide useful diagnostics. The waveform data contains the raw ADC samples of the event, plus serialized timing mark bits that indicate when specific actions (discriminator, peak, timeouts, etc.) occurred and a 2nd bit that indicates whether samples are down-sampled (rescaled average of 2**n samples) or full-speed.<br /> <br /> Energy measurement is performed in a double-correlated method timed relative to the moment the discriminator fires. Programmable '''delay buffers''' positioned to measure ranges of time before (pre-rise) and after (post-rise) the discriminator logic have accumulators continuously calculating the sum of all the ADC samples within them. When the discriminator fires these sums are saved and reported in the header. These sums may then be used by ''open source user-maintained software'' (see the gitlab link in [[analysis codes]] for GEBSort) to calculate the energy (amplitude) of the input signal, with all necessary baseline and pole-zero correction information obtained from the other information in the header. This method is arithmetically identical to the traditional “trapezoid” method but is optimized for high rates of discriminator operation.<br /> <br /> Hits captured by the discriminator may optionally be rejected if pileup occurs. If piled-up events are allowed the piling-on events may be read out in a variety of ways including extended and offset waveforms or just additional headers. The reverse logic is also supported, in which only piled-up events are available for readout. The firmware interfaces with an FPGA-based trigger system, also designed at ANL, to provide event selection based upon programmable trigger conditions. Specific triggering modes appropriate to the different detector systems at ANL have been developed. <br /> <br /> === Event Data Nomenclature ===<br /> Signal edges marked by discriminator firings are named ''discriminator hits''. <br /> *''Discriminator hits'' become accepted hits after passing through pileup rejection logic. <br /> *The firmware may run by itself (“internal accept all” mode) or with the trigger system (“TTCL mode”).<br /> # When running in “internal” mode ''accepted hits'' immediately become ''accepted events'' that are later read out.<br /> # When the trigger system is used ''accepted hits'' wait in a queue for a limited time. The ''accepted hits'' in this queue only become ''accepted events'' if selected by a ''trigger accept message'' from the trigger. Accepted hits not marked as accepted events fall off the end of the pipeline and are discarded.<br /> *The expectation is that all ''Accepted Events'' will be read out. ''Accepted Events'' that were unable to be copied into the output buffer due to FIFO backup or other readout interference are named ''dropped events''.<br /> # When using the trigger system, the digitizer may assert a ''Throttle Request'' to the trigger if its FIFO is getting too full. This request, if honored, will result in the trigger suspending the issuance of trigger accept messages so that the readout system may drain the FIFO forming an automatic flow control mechanism to avoid ''dropped events''.<br /> <br /> ==== Discriminator Modes ====<br /> The firmware supports either ''leading-edge'' or ''constant-fraction'' discriminator logic, independently selected per channel. In leading-edge mode the operation is controlled by a delay value ‘d’ and a threshold such that the discriminator fires if the difference between sample X(n) and sample X(n-d), after some filtering, is greater than the threshold. In constant-fraction mode, the user specifies a fraction value along with the same timing parameter ‘d’; the discriminator logic continuously calculates [X(n)*fraction] – X(d), and fires when this signal recrosses the initial value it had before the start of the edge.<br /> <br /> A 2nd, separate copy of the leading-edge discriminator, with its own threshold, called the coarse discriminator is also provided. The coarse discriminator fires well before the main discriminator does as it sees the edge earlier. The output of this device is used to capture early energy sum values well before the edge occurs, for use in pole-zero and/or baseline correction software after data is collected. Figure 3, later in this document, will explain these terms more fully.<br /> <br /> ==== Pileup and Discriminator Hold-Off ====<br /> When pileup rejection is '''on''', ''discriminator hits'' become ''accepted hits'' only if there is no pileup.<br /> <br /> When pileup rejection is '''off''', discriminator hits always become accepted hits, but differentiation between the first accepted hit and all that pile up upon it (a “pileup train”) is needed<br /> <br /> ''Go back to [[Digital Gammasphere and the SBX Upgrade]]''</div> Copp