LabVIEW FPGA Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Many data streams contain information for multiple channels or multiple samples. Today one must pack this data into larger integer types or interleave the data manually into multiple writes to the DMA FIFO API. It would be much simpler if the DMA natively support cluster and array data types. The local FIFO, Memory, and Register APIs already support this; extend it to DMA.

I didn't find something related to this, so I hope it's a new idea.

I use frequently VI scripting on LabVIEW, it is very useful for example to generate template VI's.

but this feature doesn't exist under FPGA, I mean some code is specific to this module, and I think it would be great to be able to generate FPGA VI's programmatically. For example in my job we make FPGA programming for Magnet Security. Even if global structure is the same for all magnets, we have to adapt a lot of things depending on type of magnet and instrumentation available. The idea would be to create ourself a kind of Magnet Safety Editor based on VI scripting specific for FPGA in order to allow non-programmers, but Magnet specialists, to generate themselves an adapted security system.

It's just an example, but when we see powerful of VI scripting for LabVIEW, it would give great results if it extends to FPGA, and even Real-Time  module, why not? 

Basically I want a VI like open FPGA VI ref which takes a RIO interface and returns a reference, except that it doesn't deploy a reference if one doesn't exist. It would instead pop out a boolean or error if you try to get a reference and there is no bitfile already deployed.

 

Two use cases I have in mind:

 

-Imagine if you need a cRIO to start working ASAP so you deploy your bitfile to flash and tell it to run on power-up. You still have to package the exact same bitfile with your RTEXE, even though its already deployed. This increases the size of your RTexe significantly. Lets say you version your RTexe and don't version the FPGA deployed to flash. Depending on what the signature check is, obtaining a reference to your bitfile may cause the "new" bitfile to be redeployed, eliminating the advantage of loading your bitfile onto flash in the first place.

 

-Imagine if you have a framework like veristand where you need to use a single bitfile in multiple locations which were written by different developers and possibly released at different times. The tools on NI labs (https://decibel.ni.com/content/docs/DOC-35574) help a lot and let you, once you have a reference, confirm the reference has all the interfaces you need to run your code. However, if you need to share references between code modules you must still be sure to obtain it in just one place and then share the reference yourself using a global or FGV.

 

Having the RIO driver solve this would be very helpful.

Hello,

 

I would like strongly suggest to support a driver for Spartan-3E-1600Kgate Development Board.

 

Thanks

Currently, FPGA palette is specific to target use din the LV project. It could be a great idea to have a common part in this palette to add drivers/functions without regarding target type.

I would like to select which FPGA resources (DMA FIFOs, front-panel controls) are used by a host VI at run-time. This would make it possible to implement multiple copies of the same function on an FPGA and control them with the same driver, passing in a reference to the appropriate resources. For example, my FPGA might be communicating with several identical devices over SPI. I'd like to write one host/real-time driver, and then pass in a reference to which front-panel controls to use for that particular device.

 

It seems like NI has already done some work in that direction, with the FPGA Advanced Session Resources (appears to be LabVIEW 2014 only) and Software Defined Instruments (only on a limited set of boards). I'm looking for a simple interface that's available on all FPGA targets.

While attempting to debug NI1483 issues, I found it necessary to make modifications to the NI1483 CLIP.  In LabView 2014 and earlier, it's not possible to maintain your own IO Module CLIP directory.  One must maintain all IO Modules within the IO module search path (<National Instruments>\Shared\FlexRIO\IO Modules folder ).  This can be done by copying an existing IO module to a new path within the <National Instruments>\Shared\FlexRIO\IO Modules folder, then editing the *.tbc file to rename the "model" key.  The main issues with this approach are the potential lack of administrator permissions and the difficulty of maintaining source control in a non-project related system directory.

 

The suggestion is thus:

 

1. Give the user an option to select the path of the IO module under the IO module Properties General Category (When Enable IO Module is selected).

 

That's it!

 

I have Labview 2020 installed, along with Vivado 2019.1.1_AR73110 (which is the version the vi package manager installed). My suspicion is there may be few bits missing from the Vivado installation that labview does, since said bits (like using a board definition as a starting point for a project) wouldn’t ever be necessary for the FPGA module’s normal operation.
 
The Short version is, Labview’s Vivado versions (2017.2 & 2019.1) behave the same way. I’d question why the C:\NIFPGA\programs\<VivadoVersion>\data\boards directory isn’t present (even if it provides no actual board definitions) in the labview installs if end users are allowed/expected to use the software for custom project uses (IE, FPGA IP export utility, expecting you to use the same vivado version), but ultimately the labview vivado versions do not appear to be missing anything major.
 
Maybe in future labview Vivado versions, include the data\boards directory, with a readme note about what to copy from a Xilinx Vivado version to get board presets to work, or leave the framework without any actual board definitions.

This has been a huge frustration in my development.  There is no way to debug a Flex RIO + NI1483 FPGA design other than to tweak, compile, and test with actual hardware.  NI should provide a VHDL behavioral simuation of all of their modules so that full end-to-end simulation can be performed using advanced simulators such as ModelSim.  This would facilitate a much more robust FPGA development cycle for their customers who have these types of tools available.

 

For the NI1483, a VHDL simulation combined with a VHDL Camera Link behavioral model would be even better.  But the CameraLink model could be developed by the customers as it (At least) is a standard or can be gleened from camera manufacturer documentation.