LabVIEW FPGA Idea Exchange

Community Browser
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!
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

LabVIEW NXG had the ability to create a resource file.  Though I cannot find the help reference for this I will describe the functionality below:

 

Right now the Target Scoped FIFO, P2P, DMA-FIFO, Memory, Handshake Items, Registers, Clocks, etc are all stored as part of LabVIEW Project (lvproj) file.

 

If want to port to a new project file or target I have to copy/paste.  This is not a big deal and works well.  However if I update one project's configuration I have to re-copy/paste.  From a configuration management perspective I cannot ensure the configurations are always the same.  With larger, multi-FPGA projects this becomes critical.

 

It would be great to have a file that holds all of these resources to allow for easier portability and configuration management.

When we try to compile timing critical FPGA application, if might be failed because of timing violation.

But if it missed only a few nanoseconds, recompiling might resolve the error as below.

 

Resolving Timing Violations on the FPGA

If your failed compilation misses the required throughput time by only a few nanoseconds, try rebuilding your bitfile. Each build of a bitfile does not always produce identical results on the FPGA, so rebuilding sometimes resolves minor timing violations. 

 

 

In most case, compilation might require much time and it's difficult to take quick action after they found the aborted compilation result.

It would be great there is an option which allow automated recompile like below.

Of course the compilation completed, it wouldn't try recompile. Only failed, try to compile again.

 

** -------------------------------------------------------------------- **

Enable Auto Recompile [  *  ]   Number of Retry  [  4  ]

** -------------------------------------------------------------------- **

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 !

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

Number to Boolean Array and Boolean Array to Number along with array manipulation functions (index, replace, reverse) are commonly used methods in FPGA for doing bit manipulation on arrays of integers inside SCTLs. Not having access to these functions is prohibitive and results in having to write code like this:

image.png

This becomes very unwieldy when dealing with arrays of 20+ elements. If Number to Boolean Array and Boolean Array to Number are truly no-op elements, then they (along with basic array manipulation nodes) should be added to the list of supported nodes inside for loops inside SCTLs.

The error "You must recompile the VI for the selected target" appears for reasons that, to me, are often obscure or even inexplicable. Recompiling is, as we know, painful. It would be good if the error message included the reason(s) for refusing the existing bitfile, since then I may be able to work out how to stop it happening.

I understand the message comes because LabVIEW decides there are "dirty dots" associated with the bitfile, what I would like the error message to tell me is which dots are dirty and why.

Please add the ability to right-click on a Memory, Register and/or FIFO and FIND ALL instances throughout the project and/or VI hierarchy. Ideally it would be just like local and global variables (as shown) for desktop LabVIEW. 

 

FIND all instances for BRAMs.png

Initially I looked around for my previous idea here: Selecting between two I/O refnums not allowed because I thought it was the same and intended to post a comment to that, but I see that was a bit more specific.

 

This seems like a more allowable case - why is A forbidden and B perfectly ok?

 

A:

Select node in SCTLSelect node in SCTL

 

B:

Case Structure to choose between two values based on boolean inputCase Structure to choose between two values based on boolean input

 

Here A is forbidden (at Intermediate file generation - so perhaps this would help: Unsupported nodes inside for loop within SCTL should result in a broken VI (NXG != Already Implemented really...)) but B is compiled with no problem. I really don't see why Select of two integers is different to a Case Structure with two integers input, a boolean case selector, and an integer output from the two inputs...

 

As an idea rather than a rant, I'd like A to be possible.

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.

I think it would be useful if LV kept track of device utilization over each compilation. The data could be presented as a graph which might give useful clues to the developer how the project is approaching the limits of the FPGA. Also, I think this data could optionally be stored in the same folder as the bit file so that the developer can review the file history with their source control.

utilization 3.PNG

 

 

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.

LabVIEW FPGA has chosen to disconnect typedefs in Register Items, Memory Items, FIFOs, and Handshake Items (http://zone.ni.com/reference/en-XX/help/371599M-01/lvfpgaconcepts/fpga_fifo_mem_custom_data/). Please reconsider this decision.

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.

All FPGA dialog properties dialog boxes that allow to specify a custom control data type (e.g. Memory, register, FIFO, etc...) should show the path and name for the last .ctl configured. For example,properties.PNG

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.

I love using enums because they can often make discrete options much clearer. Example:

enum clarity.PNG

But, at least as of 2017, the below code is going to use fewer resources and propagate faster because LabVIEW is going to use an 8 bit register above instead of the two bits below. 

 

My solution is to allow smaller integer representations of enums (I'd use a U2 in the above case).

 

Ideally the user wouldn't even have to specify the integer size, it could just calculate the minimum at edit time and show the user what it is.

The Tick Count function in LabVIEW FPGA can represent time periods with tick count accuracy of up to 2^32 clock cycles, that is (using the standard 40 MHz FPGA clock) about 107 seconds.

Sometimes I need to handle longer time spans, and I use this example.

 

I suggest to implement a built-in 64-bit tick counter.

 

 

 

64bittick.png

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.

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