Multiple PMT Inputs

Today, my plan is to finish the gelware+firmware changes needed to process 3 PMT inputs.  I discovered yesterday that we can't use all 4 PMT inputs because PMT3 is wired to the timing signal input, so it isn't really an independent input!  Asked Ray to ask to join Mentor Graphics' Higher Education program, so that maybe we can get a cheap(ish) full license for PADS, so that we can tweak the design.

I finished entering the pin assignments based on the OrCAD schematic, but I still need to double-check them against the layout.

Design with 3 copies of the datapath is exceeding the available RAM.  Cutting down the pulse-form gelware FIFO size in half, from 16 pulses down to 8 pulses.  Note to self:  If this doesn't work, I could also try putting it in logic instead of RAM - I think we still had plenty of logic cells left on the FPGA.  Nope, not enough register cells for that either.  Guess I'll have to cut the FIFO size down to 4 pulses per channel.

Changing the step size for the ladder to 100 mV, so that hopefully we can see more thresholds beings crossed.

Also disconnected some of the diagnostic outputs from earlier (stopped routing them to the board), so we can see if that helps clean up the noise on the PMT input.

Connected channels 2-4 of the scope to the first 3 thresholds, so that we can see visually on the scope exactly where the PMT pulse is crossing each of these thresholds.

A thought: Should I reprogram the FEDM to do its reporting in the form of LOGMSG messages over the UART/Wi-Fi bridge to the server?

Still no luck with the depth-4 FIFO.  Each of the datapaths is using 43 of the M512 blocks currently.  Total M512 usage is 283/202.  In other words, 81 too many.  So, if two of the datapaths didn't use M512s, then maybe we could fit.  So, construct an alternate version of the datapath that uses logic instead of M512s, and use two of these, and one of the original?  Trying that now...

Another thing:  We could do this thing that we've been postponing forever, which is to compress the pulse representation in the pulse-capture datapath, using the assumption that the pulse width is relatively narrow.  However, that is pretty involved - it will require making substantial changes to numerous modules - and it is error-prone - a lot of things could go wrong, and so it may be time-consuming to debug.  It could be an appropriate job for Darryl or David (if one of them does any work for us in the Fall), since they are more experienced now.  Or it could be done by a member of the Senior Design team, if a student who is good enough at VHDL is appointed.

OK, last fit attempt was not successful, we tried to use 29070/27104 register cells.  Each of the FIFOs that is using individual logic register cells is using about 10k worth of those.  More than half of this (5400 cells) are in the FIFO, but almost all the rest are in pulseform_cap.  Each of the 6 pulse_prep instances takes about 650 cells and pulse_combine takes 780.  Within pulse_prep, 387 cells are in cs_combine and 260 are in se_pulse_cap.  This is pretty much unavoidable in the current architecture, due to the need to store 64 bits for the sum and carry bits for both the rising and falling edges (that's 256 bits already).

We should perhaps consider reducing the counter size from 64 bits to, say, 48 bits (a 25% decrease).  That still gives about 6.5 days for the length of a run.  That seems a bit too short.  Or better, 56 bits (a 12.5% decrease) would give us a run length of about 4.5 years - more than enough.

Let's see, shrinking the width of each of the datapaths by 12.5% would save about 2500 cells in the two datapaths that are implemented as logic-only (no RAM blocks).  This would be more than sufficient to bring our register cell usage back under the limit.

This change is somewhat easier (and less error-prone) than compressing the pulse representation before buffering.  Still, it will require changing numerous modules, so it should perhaps wait for a student to be assigned this task.