End of Summer Semester

Today was Jacob's last day before grad school, and David's and Abraham's last day for the summer.  We had a little good-bye lunch for Jacob.

Today David and I tracked down several problems.  However, we are still running the fast clock at only 125 MHz and so our time resolution is only 4 ns.  But, at least things are working reliably now!

We figured out why we weren't seeing all the thresholds on the scope - off-by-one error in the signal numbering.

We tracked down why the last threshold was messing up (cs_combine was returning the handshake too quickly) and fixed it...

Things are running much more smoothly.  We are able to handle pulses at a rate of 50 per second (20 ms period between them).   Values are clean and correct.

We figured out how to automatically generate the .hex file for memory initialization.  New target mem_init_install in the project build targets.

After David left, Darryl and I worked on a problem where the software was occasionally hanging.  By adding diagnostic printf()s, we determined that somehow the ISR was getting repeatedly called but with no interrupt flags (specifically, edge-capture flags) set!  This is crazy since the edge-capture flags are the only interrupt flags that should get set.  AHA!  I just noticed in SOPC builder that I had set the PIO to level-sensitive instead of edge-sensitive IRQ.  No wonder!  Now recompiling with that fixed...

I think I figured out how to add mem_init_install to the targets automatically built for the application project.

I modified the handler for BUF_FULL so that it goes ahead and assumes that stream_pulse_out is ready and begins the sequence to pull the data.  This seems to have fixed our problem where the system would hang on BUF_FULL interrupts that for whatever reason come in before (or between, or separately from) the corresponding HAVE_DATA interrupt.

Things are in really good shape now, running really smoothly and reliably, at 150 MHz now (300 Msps).  This gives +/- 1.67 ns precision for time measurements which is at least within a factor of 2 of our target.  I'm thinking that we should proceed with application development, testing with real PMT pulses, etc., while leaving improved performance as an important background task.  We could possibly push it over 150 MHz a bit even, without any changes...  To 160 or 170 maybe.  To try later...  I'm not sure I'm coming in tomorrow.  Next week...