FI-FO, FI-FO, the buffer's ready to go!

So, we are finished testing pulseform_cap (last thing Friday I changed it to 1/2 sec. between pulses) and so I suggested to the guys that they go ahead and hook it up to the FIFO and check the output of the stream_pulse_data.  We got nuthin'!

Then we looked at the handshaking signals to our_FIFO - they seem correct (toggling every 1/2 sec. with current pulse generator) but they aren't stalling after 16 cycles (when the FIFO fills up) as expected!

Then we looked at the raw signal to the FIFO megafunction, and it looks like the write signal is never being asserted.

Mike inspected his logic in his FIFO_writer module, and identified one possible bug.  We are recompiling now.  Still doesn't seem to be stalling correctly...  We did manage to find the write pulse though, after coaxing the scope into triggering properly.

OK, we are inspecting some more signals now.  The 2-bit state of the FIFO_writer module, and the 4-bit count from the FIFO of the number of stored entries.

OK, apparently FIFO_writer is actually working correctly now, the problem is that something is reading out the data shortly after it's added.  The bug could be in FIFO_reader!

Aha, saw from looking at the FIFO_reader state that it was getting stuck for 25 cycles, suggesting that the 25 words of data were getting streamed despite the absence of the pump signal.  Looked at the stream_pulse_data module, and indeed, the wait_pump_low state forgot to actually wait for the pump signal to go low before advancing the index variable configuration to go to the next word.  Fixed that, and now the output freezes after 16 pulses (after the FIFO fills up) as expected.  We can see the number of words in the FIFO increasing.

So anyway, we have pretty good confidence that the FIFO is working now, and (guys) it is now ready for stream_pulse_data to be tested more thoroughly by the new stub module, which will operate the pump handle as required and send output data to our scope bus.  The output words are 32 bits long, and you can ignore alternate ones (since they are just the upper 32-bits of the 64-bit words).  You might want to take just the low bytes of the other words, and do subtractions like in the other stub module, so that the time values in your output are all relative to the time of the first edge (leading edge of threshold 1).

Please feel free to text me with any questions you may have.