LabVIEW FPGA Idea Exchange

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

Vision is available under LabVIEW 64 bit and this makes sense since vision can generate very large amounts of data.  I think now is the time to bring FPGA over to LabVIEW 64 bit as well.  With FPGA systems you can also generate very large data sets.  Also with cards like the PCIE 1473R, you have a VISION requiring card that generates lots of data, but it requires FPGA, so you can only use it in LabVIEW 32 bit.  This is not a good thing.  It has been 5 years since LabVIEW 64 bit has been released  it is time to finish moving the addons over to 64 bit.

High speed serial links are becoming more and more prevalent in FPGA designs. NI now offers FPGA cards with these MGTs exposed.

 

It would be a huge advantage to be able to design / implement devices with embedded SB-RIOs which are capable of interfacing vis MGT.

 

AFAIK, none of the currently available SB-RIO have any MGT functionality exposed. For us (Analytical device manufacturer) this would be a real game-changer.

Old Title: FPGA Case Structure Needs To Display Enum Values

 

In LabVIEW the case structure can show enum values, while the FPGA case only shows the numeric value. Would like to see the below example capable in FPGA.

Untitled.png

We're starting development on an Ultrascale device, KU40 and am missing the option to utilise the DSP48E2 primitive as we have for DSP48 and DSP48E1.

 

Intaris_0-1670929335347.png

 

NXG seemed to have it, but as we all know, NXG is no more.

 

https://www.ni.com/docs/en-US/bundle/labview-nxg-fpga-module-cdl-api-ref/page/dsp48e2.html

 

Can we please have a DSP48E2 primitive for LabVIEW FPGA? I would really like access to the new features supported, including the wider multiplier.

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.

I'm bringing back to life this long-lost idea: https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/pre-and-post-build-options/idi-p/2364676

as I think there are lots of situations where pre/post build actions could be useful for FPGA.

 

For example, as suggested here: https://forums.ni.com/t5/LabVIEW/Populate-FPGA-array-with-values/m-p/4145330#M1195362

I have a large array of coefficients that I want to load from a file, then populate an array constant with it. I have a script to do it, now I would like to automatically run it before compiling the bitfile. For context, I want it to be a constant because controls take more resources and do not allow constant folding optimization.

 

I already had another situation where I made a tool to auto-generate code in case structures based on some specifications given by the developer. If however the developer forgets to run it before compiling, the FPGA VI won't work properly as necessary code has not been generated.

 

More generally, I think scripting for FPGA is way underrated. As FPGA code is quite often tedious and redundant to create (because optimization is priorized over readability, and because of the lack of type genericity), scripting has a great potential here. Allowing to run pre/post build actions for FPGA bitfiles would surely take FPGA scripting to the next level !

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. 

FPGANode.png

Working with the NI 5785 our team had a hard time understanding how to use TClk without all of the extra (e.g. streaming) code that comes with the example.

 

Through support we were eventually put in touch with R&D and they told us how to initiate TClk by setting some of the FPGA controls.  This was helpful but not intuitive.

 

TClk helps support beamforming applications shown in the NI Marketing but without this usability it is very difficult (impossible) to develop applications promised.

 

TClk also has other lower level features such as the delay correction.  No info is posted on this either but it is a property we can read.

When accessing a FPGA control / indicator from the HOST, a ~property node is used, and the developer has to pick the right control / indicator from a list

 

When there's lots of items on the list, it can be a pain to scan the list for the right one.

 

At the moment they are listed in order they were created on the FPGA.

 

Could they instead be listed in alphabetical order? Or give the developer the choice?

 

 

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.

 

fixed point config.PNG

The Vision FPGA has come around for maybe ten years? Nowadays, FPGA has much more resources than their ancestor, but in Vision FPGA, we can still only handle 8 pixels a single cycle, which sometimes comes as a bottleneck.

 

Also, I think it would be good to add a signed 16-bit image data type for Vision FPGA; when we use u8 subtraction, we are losing some of the information for the output is only another u8 image. If we have the i16 datatype, it will be possible to do a lossless subtraction. Sometimes every bit counts.

 

 

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.

 

18007i82E22C521A6F662A

The latest Virtex-7 FPGAs have something like 20 times the computing power of the biggest FPGA supported by LabVIEW FPGA; it would be cool to be able to get those on a FlexRIO card.

 

Other companies make FPGA boards with up to 32 GB of RAM, the biggest FlexRIO has 512 MB; would be cool to have FlexRIO cards with RAM in the gigabytes.

Idea: New NI FPGA module with:

 

  • small FPGA (something which LabVIEW FPGA could already program Spartan 6 ...)
  • programmable by LabVIEW FPGA Module
  • IOs only
  • no CPU
  • DIP connector
  • One LED
  • Reset Button
  • Price under $100

Something like Papilio Pro.

 

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! 🙂

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:

 

normal property node.png

 

 

However, on an FPGA target, you can't open the Help for a specific property or method by right clicking:

 

fpganode.png

 

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.

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

 

Current method of adding C Series Modules. It takes a long time to add each module individually.

 

 

Proposed

 

Current method of adding cdaq modules. You can add all of your modules from one screen.

We can programmatically mass compile VI's and build executables but there is no easy method to compiling FPGA code.  We have a large application that consists of C++ and LabVIEW code.  We have automated our build process but we still have to compile the FPGA code using a procedure.  It would be nice to write a script or a VI that would compile all of our FGPA code.

The Control / Indicator pull down menu gets unwieldy with a lot of Controls on the FPGA Front Panel. 

 

I would like to be able to sort the names alphabetically so they are easier to pick in the pull down list.

When you compile on your own machine, the output of the "coregen" step is cached and used on subsequent compiles.  This saves considerable time.  The fact that this does not happen on the NI cloud service erases any speed gains (and more).

 

You could:

 - Cache cores at NI.  Save for xx days since last use (or forever if space is not an issue)

 - Transfer cores when they exist (cached locally) to compile server along with other intermediate files

 

I would like to have a feature to access several IO pin ranges to avoid programming this for a 9205 cRIO module:

check.png

With DIO modules like NI9403 you can program this:

check2.png

Why not provide Mod2/AI0:31 in the above image? (With subranges like AI0:7, AI8:15,… similar to DIO module?)