Tuesday, January 17, 2012

Tue., Jan. 17th

The Quartus compile I started Friday finished after I left.  First thing I did today:  Burned it into the FEDM.  Next major thing on agenda:  Debug the timing input capture datapath (which is still producing no output with stream_pulse_test_out).

David texted that he is working from home on the paper today (and that this is OK with Dr. O'Neal).

OK, let's debug.  First, let's look at the HAVE_DATA signal from the timing-edge input capture datapath; this is HD_3.  If it's not rising, then that would explain why nothing else is working.

The HD_3 node is already tapped out to J55 pin 2.  Let's take a look at it...  Let's use channel 3 (previously used to monitor the threshold level from DAC#6).  Current scope configuration is:
  • Channel 4 (green) - J60 pin 1 - PMT_3 node (TimingSig)
  • Channel 2 (blue) - J79 pin 1 - pf3[5] - Output of comparator between TimingSig and DAC#6
  • Channel 3 (pink) - J55 pin 2 - HD_3 - HAVE_DATA output from tsedge_datapath_v1_56
Pink stays low.  So now, we're going to have to dig into the internals of the datapath to figure out why it's hosed.

First, let's see if the DP is reporting that it's stalled.  Hooking up the sync_error status output flag to pin T7 --> J46 pin 2 (behind J49, the DE9 header).  Since the input signal TimingSig is a known factor now (coming from the Waveform generator), we'll trigger off of the blue comparator output instead, and cannibalize the green probe (channel 4) to monitor sync_error.

Current scope configuration is:
  • Channel 2 (blue) - J79 pin 1 - node pf3[5] - Output of comparator between TimingSig and DAC#6
  • Channel 3 (pink) - J55 pin 2 - node HD_3 - HAVE_DATA output from tsedge_datapath_v1_56
  • Channel 4 (green) - J46 pin 2 - node sync_error - status flag output from  tsedge_datapath_v1_56
At this point we have to recompile in Quartus, since sync_error wasn't already tapped out.

OK, that compile finished and I burned it too the board.  sync_error is staying low, so tsedge_datapath_v1_56 isn't getting stalled (or at least, isn't detecting that it's stalled).  Let's crack open tsedge_datapath_v1_56.  The first part of it (which produces sync_error) is pulseform_cap_tsedge_56.  Let's look at its handshake output, hs_prod.  Let's tap it out.

Calling it int_hsprod_tap (output port of tsedge_datapath_v1_56) --> int_hsp_debug (top-level node) --> PIN_E12 --> J48 pin 2 (behind DE9 connector).

Let's cannibalize scope channel 3 (pink) to inspect it.  Current scope config is therefore:
  • Channel 2 (blue) - J79 pin 1 - node pf3[5] - Output of comparator between TimingSig and DAC#6  (Triggering on this one.)
  • Channel 4 (green) - J46 pin 2 - node sync_error - status flag output from tsedge_datapath_v1_56
  • Channel 3 (pink) - J48 pin 2 - node int_hsp_debug - Tap out of internal producer handshake from inside tsedge_datapath_v1_56.
OK, nothing from that either.  Therefore, we're going to have to crack open pulseform_cap_tsedge_56, to figure out why it isn't generating its producer handshake output (port hs_prod).  The internal node is named "prod".  It comes from pulse_combine_tsedge_56.  However, before this point is another, internal handshake, the hs_datarec output from pulse_prep_tsedge_56, which feeds into the hs_data1 input of pulse_combine_tsedge_56.  Let's tap this out and inspect it.  I'll just use the same output path as before.  Recompiling now...

Nope, nothing there either.  Now we have to crack open pulse_prep_tsedge_56.  Inside there is another internal handshake, between the hs_prod output of se_pulse_cap_tsedge_56 and the hs_prod input of cs_combine_tsedge_56.  Let's call that node int_prod_hs, and tap it out as port int_phs_tap, and again we'll reuse the same output pathway as before.  Again, it should come out on the pink trace.

Still nada!  Let's look inside se_pulse_cap_tsedge_56.vhd.  Let's tap out the current-state bits.  We'll put them on digital input bus 2 (B2) on the scope, taking them out on pin 1 of J76 & J77 (replacing pf3[1..0] which we aren't using).

Doing the Quartus recompile... I have to leave now for the EEP workshop; we'll have to continue this tomorrow.

No comments:

Post a Comment