Wed., Jan. 18th

OK, let's try the gelware version that I compiled before leaving yesterday, which tapped out the current-state bits of se_pulse_cap_tsedge_56.vhd.

OK, we seem to be stuck in state 1, "wait_fall" - that's the state where we're waiting for the falling edge.  This makes sense, because the students might have commented out the code that looks for the falling edge.  (Although I thought I told them we still needed a state for that.)

Looking at the code... The state register is enabled by the "write state" signal (wstate).  wstate should go high when wfall ("write fall time") is high.  wfall is supposed to go high in the "wait_fall" state when "just_fell" is high.  Aha, they commented out the computation of "just_fell."  No wonder.

Fixed that; now we seem to be getting real results.  Let me probe HD_3 (on J55 pin 2) with the pink probe.  Yep, that looks good too.  OK, I think we're ready to integrate the firmware now.

One thing though:  It looks like the current design is 'counting' the number of thresholds crossed (which is always 1) and passing this information along through the datapath and to the CPU.  This is unnecessary, and ideally it would have been simplified away when they first made the new datapath.  However, we probably don't have time now to go back and make this change.  We should probably just proceed with the design as-is.

Emailed the ECE senior design students about the result of today's testing; asked them to confirm where the latest version of the firmware (Nios C code) is sitting, so I can integrate it into the "master copy" on Q:\.

Remembered I still needed to test with the real timing-sync signal, from the DE3 board.  Hm, not getting reliable results now.  Signal too weak?  Need lower threshold?  Aha, looks like the DE3 is still producing a negative pulse, from when I was trying that.  Need to recompile for positive pulse.

OK, that's fixed.  The timing signal is being passed properly between the boards.  And its amplitude is larger now, for some reason (perhaps because that old 10-ohm short is gone now?) - it's ~1.6V now - plenty big enough to detect with a substantial threshold (say 0.8V) that would give us a healthy noise margin.

An alternative - we could set that pin to use a digital I/O standard like 1.5V, and then do away with that DAC level entirely - then we could allow that level to be part of the normal voltage ladder.  Trying that now.  (Made code changes; doing Quartus compile now.)  Due to substantial changes to pin assignments, I've set the current design under a new revision ID, COSMICi_FEDM_RevA.  The old pin assignments are still in the previous revision, "New_with_Nios_trim".

To summarize the present versioning information:

• Project revision is:  COSMICi_FEDM_RevA
• Firmware version number is presently:  0.10.
• Top-level Quartus file is presently named:  COSMICi_FEDM_top14.bdf  (internal version 0.15).

Oops, we got a fitter error - looks like there is a conflict between the possible VCCIO values for I/O bank 2 and the choice of 1.5V as the I/O standard for the TimingSig pin (which I chose to be K20).  What if I used a different pin, like H1?  (TimingSig fans out to 12 different input pins.)  Or better yet, W1?  That's in VREFGROUP_B6_N0, which isn't being used for anything else currently.  In fact, all of IOBANK_6 isn't being used presently.  (The previous two observations are from the Pin Planner.)  OK, let's try again with W1 as the choice for the TimingSig input, with a 1.5V digital I/O standard...  Yep, that fixed the fitting problem.  Burning now...

OK, that works, but the diagnostic outputs look a bit noisy.  Sometimes the state machine skips a state; this is not good.  Perhaps because W1 has a longer distance to travel across other circuits?  Let's try cleaning it up by disabling diagnostic outputs we aren't actively using.  How about we get rid of the bus outputs, and let the green probe just look at the have-data signal?  We'll have it be our only output.  It shouldn't interfere with the state machine, since it doesn't change until later.