LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Managing FPGA FIFOs in the Project

Hello everyone,

 

I am developing software for data acquisition on CompactRIOs. It supports a few types of C series modules, the unit itself can be assembled with various amount and type of modules. Each of the module type uses separate DMA FIFO at the moment and I have difficulties managing it through the project.

 

I can assemble units like this:

3x NI9232, 1xNI9226, 2xNI9421

or like this:

1x NI9232.

 

Here is how I work with it at the moment:

 

Project - I manually set up modules under target. I have DMA FIFOs set for all the possible modules, even for those which are not needed for the run. When the DMA FIFO is not used in FPGA, it is optimised out in the FPGA code. I manually adjust the DMA FIFOs size depending on the number of modules.

 

FPGA - for each needed module type there is a disable structure. Before I build the FPGA, I manually enable the case designed for specific amount of modules of given type - for 0 modules of that type, there is empty case, for 2 modules there is while loop with reading 2 modules etc. If I did not use the disable structure and would for example use 0 modules of that type on a target, LabVIEW would not like the code for 2 modules and it would throw an error. Disabling such code makes it work.

 

RT - I process the DMA FIFOs in separate loops. Before loop, there is an initialization of FIFO and reading info about DMA FIFO that FPGA provides (sampling and number of channels). Inside the loop, I read the data, split it into separate channels and write it in an RT FIFO array. Because the unused DMA FIFOs are optimised out in the bitfile, I cannot just simply use Read DMA FIFO in RT and ensure that such code doesn't execute when DMA FIFO is not present; LabVIEW says the code is faulty because Read DMA FIFO points at FIFO that is not in the bitfile.

 

So, I use Conditional Disable structure in every place and every VI that works with that FIFO. The code currently supports about 7 module types and adding a new one is a tedious process. In the Project, I manually set the conditional disable symbols for each target (like "9232_FIFO = TRUE") but I feel like this is not the way it should be done.

 

Would classes solve this for me? Are there any bad and good practices when developing code for targets that vary in complexity?

0 Kudos
Message 1 of 4
(2,685 Views)

Hi Thomas,

 

does your current requirements allow to use only one (or two) FIFOs?

If yes: send the data over the FIFO(s) with an additional data value to denote the related module/channel (similar to a cluster containing an enum and some variant data, but in the FPGA encoded in U32 or U64 values)…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 4
(2,671 Views)

Here's a different approach for you.

 

Instead of putting disable structures or conditional disables around the code, why not place a regular case structure. If you then create a top-level VI which accepts a cluster of booleans for the individual modules, it will compile out to the same thing. Then you can have multiple top-level VIs calling the same core VI (with a cluster of booleans as an input) and all is good.

0 Kudos
Message 3 of 4
(2,639 Views)

@Intaris wrote:

Here's a different approach for you.

 

Instead of putting disable structures or conditional disables around the code, why not place a regular case structure. If you then create a top-level VI which accepts a cluster of booleans for the individual modules, it will compile out to the same thing. Then you can have multiple top-level VIs calling the same core VI (with a cluster of booleans as an input) and all is good.


I already explained why it is not possible. If I did not use the disable structure and would for example use 0 modules of that type on a target, LabVIEW would not like the code for 2 modules (because the read FIFOs are not present in the bitfile) and it would throw an error. Disabling such code makes it work.

0 Kudos
Message 4 of 4
(2,590 Views)