Fat Man's Squeeze

Seeing as how the present datapath (with 3 PMT inputs) won't fit on the FPGA without significant recoding, for now I am going to cut the number of PMT inputs down to 2, so that we can at least start doing some work on coincidence detection code.  It should be easy enough to write this code in a general sort of way, so that it can work with any number of inputs, so we can test it with 2, and then when we have 3 inputs, it should still work (albeit more selectively).

Latest top-level design is on COSMICi (my work PC) in Q:\COSMICi_FEDM_top9.bdf, v0.11.  It has the third instance of the PMT_ic_datapath stubbed out.  It uses 18,961/27,104 (70%) of flip-flops (8,143 = 30% unused), 193/202 (96%) of M512 blocks (9 = 4% unused), and 100% of M4K blocks, and the MRAM.

Thinking about the firmware design for coincidence filtering.  Really, we need N separate software pulse queues for the N input channels, since (due to the way the interrupt-handler works), multiple pulses from one channel could get read in from the datapath before we turn our attention to another channel on which pulses were being received at the same time.  So, to synchronize them in time requires sorting the various pulses received by arrival time, and this is easiest to do if each channel has its own queue of (already-sorted) incoming pulses.  Then we just need a selection-sort kind of process to merge them together.

Thinking now about how the "coincidence groups" will be identified.  There is a potential ambiguity if two successive groups of pulses arrive close together in time - which "neighbors" will each pulse be identified with?  However, as long as all of the potentially-important data makes it to the server (where it can be re-grouped if necessary by a more sophisticated analysis), it is probably good enough if we just take a "greedy" approach, and just send all pulses that arrive within the window size of any pulse on the other channels.

Pseudo-code for coincidence-detection algorithm:

1. Identify the pulse that is the earliest-arriving out of the ones sitting at the front of all N of the software pulse-input queues (for the N channels).
2. Calculate the absolute time difference between this pulse and the earliest-arriving one at the front of the other (N-1) software input queues.
3. MIN this with the time difference between this pulse and the pulse most recently pulled from the queues.
4. If this time difference is less than the window size, then send this pulse to the server, since it may be part of a group.  Otherwise, throw it away.
5. Repeat 1-3 until at least one of the N software pulse queues is empty.  
6. Then, take care of other tasks until a little bit later, 
7. Then start back at step 1.

Note that this algorithm will send pulses data for all potential coincidences that happen out of even only 2 of the 3 (or 4) PMTs.  However, this still should be enough to cut down on the spurious data rate from terrestrial radiation substantially (we'll see how much).  Any additional filtering that may be needed (to focus on 3-node or, later, 4-node coincidences) can be done on the server side.

At the end of the day, I was still trying to debug the new firmware (for the new multi-channel datapath).  For some reason, we seem to not be receiving any pulse-capture (HAVE_DATA) interrupts.  (Or any BUF_FULL interrupts either, for that matter.)  I have reviewed the new C code a couple of times and it looks fine.  I am thinking that maybe the SOPC system configuration got out of sync between the gelware and the BSP at some point (like, memory-map addresses of the PIOs, since Darryl added & deleted some PIOs).  Regenerating SOPC files and BSP files, rebuilding ELF file, recompiling Quartus design.  If this doesn't work, I'll just give up and go home for the night and take another stab at it tomorrow.