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!
A smaller (and cheaper) sbRIO based on the Xilinx Zynq chip. Target size is SO-DIMM form factor (68 x 30 mm (half the area of a credit card), 200 pins). Such a board would be OEM friendly and can be plugged into a product (rather than the current sbRIO offerings that requires the product to be developed around the sbRIO rather than the sbRIO fitting into your product). Also, a Base Board that is (only) used during development. Below is what the proposed sbRIO and Base Board would roughly look like (courtesy of Enclustra FPGA Solutions)
Even though ibberger touched the concept in the idea , I do think that most o people uses LabVIEW under Windows environment. Compiling a FPGA VI happens all in the PC under Windows. I noticed that during this process the compiler uses only one core. Since I'm using a machine with a 4 core processor, the CPU use rarely goes above 25%.
My idea is to update the compiler allowing it to be multicore. The user should have the option to limit the maximum number of cores available to the compiler. This is necessary because the user may want to continue working, while the compiling process is being done in background.
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.
With availability of fast FlexRIO cards (such as NI 5761) and FPGA framegrabbers (NI 1483, PXIe-1435, NI PCIe-1433 ) data rates of 1GB/s are becoming commonplace. However, the FPGA Module is limited to communication only with 32-bit LabVIEW. Since, typically you want to store more than 2 seconds of data in RAM,you would like to use 64-bit LabVIEW as your host application. Unfortunately, this isn't possible yet.
While, I can imagine that a full blown 64-bit FPGA Module add on would be pretty difficult to build (and especially test), I believe there is a solid middle ground at this point. I can imagine, coding and compiling the FPGA in the normal 32-bit LabVIEW environment, and then just using a 64-bit host application to Read/Write front panel controls and to read/write the DMA buffers from the FPGA. I don't know the details, but this communication protocols could be very low hanging fruit if it's just a simple matter of recompiling a few key pieces for 64-bit operation.
Since the data rates passing to and from FPGAs will continue to climb, as well as the prevalence of 64-bit OS, a 64-bit version of FPGA Module is needed in the new feature pipeline. This should also be kept in mind as other new FPGA Module features and tools are created, as planning for 64-bit compatability now will make the eventual transition to 64-bit much, much easier down the road.
I just manually transferred a fairly large LabVIEW FPGA project from one target to another (7965R to 7966R). It would be nice to be able to click on the RIO target in the project and have an option to "Migrate to New FPGA Target" in the context menu. The menu would open a new dialog where you could select the new RIO target and then it is automatically added to the project and populated the VIs, FIFOs, derived clocks, memory blocks, etc. from the original target. The user can choose whether or not to delete the original RIO target.
This would also make it very easy for users to transfer sample code from the LabVIEW Example Finder to the correct FPGA target (insead of having the folder labeled "Move These Files").
How amazing yould it be to have the ability to visualise resource usage on a FPGA target using a similar view to that shown above (courtesy of Windirstat)
I only recently shaved a significant portion off my FPGA usage by finding out that I had a massively oversized FIFO in my code for almost a year without noticing. I feel that this kind of visualisation (with mouse over showing what is actually occupying the space) with differentiation between Registers, LUTs, BRAM, DSPs and so on would greatly aid those of us trying to squeeze as much as possible out of our FPGA designs.
I think providing this information based on the "estimated resource utilisation" i.e. before Xilinx optimises stuff away would be OK. I'm not sure if the final resource utilisation can be mapped as accurately in this way.
It would also be nice to see CLIP utilisation and NI-internal utilisation at a glance as this is apparently hugely different between targets.
We need a way to simply reinterpret the bits in our FPGAs. I currently have a situation where I need to change my SGL values into U32 for the sake of sending data up to the host. Currently, the only way is to make an IP node. That is just silly. We should be able to use the Type Cast simply for the purpose of reinterpreting the bits.
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.
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.
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.
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.
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.
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.