Friday Fun

Although it is a furlough day, and my normal day off, I love this job so much that I decided to come in anyway.  :)

Here is a list of some things that Darryl and I can work on over the next week:

• While I'm supervising Darryl as he works on the following tasks, meanwhile in the background I can be working on making a new version of the front-end modules that uses single-edge-triggered registers at a higher frequency to see if we can improve our throughput in that manner.  (This will take a while though, so it will be good for Darryl to be making progress on some simpler tasks in the meantime.)
  
• Add a NEG_INPUT control signal to the input capture datapath (pmt_ic_datapath2.bdf), and the top-level schematic (COSMICi_FEDM_top7.bdf); then add appropriate code to the device driver (icdp_driver.{c,h}) to initialize this signal appropriately on system startup - an icdp_init() routine, and call it at an appropriate point in main().  Switch the +/- jumper on the PMT input, and run a test with negative input pulses.
  
  
• Add a RESET control signal to the IC datapath; fan it down into ALL appropriate submodules (exception - the high-speed counter); add VHDL as needed to reset the state of the datapath (clearing out any stale, buffered information; reinitializing all state variables); add a routine icdp_reset() to the device driver; call it on initialization; add RESET command to the command-line interpreter (command.{c,h}).
  
  
• Add the RUN_PAUSEn control signal to the IC datapath; fan it down into all appropriate submodules (with the exception of the high-speed counter);  modify VHDL as needed to require RUN_PAUSEn to be high as a prerequisite for any state changes; implement RUN/PAUSE commands.
  
  
• Add a SET_DAC command to the command-line interface.  Syntax: "SET_DAC [<dac_id> [<int_level>|<float_level>]]", where <dac_id> is an unsigned decimal integer from 1-6; <int_level> lacks a decimal point and is interpreted as a literal 12-bit unsigned integer (0-4095) to be sent to the DAC; or, if <int_level> starts with a minus sign, then it is interpreted as 4096+<int_level>.  Alternatively, <float_level> contains a decimal point and is interpreted as a nominal voltage in volts from 0.0 to 2.5; however, if <float_level> is negative, then it is interpreted as 2.5+<float_level> volts instead.  If the <dac_id> or the requested level is out of range, then an error message is displayed.  If there is no 2nd argument, then the present (i.e., most recently programmed) level of the designated DAC is displayed.  If there is no 1st argument either, then the present levels of all the DACs are displayed.
  
  
• Using SET_DAC interface, determine minimum threshold level that avoids getting significant numbers of spurious pulses due to noise in current test rig setup.
  
  
• Create a new input capture datapath for the timing sync input pulses.  A comparator threshold around 0.5V would be fine for those, as we expect to be able to get at least 1V out of the sync pulse receiver (and more during direct coax testing from the DE3 board).  All that this datapath needs to do is: (1) latch the carry-save counter value on a rising edge from the comparator, (2) add the sum and carry bits, (3) break up the 64-word into 32-bit subwords, and (4) send it to CPU using another couple of PIOs and a HAVE_DATA/PUMP_DATA interface.  RESET and RUN_PAUSEn control bits could also be included.  We don't need a BUF_FULL since there's no buffer, but we do need a somewhat analogous interrupt, call it MISSED_PULSE, that allows us to complain to the CPU if a new pulse arrives before it has finished pulling the data from the last one.  The data to be sent includes: (a) 32-bit sequence number of this pulse (to allow CPU to detect if it missed a pulse), (b) 32-bit MSW of arrival time, (c) 32-bit LSW of arrival time. 
  
  NOTE: All 5 of the input capture datapaths (4 PMTs and 1 for timing) could be controlled through a single icdp_ctrl PIO by allocating different bit-fields for them appropriately; this would take 5x5 = 25 bits.  However, I'm not sure yet if there will be enough space on the board for all of them.
  
  (5) Write the device driver (timing_driver.{c,h}), which will basically just keep count of the number of timing sync input pulses that have arrived since the start of the run, and the time (in fast counter half-cycles) of the most recent timing-sync pulse.  And maybe periodically send a report of this time data to the server.  (Twice a millisecond is too often, given our serial bandwidth limitations, but we could maybe send one every 100 ms, say - and one each time a pulse arrives.)
  
  
• Hook up the GPS app board to the FEDM board, get both running together (with timing sync pulses from the GPS board being received and timestamped on the FEDM board). 
  
  
• Try fitting all 5 input capture datapaths on the board at once; modify firmware and/or compress datapath if needed to make room.
  
  
• Write code to send pulse data (with timing data) out the serial port through the Wi-Fi board to the server.  Create server modules to gather, store, and visualize this data.
  
  
• Create module for dynamic adjustment of threshold voltages to minimize noise.

I was out for a while in the afternoon meeting with some colleagues at CAPS.

Since getting back, I've just been working on cleaning up the C code, adding comments and so on.