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!
I have to remember to place a comment next to every memory element so that I can quickly know its size. This is especially important because I can't get to the property window if I'm viewing the vi outside of the FPGA Target Scope. I can view the data type of a memory/FIFO element by hovering over the wire that goes into a read/write property with the context help window open, so I don't really care about that. However I cannot view its size. This could be fixed in one of two ways, add it to the context help when you hover over the element or display it directly on the memory element.
I would like to access class attributes of my FPGA class hierarchy with property nodes. I prefer the property node API over VIs for data member access because it allows you to grab properties from across the hierarchy in a single node. This leads to a (much) cleaner block diagram and expedites development. For example in the screenshot below, the FXP attributes belong to the NI_9205 class, while the "_OP" attributes belong to the parent. I don't care about the Invoke node API over a subVI, because the wiring work and diagram appearance are about the same IMHO.
Currently, when you put a fixed point number into a case structure, it uses the next largest integer and you get a red cooercion dot:
This is unfortunate because, you have to have a default case. It would be nice if the case structures could take the fixed point type since there's isn't any of the ambiguity that exits with floating point. Using a smaller number for the selector might also provide an optimization.
When developing a FPGA application in LabVIEW, after submiting a FPGA code compilation - usually quite a lengthy process - if you modify the code either on the Front Panel or Block Diagram while compiling is in progress, this results in a Compilation Error at the end.
And this occurs regardless the modification be only a mere cosmetic change, without any implication in the code that is being compiled. This is quite frustrating when you realize that the compilation has failed (maybe after half an hour waiting) just because you unconsciously clicked and resized some control or node.
In such a situation, when LabVIEW detects a code change while the FPGA compilation is running, it should warn the user with a message box; if the user confirms the code change, the current compilation can be inmediately aborted or let it continue (at user option); on the other hand, if the user cancels the modification, nothing happens and the compilation continues to a successful (hopefully) end.
Wouldnt it be nice if, when you build an FPGA, rather than poping up a modal window, and preventing you from doing anything usefull for 10 mins or so (or more, dependant on the FPGA vi), LabVIEW went away and generated the intermediate files in the background?
After all, the actual compilation is now performed asyncronously (and you are using the cloud compile, arent you? ), so why should we sit and watch the intermediate files being generated?
Imagine the hours you would save a week, just by being able to get on and do something else.
As the compilation goes on of the LabVIEW FPGA code to bitfile, there is an intermediary step when a VHDL file (or maybe Verilog?) is generated. This file would be very beneficial if you want to use another FPGA target, that NI supports. I know that this VHDL file cannot be directly used for non supported FPGA, but it would be a very good starting point for the ones that know VHDL language.
On PC and RT targets, when you right click on a specific property in a property node, you can directly open the help for that property:
However, on an FPGA target, you can't open the Help for a specific property or method by right clicking:
What happens if you click on 'Help'? It takes you to a page that explains the purpose of a property node. Rarely if ever is that what I actually want. Instead, I want to know about 'Linearization Coefficient 1.' My only option is to open up the Help and search for that specific property, which may or may not be easy to find.
My suggestion is to add a direct link to the help for every FPGA property and method in the right click menu.
The LabVIEW FPGA module has supported static dispatch of LabVIEW Class types since 2009. This essentially means all class wires must be analyzable and statically determinable at compile-time to a single type of class. However, this class can be a derived class of the original wire type which means, for instance, invoking a dynamic dispatch method can be supported since the compiler knows exactly which function will always be called.
This is not sufficient for many applications. Implementations that require message passing or other more event oriented programming models tend to use enums and flattened bit vectors to pass different pieces of data around on the same wire. All of this packing and unpacking can automatically be handled by the compiler if we can use run-time dynamic dispatch to describe the application.
We call for the LabVIEW FPGA module to add support for true run-time dynamic dispatch to take care of this tedious, annoying, and down-right boring job of figuring out how to pack and unpack bits everywhere. Whose with me?
Per NI Applications Engineering, "If you intend to run multiple compiles in parallel on the [Linux] server then yes, you will need the Compile Farm Toolkit running on a Windows machine to handle the parallel workers." I would like NI to support the FPGA Compile Farm Toolkit on Linux, so I don't need a dedicated Windows server to outsource compiles to workers.
In correlation with another general idea I have posted, I have come to the conclusion that it would be nice to run an analysis of the Xilinx log in order to give feedback over which code has been constant folded by the Xilinx compiler.
Other aspects such as specific resource utilisation would be really cool also (SRL32 vs Regsiters for Feedback nodes). This would obviously be a post-bitfile operation but could at least give some direct feedback as to what the Xilinx compiler has modified in the code (Dead code elimination, constant folding etc.).
Writeable inputs to FPGA I/O nodes can be left disconnected without any warning (or broken VI indication) from the VI in which the I/O node is used. This can cause some vigorous head-scratching if the missing connection is not immediately obvious as in the screen shot below. For obvious reasons, FPGA controls have no connector assignment or "Recommended, Required, Optional" attribute. In that case, and to avoid playing "Where's Waldo" on the block diagram, I suggest making FPGA I/O node input connections implictly "required", and if not, the VI would be broken. This would be the same behaviour as seen with cluster nodes.
When working with alot of fixed point math (think FPGA development), unless you are content to simply let LabVIEW decide what precision you want in your fixed point data types, it is extremely cumbersome to (right click->properties->Output Configuraton->Uncheck Adapt to source......, close window, move to next function and repeat and repeat and repeat. This is especially true if you end up needing to highly optimize your code.
It would be nice to have something like a floating window that could be opened that would display the output configuration data for the selected function or control and allow editing without the need for multiple mouse clicks. The window would automatically update with the configuration of whatever function or control was currently selected.
LabVIEW FPGA gives users the ability to prototype FPGA code before they even have the hardware. This is incredibly useful. However, this requires you to manually add your controller, chassis, fpga, and C series modules. The process of adding C Series modules could be improved. Currently, you only have the option to add one module at a time. This isn't too difficult if you only have a few modules. However, if you have a full chassis of modules and a few ethercat expansion chassis, this process can be extremely time consuming. It would be nice if you could add multiple modules at the same time like you can with compactDAQ.
Current method of adding C Series Modules. It takes a long time to add each module individually.
Current method of adding cdaq modules. You can add all of your modules from one screen.
I've searched but can't see anything similar - please add a method for setting the timeout for FPGA nodes. This includes the 'Open FPGA reference' and FPGA IO nodes.
If you disconnect a cRIO FPGA (e.g. NI 9148) from the network, it takes 20-30s for the IO node or Open FPGA reference to execute. This is really bad for the user experience as if they try to exit their application in this time it may take half a minute for the application to exit. It also means you may have to wait that length of time to realise that your FPGA has disconnected under most use cases (you can obviously have an external watchdog loop to check that the node is executing in a timely manner)
Please allow me to configure the timeouts for these nodes similar to the TCP/UDP or VISA nodes. They are very similar in how they operate to the FPGA nodes (i.e. a hardware device driver which is susceptible to disconnects!) so I don't understand why these have been omitted.
I wouldn't mind having to set the timeout as part of opening the FPGA reference and then internally have it use the same timeout for other IO nodes as follows:
I have recently started placing wire labels in my code to keep track of datatypes of wires flowing around my code. This is very useful to understand what is going on on the FPGA since not all grey wires (FXP) are equal and slight mismatches can mean big trouble in the code.
As such I tend to label wires like "Phase FXP+25,0" and so on.
What I'd love to be able to do is to place a formatter in a Wire Label to be able to keep such labels up to date because at the moment it's probably more error prone than anything else due to some wires and labels not being synced any more due to code changes or bugfixes.
If I can set a wire label to "Phase %s" or similar to place the ACTUAL datatype in the label this would be amazing.
Now that most numeric operators have the ability to saturate it would be nice to be able to differentiate these operations. I know that the majority of the time you can determine this information easily with the context help but this would make it much easier to spot. I tend to copy operators that are already being used in my vis than to grab a new one off the pallet. This would let me know which type of operator I'm copying.