[FPGA] is there a way to change initial memory contents in the LVBITX file?

[jt_fuw]

Hardware: Compact RIO 9039 or similar (RT part runs Linux).

I would like to use the same LabVIEW FPGA program with different initial data in its memory; some solution is to put in the FPGA program an interface (using some communication with the RT part) for loading the data and then allowing the rest to run.

But it might be more convenient to run a program in the RT part which will read the LVBITX file and create another, having a new initialization data for the memory. Is there a way to modify the LVBITX file to get it?

Xilinx provides an 'updatemem' utility for replacing memory contents in a compiled (binary) FPGA program, but seems it doesn't handle LVBITX files.

Thanks in advance, Jerzy Tarasiuk

[Terry_ALE]

LabVIEW FPGA supports what you are asking for but not the way you indicate.

In other words, a LabVIEW FPGA bitfile has MMRAs (registers) which can be set from the host software before the bitfile is run.  None of the Xilinx or more advanced techniques you mention may be needed.

[jt_fuw]

I understand that the VI must receive the data for the memory when running, and you suggest to use a control (LabVIEW object accessible from the Real-Time system as a memory-mapped register) to transfer the data.

As well as I know, it provides no ability to know that no data was lost due to delays (but it is likely that FPGA will read much faster than the data can be transferred; I am not sure about writing from the RT program to the register - what happens if the program attempts to write data too quickly?), unless using additional control and indicator for synchronization signals (e.g. the RT program puts data, then address, and the FPGA program outputs the same address; then the RT program detects the address change and can put another data and another address...).

I suppose a more efficient way is to use Host-to-Target FIFO to send the data. The FIFO has an inherent handshaking and can accept a block of data. Again, a control (for the address) and an indicator (now for data word count) are needed.

* The VI waits for a data in the FIFO, then gets the address from the control, saves it, and starts getting data from the FIFO and putting it to the memory, using consecutive addresses and counting data words; when the FIFO has no data, the VI adds the word count to the indicator value, and examines the control - a change of the address in it will mean a next transfer to a new address, a value of -1 will indicate end of the memory loading.

* The RT program at first puts an address to the control, reads and saves the indicator value, waits a while and puts all the data to the FIFO, then waits for the indicator value change, expecting the change to reach count of words that were sent; then the program can put a new address for another transfer, or a -1 to terminate the memory loading, for the VI to start processing the data.

[Terry_ALE]

I do not have enough information on your application to determine if an MMRA or DMA-FIFO is best (or a combination of the two) is needed.

MMRA: https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgaconcepts/pfi_data_transfer/

DMA-FIFO: https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgaconcepts/fpga_dma_how_it_works/

MMRAs do not require synchronization.  The value written can be read back to confirm it is has been set.  Sometimes a counter or other status is checked to create our own application specific check.

MMRAs are much lighter in terms of resources.  If setting say a gain value it may not be good to use a whole DMA-FIFO for something that gets set once.  For say waveform data a FIFO may be mandatory as we want high throughput lossless data transfer.

[jt_fuw]

I tried a simple program in the FPGA: 240MHz SCTL containing a control connected to an indicator, and an RT program which was writing the control (a different value each time), reading the indicator and waiting till the written value was read. On cRIO-9039 It shown that RTT (round-trip-time) of the communication is about 7.25 usec. I was using 64-bit values, so it needed 0.9 usec for a byte. Using a FIFO I obtained data rate over 120 MB/sec - over 100 times better (sending and receiving 2 kB blocks).

The cRIO-9039 has 16 DMA channels for FIFO-s, and I will not use all of them. And I plan to use the FIFO for communication between the FPGA and RT also later.

"The value written can be read back to confirm it is has been set" - does it mean that when the RT program reads the value that was written, the FPGA program has it? It is likely, looking on measured RTT - seems it takes slightly more (I see 7.34 usec).

I did these tests using the C API - seems all requests go through OS calls and likely they cause most of the delay seen. But I don't know how to get a direct access.

[Terry_ALE]

MMRAs are lossy but lower latency.  DMA-FIFOs are lossless and throughput optimized.

I would not use the C API to develop.  LabVIEW to LabVIEW FPGA (and RT) is best at first and then switch to C API for delivery.