Wed., Nov. 2nd

Plan for today is as follows (or at least, as far as we can get on this):

1. [/] Recompile latest firmware into gelware image (.sof/.pof files).
2. [/] Burn new .pof file to EEPROM (set as baseline code to revert to on power-up).
3. [/] Import files from Juan & Mike's new 56-bit version of datapath into master project folder.
4. [/] Do a test compile; fix any problems.
5. [/] Inspect space remaining (all types) after fitting.
6. [/] Check maximum PLL clock speed in timing analyzer.  Increase PLL clock speed if possible.
7. [/] Determine whether further compression of datapath will be necessary to add 3rd datapath.
8. [/] If not, add 3rd pulse-capture datapath to design
9. [/] Wire up LVDS inputs for "PMT #4" input to 3rd datapath (if not already).
10. [/] Recompile design with 3rd datapath, check space remaining & maximum clock speed again.
11. [/] Use Dremel tool to file down a 3rd SMA connector, populate it on "PMT #4" footprint.
12. [ ] Work with Ray to set up 3rd paddle/guncase assembly, connect it to board.
13. [/] Adjust firmware to look for data on all 3 input capture datapaths (currently it just checks 2).
14. [,] Do a first run gathering data from all 3 detectors!  This will be the acid test of the new 56-datapaths, to make sure that none of those design changes screwed up the functionality.

Here we go:

Task 1.  Starting Quartus license server.  Starting Quartus on Q:/COSMICi_FEDM.qpf project, New_with_Nios_trim revision.  Starting full compile with the latest .hex files (hexadecimal memory initialization files containing the latest compiled firmware).  This will take a while...

It occurs to me that it might be nice, at some point, to introduce a version identifier for the gelware too; this could be implemented as (for example) an LPM_CONSTANT megafunction that feeds a PIO input to the Nios core, which the C code can read and then report in the FEDM_STARTING message.

Compile successful (of course; nothing changed but the .hex files).  Some stats:

• Slow corner fmax for high-speed counter:  211.28 MHz
• Logic utilization:  24,314/27,104 (90%) =  2,790 remaining
• Dedicated logic registers used:  21,878/27,104 (81%) = 5,226 remaining
• M512 blocks: 193/202 (96%) = 9 remaining
• M4K blocks: 144/144 (100%) = 0 remaining
• M-RAM blocks: 1/1 (100%) = 0 remaining (but we may be able to use a bit more of the space)

Task 2.  Starting C:\SHARED\Server Code\COSMICi_server.py; it pops up its windows.  Powering up Mastech supply at ~4.5V driving fan (on metal block on FPGA), and then powering up Agilent supply at 5V driving FEDM + (via FEDM) WiFi board.  Total current draw: 2.11A.  Actually it just occurred to me I could power the fan from the same supply.  Now the total current draw is about 2.21A peak (fluctuating due to the EMF feedback from the fan motor).  Hope the voltage level isn't too unstable for the application.  It seems to be fine.  A new set of windows popped up of course when I power-cycled (b/c the Wi-Fi drops the old connections).  OK, let's burn the new firmware in there.  Switched burner to Active Serial mode, selected New_with_Nios_trim.pof file, added ByteBlaster hardware, doing program/configure + verify.  Finished programming; new firmware (0.7) is now installed and running.

Task 3.  I think I put Juan & Mike's new code into the C:\LOCAL\q91_56\ folder.  I need to copy all the _56 design files from there to Q:\, and then merge their changes to the toplevel schematic into a new version of my toplevel schematic, and then set it as the new toplevel file.

Let's do this in Cygwin.  cd to /cygdrive/c/LOCAL/q91_56 and type "ls *_56.*", and get:

