FPGA DMA elements to read returning zero

[AlexN908]

Hi all,

on a recent LabView FPGA project, I ran into a surprising behaviour I cannot make sense of. Hopefully someone has an idea how to solve this issue.

The system is an sbRIO-9632 programmed with LabView 2014.

Attached are screenshots of two programs that isolate the issue. Both programs are executing on the FPGA and waiting for data in a DMA (Host to target) channel. 'Working.JPG' is a single cycle timed loop which constantly looks for data in the DMA fifo buffer and sets a control output high if data are present. The channels goes high and low in a random order with 25ns spacing. This is expected as the FPGA reads data quicker than the host computer provides. 'NotWorking.JPG' is the same core with the addition of a counter which is decreased to zero before the next value is read. In the final program, this should give the host time to fill up the buffer. The "False" case of the structure decreases the number of the counter by one. If this program is executed, the channel never goes high but stays low all the time, indicating that there are no elementsin the buffer, however the filling is the same as in the other program so I do not see a reason why there shouldn't be any. I would expect that the DIO channel goes high for however many elements are in the buffer times 1s because there is the additional count-down between consecutive readouts.

If someone has an idea or spots an obvious mistake I have made, please let me know.

Alex

[RavensFan]

What is happening in the false case of the non-working VI?

In working, you could have a true or a false going out of the digital output depending on the value of the number of elements.  In non-working, are you also writing to the digital outuput in the false case? 

In either code, your outer while loop is worthless along with the final I/O node because your inner timed while loop will never end.

[AlexN908]

Hi RavensFan

Thank you for your reply.

Yes my outer loop does not serve any purpose but is a leftover of the original program I was working on while encountering this problem.

The false case in non-working does exactly the same as in the working case, it decreases the counter by one. In both cases, the digital output is not written. I expect the program to check for new elements in the buffer everytime the counter has reached zero, which it does because the digital channel is set, but it always claims there are no elements in the buffer. It seems as if I cannot delay the readout of the buffer? This seems very surprising, because I have done this in a different program with a slightly changed structure. The only difference was, that the program was started once the buffer is full, whereas the examples I posted are running while the buffer is filling.

Alex

[ZX81]

I have several conflicting ideas...

1. Have you checked the host for error messages posting into the FIFO?  You mentioned the code there is the same either way, but if the consumer end behaves differently, it may have an effect on the producer.  From the host, can you tell if elements are getting consumed?

2. Would you be able to run the FPGA in interactive mode (to see the front panel)?  You may be able to put the 40,000,000 count-down value on an indicator, or the [ i ] counter...  I rarely get probes to work in FPGA, but front panel displays on the top-level tend to work.

3. True, the FPGA is able to handle two writes to a hardware, but I recommend avoiding it.  a) if it works for your system, maybe you could stop writing in the 'false' case.  b) since the 'true' and 'false' cases both write to the same output bit, why not take the write outside of the case, and pass the value through a tunnel.

4. Are you sure the output is never on?  A 25ns pulse is hard to catch.  And since it looks like you only expect a value once per second, it's even harder.  (The actual pulse may be shorter; see #5)

5. The timed loop starts executing every 25ns.  That doesn't mean everything inside occurs at once, and timed like you might expect.  It's actually possible that the 'true' case checks for anything in the FIFO (taking 25ns), then writes a true to the output, but the timed loop starts the next iteration immediately (one primary clock cycle; may be 10ns, or even shorter), and the 'false' case writes a false to the output before the true shows up.  In a few cases, the hardware won't even be able to change states quickly enough, so the 'true' never actually changes a voltage level, no matter how fast your oscilloscope is.  Since you only want a value every 1 second, why not set your timed loop to a few milliseconds, instead.

[AlexN908]

Thank you for the input.

Elements are written to the buffer, as far as I can tell buy the "Remaining elements" functionality of the write function. Both cases return the same number. Surprisingly they are the same in consecutive calls, indicating that they are removed from the buffer in the mean time. As I am not resetting the FIFO on the host side, it seems that something on the FPGA is emptying it but not processing in the non-working case.

Yes, I could have missed the 25ns pulse, but I would put the probability for that quite low. The used oscilloscope should resolve down to approx. 5ns so even shorter pulses should be caught.

Although not having solved the issue, I got my program working by shifting the timeout logic to the realtime host. A program constalty running on the FPGA but only reading if a front panel element is set to true works without any problems if the host loads the data and allows a wait of several ms before enabling the control. In retroperspective, this approach is also simpler as it requries less resources. I am therefore tempted to mark this issue as semi solved with the advice to not use a construction as shown above for the various problems indicated in the posts.

A big thank you to RavensFan and ZX81 for their replies.