NI Home > Community > NI Discussion Forums

LabVIEW FPGA Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

Better FPGA FP Control Selection

Status: New
by Trusted Enthusiast on ‎01-13-2015 10:36 AM

When there are many controls on the front panel of the FPGA, selecting the control from a Read/Write Control node in the host can become a pain.  It is one very large list of controls on the front panel of the FPGA.  This list has no scrollbar, no browse, or search feature, and no obvious way of grouping controls.

 

Here is one example of a front panel, and a video showing how long it takes to scroll through the list of contorls.

 

FPGA Front Panel.png

 

And here is the video of me scrolling through the controls:  http://screencast.com/t/PLzptTwq58aw

 

There is plenty of room for improvement.  Here are just a few ways I think NI could make this better.

 

Browse and Search

 

When using a Property Node, or Invoke Node, the very top option is to "Browse..."  From here a list of all properties, or methods can be seen in a resizeable window.  Here you can also search, and sort alphabetically.  The Read/Write Control node could have similar functionality making selection of controls easier.

 

Front Panel Selection From FPGA

 

There could be an option for creating a node by selecting the controls on the front panel of the FPGA.  A solution that may work today, is to select the controls, then invoke a custom QuickDrop command that creates the node and puts it in the clipboard so it can be pasted in the host VI.  If this were to become an option, I'd hope there is a way to combine two nodes into one, by concatenating the controls of one onto the other. 

 

Front Panel Selection From Host

 

Lets say you already have the Read/Write Control node on the host.  There could be an option by right clicking that would open a new window, showing a static image of the front panel of the FPGA, which the user could then click on.  This would be great because the developer probably already knows the control they want based on the front panel location.  I don't know how possible this is because you could load a bit file which won't have any front panel information. 

 

Easier Grouping of Controls

 

Right now there is a way to group controls of an FPGA.  This feature is never talked about, and doesn't work on dynamic bit files.  Here is a discussion where I describe the steps to make controls grouped on the host.  Still this isn't supported on all FPGA setups, and you have to conform to a specific naming convention.  Why can't controls that are grouped on the front panel, just be grouped in the host?

 

 

This idea exchange is really for any kind of improvement to the FPGA control selection.

Change the font in the Xilinx Log window to fixed width

Status: New
by Trusted Enthusiast ‎07-24-2014 07:42 AM - edited ‎07-24-2014 07:42 AM

Xilinx log window should use a fixed-width font.

 

Which of these two string indicators with identical content is easier to read?

 

FPGA Xilinx Log font.png

 

Spoiler
The one on the left is Courier, the one on the right is the default Application font

This is the current situation when dealing with register creation on FPGA targets:

 

Regsiter Create.png

 

This is what I would like:

 

Regsiter Create wishful thinking.png

 

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.

 

 

Hi How about facility of import and export of I/O Label in FPGA-Real time project as shown image instead of manually renaming each I/O

 

IO Label.jpg

Allow Type Cast in FPGA

Status: New
by Knight of NI on ‎08-12-2014 02:29 PM

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.

FPGA resource utilisation visualisation

Status: New
by Trusted Enthusiast ‎07-31-2014 06:18 AM - edited ‎07-31-2014 06:20 AM

 

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.

 

Shane.

Smaller (and cheaper) sbRIO based on Xilinx Zynq

Status: New
by Active Participant vitoi on ‎05-01-2012 03:10 AM

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)

mars_pm3_350.jpg       mars_pm3_350.jpg

 

User Lorn has found a brilliant tip for *DRASTICALLY* speeding up FPGA compile times under Windows for PCs with the turbo boost feature. What's more, it's extremely simple to implement.

 

Please let's see this in future versions of LabVIEW as standard.

 

http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Multi-core-Compiling/idc-p/2301338#M297

Incremental Compile LabVIEW FPGA

Status: New
by Active Participant e.ono on ‎07-31-2014 07:47 PM

Hello all.

 

It is time-consuming that we have to compile all LabVIEW FPGA code even if there is tiny little change on FPGA code.

I understand there is sampling probe, Desktop execution node and simulation tools to reduce such time.

 

Our customer in Japan, would like to use incremental compile function also on LabVIEW.(Please see below)

I agree his opinion.

 

http://www.youtube.com/watch?v=9v50uCVdW3o

 

What do you think?

 

Eisuke Ono

Application Engineer at National Instruments Japan.

 

 

Get reference to currently deployed bitfile on FPGA target

Status: New
by Active Participant smithd on ‎11-13-2014 11:15 AM - last edited on ‎02-25-2015 10:31 AM by Active Participant Dragis

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.

Improvements for Continuous Integration

Status: New
by Member AndyBrown on ‎02-25-2015 09:48 AM

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.

Bring FPGA over to 64 bit LabVIEW

Status: New
by Member Kirk on ‎05-23-2014 11:53 AM

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.

Make Bitfile Paths Relative, Not Absolute

Status: New
by Active Participant James_McN on ‎08-05-2013 09:48 AM

Currently when you build a VI the bit file path is stored as relative (you can see it in the project XML). This means if you change the project location either:

 

  • Moving machines.
  • Checking in and out of source code control on different machines

You have to recompile the FPGA to use VI mode or run interactively. It seems the bitfile could be stored as a relative path like all VIs in the projects.

 

Cheers,

James

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?

 

 

Improve Compile Retrieval Process

Status: New
by Member AndyBrown on ‎02-25-2015 07:34 AM

Long compile times are a necessary evil of FPGA code.  Even with the vast improvements of Vivado, compile time still ranks as the biggest killer of large project efficiency.  As compile times approach 3-4 hours, their successful completion becomes paramount.  All too often I find that the Xilinx compiler running on the compile worker has completed successfully however some small communication glitch either between my development machine and the farmer or the farmer and the worker has caused the compile to be lost.  It is quite frustrating to know you have a completed bitfile from Xilinx but the NI tools will not perform the final processing steps required to create the lvbitx file.  The only solution is to restart the compile costing another 3-4 hours of productivity.

 

Typical workflow in our company for these large projects is to spend mornings testing and stressing the compile(s) from overnight.  Then make any bug fixes and incremental feature improvements and try to start a compile by mid-morning.  By mid-afternoon when the compile is complete do the process again so that you can process another build for overnight.  If one of the compiles fails because of timing or resource problems, there's nothing that can be done.  But if it fails because of glitches in NI's compile wrapper code, that becomes a waste of a half of a day of productivity.

 

I propose that the current methods for compiling bitfiles be modified.  The goal is to improve user productivity.  Some of my suggestions include:

  • For a given build specification, give it the ability to re-attempt to retrieve the last completed compile. This option would be available even if the VI's that created that compile had been modified.
  • If a compile was completed previously for this build specification and there has yet to be a successful lvbitx generation, prompt the user before doing anything that would destroy the ability to retrieve it.
  • Make sure that all of this still works when changing connections to the worker.  For example if I start my compile at work then take my laptop home and want to login to my VPN at night to check on my compile
  • Don't remove any chance to get a compile if there was a communication error.  Right now when I get the communication error, I see a red X in the compilation status and my only option is to remove it from the list.

Auto-Migrate to New RIO Target

Status: New
by Member Brian_R on ‎08-15-2012 03:16 PM

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").

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.

Multi-core Compiling

Status: New
by Active Participant Manzolli on ‎03-08-2010 07:43 AM

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.

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.

About LabVIEW FPGA Idea Exchange

Have a LabVIEW FPGA Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. 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!
  3. 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.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
Idea Statuses
Top Kudoed Authors