COSMICi_FEDM_top9_56.bdf
FIFO_reader2_56.bsf
FIFO_writer2_56.bsf
cs_combine_56.bsf
cs_combine_56.vhd
cs_combine_56.vhd.bak
fifo_reader2_56.vhd
fifo_reader2_56.vhd.bak
fifo_writer2_56.vhd
fifo_writer2_56.vhd.bak
hspeed_counter_56.bsf
hspeed_counter_56.v
hspeed_counter_56.v.bak
our_fifo2_56.bdf
our_fifo2_56.bsf
our_fifo_v3_56.bdf
our_fifo_v3_56.bsf
pmt_ic_datapath2_56.bdf
pmt_ic_datapath2_56.bsf
pmt_ic_datapath_v3_56.bdf
pmt_ic_datapath_v3_56.bsf
pulse_cap_56.vhd
pulse_cap_56.vhd.bak
pulse_combine_56.bsf
pulse_combine_56.vhd
pulse_combine_56.vhd.bak
pulse_prep_56.bdf
pulse_prep_56.bsf
pulseform_FIFO_v2_56.bsf
pulseform_FIFO_v2_56.qip
pulseform_FIFO_v2_56.vhd
pulseform_cap_56.bdf
pulseform_cap_56.bsf
se_pulse_cap_56.bsf
se_pulse_cap_56.vhd
se_pulse_cap_56.vhd.bak
se_reg_en_56.vhd
se_reg_re_56.vhd
se_reg_re_56.vhd.bak
stream_pulse_data_56.bsf
stream_pulse_data_56.vhd
stream_pulse_data_56.vhd.bak

Great.  Now doing "cp *_56.* /cygdrive/q".  That is done.  Now in Quartus, opening for inspection "COSMICi_FEDM_top9_56.bdf", which is their new top-level file.  Basically, the only thing that should be changed in it is the new datapath implementations, pmt_ic_datapath2_56 (M512 fifo block type version), and pmt_ic_datapath_v3_56 (Auto fifo block type version).  

Oops, they forgot to create pulseform_FIFO_56 using the M512 blocks, use pulseform_FIFO_56 in their our_fifo2_56, and use pulseform_FIFO_v2_56 in their our_fifo_v3_56.  Did that for them.

Created new _top11 version of top-level schematic, added appropriate version comment, replaced the two ic datapath blocks with their new versions. Also replaced hspeed_counter with hspeed_counter_56.

Task 4.  Doing test compile...  Oops, forgot to replace the high-speed counter with new version.  Fixed that.  Forgot to add some .vhd components (not automatically included) to project.  Fixed that.  This is going to take a while, so I'm going to get a soda...

Compilation successful!

Task 5.  Let's look at the stats:

• Slow corner fmax for high-speed counter:  213.13 MHz (only slightly better)
• Logic utilization:  22,007/27,104 (81%) =  5,097 remaining (almost 2x as much left)
• Dedicated logic registers used:  19,463/27,104 (67%) = 7,641 remaining (about 25% better)
• M512 blocks: 188/202 (93%) = 24 remaining (more than 2x better)
• M4K blocks: 144/144 (100%) = 0 remaining (same as before)
• M-RAM blocks: 1/1 (100%) = 0 remaining (same as before)

This is, I think, about as I had expected. 

Task 6.   It's not yet possible to increase the PLL speed.  Will probably need to use LogicLock first.

Task 7.   Let's look at the resource usage of each ICDP now:

pmt_ic_datapath2_56 (M512 version, 4 pulses):

• Block memory bits:   2,700
• Combo ALUTs:          2,442
• Logic registers:          5,598
• M512 blocks:             38

pmt_ic_datapath_v3_56 (Auto version, 8 pulses):

• Block memory bits:    0
  
• Combo ALUTs:           2,410
  
• Logic registers:           11,576
  
• M512 blocks:              0

I don't think further compressions of the datapath will be needed.  The actual FIFO in the latter one is 6,083 logic registers, so if we cut it in half, we might save about 3,000 logic registers, I think at this point we might be able to fit two copies of it in the design.  Let's try.

Task 8.  Added 3rd input capture datapath on channel 2 of type pmt_ic_datapath_v3_56.

Task 9.  Wired up its LVDS inputs, skipping the one for DAC #2, as with the other datapaths.

Task 10.  Starting Quartus compile.  Compile successful!  Let's look at the stats:

• Slow corner fmax for high-speed counter:  212.49 MHz (only slightly better)
  
• Combinational ALUTs:  10,017 / 27,104 (37%)
• Dedicated logic registers used:  25,678/27,104 (95%) = 1,426 remaining
  
• Logic utilization:  26,664/27,104 (98%) =  440 remaining
  
• M512 blocks: 188/202 (93%) = 24 remaining (same as with 2 datapaths)
  
• M4K blocks: 144/144 (100%) = 0 remaining (same)
  
• M-RAM blocks: 1/1 (100%) = 0 remaining (same)

