Digitizer flushing

Looking into the flushing of digitizers at run stop

This is one of many looks into the C source code found at /global/devel/gretTop/9-22/dgsDrivers/dgsDriverApp. The code here is supposed to be the ATLAS-specific general drivers for triggers and digitizers.

inLoop.st

The main data acquisition thread in the MVME5500 is the state machine "inloop", found at /global/devel/gretTop/9-22/dgsDrivers/dgsDriverApp/src/inLoop.st. There are variant versions of this code named inLoop.st.JTA (commented by me), inLoopDbg.st (a version that doesn't take data but allows you to dump various internal IOC information from the console port by setting a variable to different values). Other variations of the inLoop name are probably temporary or deprecated versions.

InLoop is written in "epics state machine language", meaning that a set of states are named, and you can define things to do upon entry to the state, things to do when some condition becomes true during the state, and things to do when exiting the state. General syntax is

   state StateName {
      entry {
        <<statements to be executed when state is entered from another state>>
      }
      when (<xxx>) {
        <<statements to be executed when condition 'xxx' is true when in this state>>
      }  state NextState    <<<----  name of state to transition to when condition "xxx" is true, after executing statements in the braces
      exit {
       <<statements to be executed when exiting this state for any reason>>
       <<nominally could just be in when() condition braces but this works for *any* exit>>
      }
   }
 

When we look at what's going on during the run portion of inLoop.st, this shows that state "waitfordone" is supposed to be flushing the FIFOs of the digitizers after acquisition is stopped.

   state run {
      option -e;	/* do entry every time */
      entry {
       %%if (readfifo_trace>5)	printf("inLoop run");
         dataReady = checkFIFO(boardNo, buildEnable);
      }
      when (!AcqRun) {
	      MLE=0; pvPut(MLE);
      } state waitfordone
      when (dataReady) {
        serviceOneBuffer(boardNo,dataReady);
      } state rundelay
      when (delay(tDly)) {
      }  state run
   }
   state waitfordone {
      option -e;	/* do entry every time */
      entry {
                %%if (readfifo_trace>5)	printf("inLoop waitfordone");
		dataReady = checkFIFO(boardNo, buildEnable);
      }
      when (dataReady > 1) {
        serviceOneBuffer(boardNo,dataReady);
      } state stopdelay
      when (delay(1)) {
         clearFIFO(boardNo);
      }  state setup
   }
 

The magic routine used in all cases to get data out of a digitizer is the routine serviceOneBuffer(boardNo,dataReady). It need be noted that this function is not event-based but is aligned to the amount of data that the MVME5500 considers a 'buffer'.

ServiceOneBuffer

After a bit of looking you find the file readFIFO.c in the same directory as inLoop.st. And you also find that within readFIFO.c there are at least four versions of serviceOneBuffer - one with that exact name, one called serviceOneBufferDGS, one named serviceOneBufferTrig and another named serviceOneBufferSim.

You might think that serviceOneBufferDGS is for DGS digitizers, but you'd be wrong. The inLoop.st code calls serviceOneBuffer, not serviceOneBufferDGS. Why? Only the Deity knows. Or maybe the guy in the place with fire and brimstone. One of the two. Not any of us.

Anyway, the takeaway here is that the flushing problem appears to be in the back-end sorter code, not in the collection of data from the digitizers. So we have to then figure out where all the buffer management junk is.