Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW FPGA Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW FPGA Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
In current versions of LabVIEW FPGA, placing a For Loop inside an SCTL will result in code that cannot be compiled; this is because conventially For Loops work iteratively and therefore require multiple clock signals to drive each new iteration.
However, I think a logical implementation of a For Loop within an SCTL would be the generation of multiple parallelised instances of whatever code is inside the For Loop. This would greatly improve readability and flexibility by avoiding the user having to manually create multiple separate instances of the same critical code on the Block Diagram.
This would require the For Loop to execute a known maximum number of times.
Single cycle timed loops are a huge performance enhancer in LV FPGA. We learn to use these very prolifically in and around our code to save precious FPGA space, yet the BD representation of the SCTL is the standard Timed Loop structure, with both the Left and Right "ears" visible as well as the conditional terminal.
I propose that the SCTL be given it's own representation on the block diagram, one without the "ears" and without the conditional terminal (by definition it only runs once). This will promote much cleaner looking FPGA code and more readable diagrams.
If I am choosing to offload multiple FPGA compilations to either a local or cloud compile farm, can we not at least do the itnermediate file generation in parallel? Our current design takes approximately 10-15 minutes to generate intermediate files. For 5 Cloud compiles, this blocks my IDE for around an hour.
Since the file creation processes are independent of each other, why can't we do them in parallel?
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.
The FPGA compilation results should be copied to a file in the folder with the bitfile. This is needed to track the history of compilation results, especially useful when using source code control. Right now they get overwritten with each recompile.
Adding a Post-build action VI to the FPGA build spec, would also enable something like this.
This might have already been asked, but I couldn't find any posts.
X-Nodes are huge in comparison to the size of a subvi or most anything else on the block diagram of code, so lets shrink them down.
Can we remove the Read/Write box? We already have the little triangle to tell us the function/direction.
Can we use the node name instead of the generic term Data/Element? It's already there.
From there we can model it after a property node using references instead of error lines or we can model it after the IO node which is a little cramped but gets the job done. Both options retain a purple/pink bar to help identify it's X-node-iness.
This is the current situation when dealing with register creation on FPGA targets:
This is what I would like:
I am currently creating a group of classes to abstract out inter-loop communication and the ONLY thing changing between classes (aside from variations between Ragister vs FIFO vs Global and so on) is the datatype. Being able to link the Register creation to a data input (the data value of the class itself for example) would save a lot of work in such operations. If it were also possible to do the same for the Register stored within the class private data then implementing different classes int his way would be really easy.
Even without classes, the ability to autoadapt the type of registers / FIFOs in this way would be a real step towards re-usable code on FPGA.
Parallel loops are supported by LabVIEW but not LabVIEW FPGA, this requires us to copy/paste the same blocks multiple times to make them run in parallel. I would like to see the ability to use parallel loops on FPGA targets as FPGAs are very well suited to this style of programming and the current copy/paste parallelism hinders this.
Reason: As ATE manufacture sometimes we need small FPGA to do something inside ATE or ITA (interface test adaptor). To use sbRIO/myRIO is to big (complexity,price). Because we use TestStand and LabVIEW out knowledge of VHDL is small.
We could learn VHDL but after that we could stop to use LabVIEW FPGA! :-)
Proper unit testing is a key component of large LVFPGA project success. As the number of modules grows, so does the number of units tests increase. We are working on automatic continuous integration methods that will continue to monitor the accuracy of all modules and assemblies throughout the project life cycle. IP Integration node and NI's wrapper around Xilinx IP makes this task more difficult. When our continuous integration machine refreshes the source code from the repository it has to regenerate these nodes in order to compile. The "Regenerate IP Integration Node Support Files..." tool does not always properly update all IP. It seems like the NI wrappers around Xilinx IP are most problematic. The only way a computer can properly update its version of the node is to open the VI and click through the Xilinx IP generation pages to get it to update.
As a rule we do not commit build products into our source code repository. One option would be to submit all the support files generated when first creating the IP integration node so that others users might not have to update. This can become messy and quickly unwielding. The problem arrises when changes to the IP integration node cause more or fewer support files to be generated. This then requires deleting some files from the repository and adding others which is tedious and leads to errors. One compromise would be if the IP integration created one single compact file that contains all the information needed (expect the input vhd, etc. files) that could be committed to the repository. Even better would be to roll this information into the VI itself. Neither of these might be ideal if the support file contents take up a lot of disk space.
Regardless there needs to be a better solution to allow for automated continuous integration testing.
For debugging, using FPGA VIs in interactive mode can be very valuable. I have, to this day, not been able to find out how LV determines if a bitfile and a VI match.
Therefore whenever I click on the run button for a VI, I'm never quite sure if the bitfile will match or not and often have to wait 1-5 minutes before I can resume working with LabVIEW. This is a very high price to pay for something which I end up cancelling. I would like very much if the IDE would TELL ME that the bitfile and VI don't match before starting a new compilation and thus wasting my time.
This is opposed to a CTRL_Click of the run arrow which explicitly tells the IDE to compile.
I have several FPGA projects that require significant compile time (up to 1.5 hours), and for that I am thankful to have my compile server running on a separate computer.
The issue comes with the seven Pre-Compile steps that occurs before LabVIEW sends to the code to the compiler. On one particular project this action alone can take up to 35 minutes during which time I can do nothing on that machine.
I would like to see much of this precompile time moved from the development environment to the compile server. There already exists a mechanism for updating the user with the compile status so those precompile errors could be annunciated in a similar fashion.
Get the development system back online as quickly as possible.
The FIFO read looks like an event based node (like a dequeue or wait on occurance) and I think there's a lot of people that assume it's going to use minimal cpu resources while it is waiting for data. I'm wondering if we can have an option that behaved like that. For example, could we have fixed sized FIFO read where the FPGA could trigger an interupt to let the RT side know the data is ready?
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.