We probably will still need to free up some space before we can add the extra timing-sync edge-capture datapath.  We might conceivably be able to do that by getting rid of extra_RAM, and using more of the M-RAM (extra 8K in there, not currently allocated to anything).  If not, then we will have to shrink down the main input capture datapaths (and/or the firmware code size) further.  We could recompile with optimization for minimum code size turned on, and see if that lets us shrink the size of our RAM blocks.

Task 11.  While compile was running, Dremeled down the pins of another SMA connector to fit the thru-hole footprint.


Task 12.  Ray is out swimming.  Texted him that we need the 3rd guncase soon.


Task 13.  Back now in the Nios II design tools for Eclipse IDE, changed the value of NCHANS_TOBUF from 2 to NCHANNELS (i.e., 3) in pulsebuf.c.  This should cause the coincidence detector to now expect to receive pulses on all 3 input channels, and look for coincidences between any pair of them.  (Further filtering for 3-way coincidences can be done on the server side.)  I'll wait to recompile with this option until the Quartus compile is working.  OK, that's done now; recompiling the project.


Task 14.  Testing will have to wait until we get the 3rd detector hooked up.  I want to talk to Ray about that before putting it together to make sure it's OK with him to use a given paddle.  Well, we could hook the board up and test it with just two detectors, but that will confuse the coincidence-detection algorithm.  In the meantime, while waiting for the 3rd detector, I could perhaps start working on adding stuff to the gelware to allow us to positively verify the absence of a pulse in a given time interval.  Actually, it might be a good idea to first just do a test with the 56-bit version using just the first two channels.  Or, I could synthesize fake pulses on the new channel!  That last idea is probably best.

Doing another Quartus compile to pull in the new .hex files (to support the triple datapath).

Just remembered there are a couple more places in the firmware where I assumed there are only 2 input channels.  Going back & fixing those now...  In the NONCOIN_PULSES message...  Was that it?  I think so... Recompiling firmware & Quartus design again.  In the last compile, Quartus hung in the assembler (as it sometimes does).  Killing it and restarting.

