LabVIEW FPGA Idea Exchange

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

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.

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.

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

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.

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

Both resource and timing reports can be hard to read.

 

Timing shows clocks that may not appear as SCTLs.

Resources show items which are not easy to trace back the resources on the FPGA itself.

 

This varies based on the target being compiled, for say 7976 (Kintex-7), 5785 (Ultrascale), and x410 (RFSoC).

 

There could be a knowledgebase article on "How to understanding LabVIEW FPGA compile results"

 

I know that for more detailed compile results we have exported to Vivado but for new users this can be very intimidating and a big distraction.

Hello,

 

This morning, after a night of FPGA compilation, i moved my Labview project path into an other location.

(Without modification of relatives path inside the project directory)

 

And then ... when i tryed to launch my FPGA main VI ... Smiley Mad the compilation started again !!!

 

I would be nice that the  "change detection mechanism" which detect if a compilation is required or not, doesn't take care of absolute paths !

 

I think that the "change detection mechanism" of FPGA code should be modified in order to only take in account the FPGA code dependencies.

 

The dependencies should not include ...

 

 

  • Absolute path references
  • disable conditional items ... if not used in the FPGA code 
  • ...
  • All things not directly needed and called by the FPGA code
  • ...
Angry Manu.net.

 

 

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  ]

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

While for loops inside SCTLs offer limited functionality, placing an unsupported element inside the for loop does not result in broken code. Instead, one has to wait until the second stage of generating intermediate files to discover that the element is not supported. Code like the example below should show a broken run arrow if it is not supported.

 

Annotation 2019-08-14 111042.png

 

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

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.

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

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?Smiley Happy ), 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.

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.

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.

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.

 

 

The rvi folder has automation tools for FPGA compiles.  These are not very well documented.  There are no examples on using these.

 

Could additional info and examples be provided?

 

This is useful for projects where automated building helps continuous integration with tools such as Jenkins or Bamboo.

Hi there,

 

I got following feedback from a LV FPGA user:

 

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.

 

 

Thanks

Álvaro

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.