FPGA Host to Target FIFO Buffer Reset

[wtqp114514]

Hi All,

I got a question re. resetting a host to target FIFO buffer on the FPGA set up by labview.

The situation is as follows:

1. There is an FPGA FIFO buffer connected to a custom UART port that puts data to the FPGA IO pin as TX line,
2. The UART port shifts data to the TX line after the FPGA is powered on,
3. The PC with the FGPA is reboot, and the FPGA bitfile gets loaded,
4. The write from C API to the host FIFO buffer does not return error,
5. The UART port does not shift data from the FIFO buffer (verified with an oscilloscope).

I tried different UART implementations and made no difference. It seems the FIFO buffer receives the data but does not send it when it is received. 

Is there a way to "reset" the FIFO buffers?

Thanks for all your listening. 

[rolfk]

I have seen instances in earlier versions of LabVIEW where a FIFO gets into a unresettable state after it is overflown. Solution was to always check the remaining space in the FIFO before attempting to write data to it and make sure to never try to write more data to it than it has still free space.

Checking for the amount of free space can be done by executing the FIFO Write function with no data to write (empty array) and then observing the "Empty Elements Remaining" value.

Once the FIFO gets in that state, the only way to reliable reset everything was by reloading the FPGA.

[wtqp114514]

The UART data transfer failure apparently only happens after the chassis is rebooted. Cold boot is always OK. 

The FIFO buffer depth is 8191 elements with u8 data type. 

When I write to the FIFO buffer with 9 bytes data, the remaining write buffer elements is 20471. That made the total depth 20480 bytes, which is 2.5 times bigger than the actual buffer depth?

For "reload FPGA image", what is the "correct procedure" for it? Should there be need to reset the FPGA VI before reload?

Finally what I don't understand is - what is the difference on the FPGA when the chassis is rebooted vs. cold boot? 

[rolfk]

Not sure what is happening with your FIFO size. I know NI rounds the FIFO, or more precisely the DMA transfers, to a multiple of 64 bits, but that doesn't explain this difference at all.

As to restarting the FPGA, no I did not do a reset. Simply stop it, close the refnum, open a new refnum to the FPGA bitfile, prepare it and then start it. I do usually give a reset before starting just to be sure, but I seem to remember that that reset sometimes can actually make things not work, but not sure about the details.

Please note also that this was with an sbRIO-9651 and multiple types of cRIOs. I have no experience with FlexRIO and R series RIO. While the API seems to be similar or the same, they are separate drivers that need to be installed specifically for the respective hardware and that could make some of the details work differently.

As far as these things go, trial and error is often the only thing to deal with them. It's tedious at times but at the same time it's also impossible to expect everything to be fully documented in that respect. In fact it probably often is somewhere but finding that is like finding the proverbial needle in the haystack, and trying it out yourself is usually quicker.

[Intaris]

FIFO has multiple depth definitions.

One on on FPGA, One is on RT.

Make sure you've set both accordingly.

[wtqp114514]

I have a couple of questions (newbie):

1. What's RT?

2. I am using the C API to control the VI and while I can reset the top-level VI every time I restart the C control program (during startup) it does not make any difference and the problem of successfully writing to the FIFO buffer while no data appearing on its downstream UART seems to be the same. 

[wtqp114514]

As for restarting the FPGA, this is what I followed with the C API generated by the labview 2017:

1. Stop FPGA session,
2. Close  FPGA session, 
3. Open FPGA session and download the bitfile,

After rebooting the chassis, the NiFpga_Abort() returned -52018 when the application is started. Subsequently restarting the application there are no errors for reloading the FPGA but the UART comms never worked even the write to the FIFO buffer connected to the UART was successful. 

If I reload another FPGA bitfile and then load the correct bitfile, then the UART comms would work correctly. 

[rolfk]

RT is real-fime. The cRIO and sbRIO have a CPU in the chassis whuch runs an RT OS and the control application normally on this RT system rather than on your (Windows) host computer. 

The FIFO is of course writeable until it is full even if your FPGA doesn’t properly initialize and enter your loop that polls the FIFO. And that seems the problem. Somehow your FPGA does not go through its own initialization or doesn’t shutdown properly. You should not just yank everything out by closing the FPGA refnum. Instead you should of course have a way to inform every loop in the FPGA to properly terminate, for instance by setting a register (front panel control on the FPGA VI) andon starting up the FPGA make sure to initialize all these registers to proper values before entering your loops.

[wtqp114514]

The UART and write/read FIFO buffers are placed inside a single cycle timed loop (SCTL) with the 40MHz FPGA clock as the clock input. 

The UART reset is synchronous to the clock and specified to take 1 cycle to complete. 

There is no further "reset" for the read/write FIFO buffers. 

The FIFO buffers are the "built-in" data type in LabView 2017.