Meanwhile, I hooked up the function generator to the "PMT#4" input port (which we're using as the new channel 2).  It is now outputing a 100 Hz, inverted, +2.5V pulse with 100 ns pulse width, 20 ns rise time, and 130 ns fall time, which makes it an asymmetric triangle (sawtooth) pulse.  Checked the pulse profile on the scope to make sure it looked OK.

Just remembered, I forgot to add the DC bias jumper for the new input port.  Checking the OrCAD schematic to confirm which one it was.  It is J63.  Adding an orange Adafruit F-F jumper there (I am out of bridges). Now I am ready to test, as soon as the Quartus compile finishes.  There, that's done.  JTAG programming new design... It's running.  Seems to be working as expected.  Here's an output sample:

Wed Nov 02 18:00:16 2011 + 636 ms: <
Wed Nov 02 18:00:16 2011 + 637 ms: < FEDM_STARTING,v0.8
Wed Nov 02 18:00:16 2011 + 842 ms: <
Wed Nov 02 18:00:16 2011 + 842 ms: < DAC_LEVELS,-0.200,-2.500,-0.299,-0.447,-0.669,-1.000
Wed Nov 02 18:00:16 2011 + 843 ms: <
Wed Nov 02 18:00:16 2011 + 843 ms: < FEDM_READY
Wed Nov 02 18:00:17 2011 + 915 ms: < NC_PULSES,245837961,201,100,123
Wed Nov 02 18:00:19 2011 +  37 ms: < NC_PULSES,469189411,203,90,112
Wed Nov 02 18:00:20 2011 + 223 ms: < NC_PULSES,706924408,201,90,119
Wed Nov 02 18:00:21 2011 + 456 ms: < NC_PULSES,954722914,205,94,123
Wed Nov 02 18:00:22 2011 + 670 ms: < NC_PULSES,1196743610,203,107,122
Wed Nov 02 18:00:23 2011 + 793 ms: < NC_PULSES,1422506353,202,98,112
Wed Nov 02 18:00:24 2011 + 873 ms: < NC_PULSES,1638620374,200,96,108
Wed Nov 02 18:00:26 2011 +  66 ms: < NC_PULSES,1876744706,200,94,120
Wed Nov 02 18:00:27 2011 + 371 ms: < NC_PULSES,2136745128,202,121,130
Wed Nov 02 18:00:28 2011 + 756 ms: < NC_PULSES,2414745580,203,104,139
Wed Nov 02 18:00:30 2011 +  53 ms: < NC_PULSES,2674182865,204,108,129
Wed Nov 02 18:00:31 2011 + 226 ms: < NC_PULSES,2908746387,203,91,118
Wed Nov 02 18:00:32 2011 + 354 ms: < NC_PULSES,3134746760,204,81,113
Wed Nov 02 18:00:32 2011 + 849 ms: < PULSE,2,1,3233112444,3,(0,(1,(1,3),4),2)
Wed Nov 02 18:00:32 2011 + 850 ms: < PULSE,1,1,3233112445,2,(0,(3,1),6)
Wed Nov 02 18:00:33 2011 + 493 ms: < NC_PULSES,3361671587,200,92,113
Wed Nov 02 18:00:34 2011 + 836 ms: < NC_PULSES,3630432436,201,116,134

Explanation:  The verbose timestamps at left (before the ":") are just when the server logged the data; they are not particularly accurate as event times (at best, to the 10s of milliseconds).  The "<" means this is input from the board (as opposed to output to the board on the return connection).  The FEDM_STARTING message says that the board has powered up, and gives the firmware version number (0.8 is the new version for 3 datapaths).  DAC_LEVELS message is there as a diagnostic to tell us what are all the voltage thresholds we set (relative to the +2.5V input bias).  This is a logarithmic ramp from -200 to -1000 mV, except that the 2nd value is null (-2.5) because that DAC is broken anyway.  FEDM_READY just tells us the firmware is entering the main loop.  NC_PULSES tells us how many non-coincidence pulses we have tallied up from each input channel as of a given (fairly arbitrary) point in time; this time is marked approximately by the arrival time (first threshold edge-crossing time) of the most-recently-arriving pulse in the tallied set, expressed in cycles of the high-speed counter.  PULSE expresses actual data about a pulse that is potentially a member of a shower, i.e., it arrived within +/- 50 ns of a pulse on another channel.  The fields are: Input port number (1, 2, 3); sequence number (out of coincidence pulses reported on this port), first edge-crossing time in HS clock cycles, number of thresholds crossed (1-5), time deltas (in HS cycles) between subsequent edges.  The ones after "(" are rising edges; the ones before ")" are falling edges.

A little later in the dataset (8 minutes later), we see an accidental coincidence between one of our synthesized pulses on port 3, and a real pulse on port 1.  This is evidence that coincidence detection is working between any pair of ports (not just ports 1&2) and that as expected the synthesized pulse crosses all 5 thresholds.  Its total measured width is 38*5 = 190 ms, which is about right considering its FWHM is synthesized at 100 ns and that we miss a little of the base (before it gets to -200 mV).

Wed Nov 02 18:08:21 2011 + 129 ms: < PULSE,1,17,96886924398,2,(0,(2,2),7)
Wed Nov 02 18:08:21 2011 + 130 ms: < PULSE,3,1,96886924408,5,(0,(1,(0,(0,(1,25),4),4),2),1)

One final note:  On power-up, the Wi-Fi script currently does not start up quite quickly enough to catch all the initial output from the FEDM board - so the earliest output (including the startup message and DAC levels) gets lost.   To prevent this, the FEDM firmware needs to be changed to actually wait to receive the WIFI_READY message before it turns on the input capture datapaths and starts streaming data.  However, this could create a problem in cases where the WIFI_READY message has already been sent earlier (like when restarting the FEDM via the JTAG).  There are a couple of ways to handle this:  (1) With a timeout, or (2) if WIFI_READY isn't seen within an expected interval, have the FEDM send a "PING" message to the server, which responds with a "PONG" that gets relayed via the Wi-Fi script to the FEDM, thereby confirming to the FEDM that the wireless link is up and running.  I can also work to reduce the Wi-Fi script's startup time (a lot of it right now is just unnecessary diagnostics), or (perhaps simplest) add a fixed delay in the FEDM firmware to give the Wi-Fi board time to start up.  Think about the various possible combinations of options here, & start working on them another day.

In other news, I started looking at the Senior Design students' report, & writing comments on it.  Emailed it to Ray and he also read it.  Ray (and I) noticed some lingering confusion about the project requirements in a number of places, and a general lack of specifics about the proposed cooling system design.  The students' presentation is scheduled for Friday, so we can give them our verbal feedback then.  I am hoping to get my written feedback done by tomorrow, so we can return the graded reports in class.