FIFO reports "Ready for Input" to be false despite never writing anything to FIFO

[nanocyte]

Here's my FPGA code

Here's my RT code

I would expect "Ready" to always be true because "enable" is staying false and there should always be room on the FPGA block ram.  But, when I run the above code on RT, the first time it reports 0 "not ready"s the second time I get 92 for "Not Ready" and the third time I get 184 meaning there were 92 cycles where the FIFO is unavailable. Is that expected behavior?

I should add that I'm running this on an NI Linux RIO target (sbRIO 9627)

[Artem.SPb]

Your buffer 1000000 points. And as I see, you run FPGA code at 80 MHz. So, for full FIFO enough 1/80 sec or 12,4 ms. May be your RT code can't take data from FIFO enough fast.

[nanocyte]

The enable boolean is always false. There should be no actual data being transfered.

[Artem.SPb]

Oh, I see. Try use FIFO.Start after FIFO.conf.

[nanocyte]

I tried and it makes no difference

[dkfire]

Are the FPGA running? 

I don't see a Start for the FPGA. 

[nanocyte]

I have "Run" set in the configuration of "Open FPGA VI Reference" and I don't see how "not ready" could be incrementing if the FPGA wasn't running.

[yamadj]

Hello nanocyte,

Thanks for the post! I think there might be a mix up in our understanding of "Ready for Input".

According to the help manual "Ready for Input returns TRUE if this node is ready to accept new input data." 

Write (FIFO Method) - https://zone.ni.com/reference/en-XX/help/371599K-01/lvfpga/fifo_write/

This mean that it will only be true once it finishes an operation. So if we never finish an operation since we never get "Input Valid" as true, we shouldn't expect "Ready for Input" to be true either. I believe what you are seeing in "Not Ready Count" is expected.

Moving past that, if you have a specific throughput applciaiton in mind this interface method would make more sense.

There is a good walk through of how handshaking is supposed to work in the walk through below.

Scheduling Timing Using Handshaking Signals (FPGA Module) - http://zone.ni.com/reference/en-XX/help/371599F-01/lvfpgaconcepts/fpga_handshaking/

[nanocyte]

A) Why wouln't the node be ready for input before it's completed some operation?

B) If that were the case, we'd expect ready to always be false and that is not true either. I can run the FPGA in interactive mode and it would be a free running counter but that is not the case. I could put a delay in after the first "not ready count" read and expect a different number on the second read. That's not the case either. Ready is false for 92 itterations some time after my last  "not ready count". It seems sort of arbitrary and a little scary.

[T-REX$]

Hey Nanocyte,

Do you ever do a manual 'Download' method call from the host (after that 'Not Ready 2' read)? Could you try placing one right after the open?

What is the behavior if you copy-paste your code again, so that you have 'Not Ready [1-4] all in series at the end?

Try wiring an initial value of 0 to that feedback node on your counter. Does that change the behavior between runs? (you could potentially do this instead of my first suggestion).

I'd expect your first 'Not Ready Count' to be 0. Then you're reconfiguring the FIFO, which means you're stopping it if it's running, configuring the host-side buffer, then restarting it when you do your next read. I think (guessing here) 'Ready for Input' is going false while that configuration is happening, even though the FPGA-side buffer has plenty of room available. It goes up by 92 each time you run this because the memory for that feedback node isn't being reinitialized between runs.

Another theory is that a reset is happening, and the synchronization between your logic (80MHz) and the DMA bus logic(125MHz?) takes 92 cycles to happen.