IntegrationDaq 220211

Back to Main Page >> Data Acquisition Meetings >> Integrating mode DAQ meetings

previous meeting << >> following meeting

Meeting information

 Meeting time:  12:00pm Eastern
 
 Zoom connection information
 Join ZoomGov Meeting
 https://jlab-org.zoomgov.com/j/1603800887?pwd=aXVmSnN6aWZWN3RBdXB4RUhGckZJdz09
 
 Meeting ID: 160 380 0887
 Passcode: 903612
 US Tool free phone: (833) 568 8864
 Find your local number: https://jlab-org.zoomgov.com/u/ab8341cjcG

Agenda

• Activity updates
  • We have restarted the discussion of the integrator running modes we would like to have available, but is not final
• General discussion

Open Issues to be followed up later

1. Discussions with M. Pitt & J. Musson to understand the beam monitor signals we'll be getting
2. Draft timing diagram: DocDB 790
3. Michael, Bob, Brynne, and Paul should put together a list of the integrator running modes we would like to have available

Minutes

Recording at zoomgov: [1]

Participants: R. Michaels, B. Moffit, D. Bishop, B. Blaikie, W. Gu, P. King, M. Gericke

• Talking about the concept of the integrating ADC firmware DocDB 864
  • The delay between the trigger to the "Start of integration" will be done in the TI firmware within the module.
    • We can use either the leading edge or trailing edge of the Tsettle as the trigger to give us the most flexibility in defining the time
    • In an email after the meeting, Michael asks if we might need to have different delays for different channels, such as for beam monitors at different places along the beam line running into the same ADC board
  • Daryl points out that the ADC samples will be running all the time, and the trigger information is just flagging what to do with the samples, such as to integrate them or to store them as the waveform, etc.
    • Bryan asks if we could have some "lookback" or latency in the module such that we could actually accumulate samples from earlier than the trigger arrives
  • Talking about the subblocks
    • Our normal subblocks would be the time-ordered blocks, i.e. the first subblock is the first quarter of the helicity window, etc.
    • The interleaved subblock proposal would have every fourth sample accumulated in the same block, i.e. the first interleaved subblock would be samples 1, 5, 9, etc.
    • Bryan asks if the interleaved blocks are designed to look for a particular type of noise, or if there might be some better choice to pick out a type of noise; the answer is that these aren't specifically designed for a particular type of noise. This had been brought up at a collaboration meeting several years ago, and we don't recall right now if this was targeted at something specific
    • Daryl suggests we could have both the tine-ordered and interleaved blocks accumulated all the time.
  • Another idea, initially suggested by Jie, is to have the sampled waveform during the Tsettle, and then the accumulated blocks for the stable period
    • The 10us Tsettle would be about 150 samples: treating the samples as 4-byte longwords gives 600 bytes per window, or about 1MB/s added. This seems like a good idea and shouldn't take up too much of our resources.
  • Can we send trigger types to the modules, and then use that to communicate what types of readout to do for a particular helicity event?
    • William says that would be possible: several levels can be passed from the TI part of the firmware to the rest of the
  • We should use 64-bit integers for all the accumulated values. The prototype is currently using 64-bit integers.
    • This would double the data rate to ~260MB/s.
  • Do we want a time-stamp on each block? Yes, we should do that.
  • Talking about the "streaming modes"
    • One way to handle both the "continuous 1 second" and the "waveform during helicity window" modes would be to have a mode in which we report all the samples without blocking out the spin-flip
      • Late thought: Maybe combine this idea with the idea of reporting all samples of the Tsettle; the "window waveform" is the specified number of samples starting at the trigger point, and the "Tsettle waveform" the the samples from the end of the previous window until the beginning of the current window. The actual spin flip transition occurs early in the Tsettle period, so most of the Tsettle has the same helicity state as the window following it. The Tsettle waveform should be associated with the window following it.
    • Daryl things that we bought the SOM with 2GB of memory, so that minus the operating system sets the scale of the most we can accumulate. Bryan thinks the OS on the VTP might be 1GB, as a comparison.
      • At the 14.7 Msps and packing the samples as tightly as possible (4 samples per 9 bytes), one second of data in all 16 channels would be 530MB. If we used 4 bytes per sample, one second of data in all channels would be 940MB.
  • The Ethernet link on the modules is capable of 10Gb/s, but the Xilinx IP is very expensive (~20k$ for the license). The 1 Gbps link doesn't require an additional licence
    • In an email thread later, Ben Raydo shared that for the 10Gbps links in the VTP JLab uses some IP from Comblock which costs ~$3300 for the license
  • To have lower rate samples, it is easier to keep the actually sampling of the ADCs the same and just keep the ones of interest. (Keeping every seventh sample would give an effective sample rate of 2.1MHz).
• Update from Daryl
  • Bryerton has finished the clock cleaner and is started to work with the ADCs
  • They found that the VCO they had chosen is too precise to lock properly to the 250MHz clock from the TI (or the other clocks)
    • This will require a part change; Daryl has ordered the replacement part and should get it next week.