LabVIEW FPGA Idea Exchange

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

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?

 

 

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

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

Hi,

 

I realise that parallel for loops don't work on FPGA because they are designed to create multiple threads which FPGAs don't have.

 

However lets take the scenario that I have 8 channels of data to process (scale, filter etc.) but do not have time to do this sequentially due to high loop rates.  Could parallel for loops be a way of doing loop unfolding on FPGA rather than forcing me to have 8 parallel paths of identical code?


Cheers,

When considering options, it's important to see the development and deployment price. Please put the sbRIO prices on the NI website so we can consider it.

When writing LabVIEW code for an FPGA target, the most important considerations are speed and resource usage.  By using the single-cycle timed loop (SCTL), we can increase the speed of the program by allowing more than one operation to complete per clock cycle.  We also decrease resource usage by removing the flip-flops that would be required to store values between clock cycles for the operations in the SCTL.

 

However, there are limitations of the SCTL.  For some operations, it takes significantly less resources to implement something using a for loop rather than a single-cycle timed loop.  With a for loop, one can auto-index a result at the border of the for loop (if the preallocation of arrays option is selected) to obtain a fixed-size array (valid on the FPGA).  Below is the simplest possible example:

 

AutoIndexed For Loop

 

The equivalent with a single-cycle timed loop would be:

 

SCTL

The replace array/subset VI consumes resources proportional to the size of the array.  Depending on the operation being performed, this can increase resource usage such that it is more practical to use a for loop (as shown above).

 

I propose the creation of a single-cycle timed for loop.  Here is a very rough mock-up (MS Paint is not the most adequate of image processing tools... you will get the idea):

 

SCTFL

 

This solves two problems: 1) It allows for the compiler to know how many times to loop will run at compile time.  It also simplifies the UI by letting the user know how many times the loop will run without having to think through a condition.  2) It allows for the more efficient creation of fixed-size arrays through a SCTL (rather than through a for loop).

I didn't find something related to this, so I hope it's a new idea.

I use frequently VI scripting on LabVIEW, it is very useful for example to generate template VI's.

but this feature doesn't exist under FPGA, I mean some code is specific to this module, and I think it would be great to be able to generate FPGA VI's programmatically. For example in my job we make FPGA programming for Magnet Security. Even if global structure is the same for all magnets, we have to adapt a lot of things depending on type of magnet and instrumentation available. The idea would be to create ourself a kind of Magnet Safety Editor based on VI scripting specific for FPGA in order to allow non-programmers, but Magnet specialists, to generate themselves an adapted security system.

It's just an example, but when we see powerful of VI scripting for LabVIEW, it would give great results if it extends to FPGA, and even Real-Time  module, why not? 

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.

I would like to access class attributes of my FPGA class hierarchy with property nodes.  I prefer the property node API over VIs for data member access because it allows you to grab properties from across the hierarchy in a single node.  This leads to a (much) cleaner block diagram and expedites development.  For example in the screenshot below, the FXP attributes belong to the NI_9205 class, while the "_OP" attributes belong to the parent.  I don't care about the Invoke node API over a subVI, because the wiring work and diagram appearance are about the same IMHO.

 

2013-09-05_233500.jpg

 

Thanks,

 

Steve K

If you try to compile while pointed to a Compile Server that is for any reason inaccessible (server is down, firewall, typo in the hostname, etc.) you must wait through the generation of intermediate files, then you receive the error message that LabVIEW FPGA was unable to contact the Compile Server at your configured hostname/IP.  Generating intermediate files can be a lengthy process and it shouldn't be necessary to wait through it just to find out if you have configured your Compile Server correctly.  Any of the following would be a much better experience:

 

  1. Attempt to connect to the Compile Server before generating intermediate files.
  2. If the connection to the Compile Server fails after generating intermediate files, give the option of specifying a new Compile Server hostname/IP and retrying without having to re-generate the intermediate files.
  3. At least put a connection check in Tools >> FPGA Module Options... so the user can test the connection to the Compile Server.  You wouldn't do this all of the time, but if you run into a problem at least this way you can keep trying new configurations without generating intermediate files.  Right now the best way to test new configurations is to create a blank FPGA VI (to decrease the length of generating intermediate files) and keep trying to compile it.

With multiple hosts in one project remove the restriction of FPGA target names.  If I have 2 cRIOs in one project and the FPGA in those cRIO's is the same then so should the FPGA target name.

 

FpgaName.jpg

 

 

Of course, FPGA target names must be unique if they are within the same host.

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

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.

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.

Per NI Applications Engineering, "If you intend to run multiple compiles in parallel on the [Linux] server then yes, you will need the Compile Farm Toolkit running on a Windows machine to handle the parallel workers."  I would like NI to support the FPGA Compile Farm Toolkit on Linux, so I don't need a dedicated Windows server to outsource compiles to workers.

In real time engineering usualy the clock rate is a parameter which is needed in calculations. Therefore it would be useful to be able to access that rate as integer (or float). It is clear, especially in fpga-programming that the clock (and its rate) is not a variable, that can be chosen by the application user. This idea is rather about code development in order to avoid bugs. In the current situation I am forced to define a seperate constant copying the clock rate; in the course of later code changes I risk to forget to change that constant, when changing the clock.

For the same reason it would be useful to be able to access a clock refernce of an fpga-vi (an with it its rate) form the calling vi.

 

 

FPGAClock.png

Typical Xilinx IP core icon like FFT and DDS looks like this - in expanded mode:

Typical Xilinx IP icons in expanded view

The connector labels are very hard to read. I guess everybody agrees on that this could be improved. And it is not that there is a "standard" narrow width to obey, for instance FIFO is wider than the Xilinx IP icons.

Thanks for considering this.

Hi,


Simple one that I have heard a number of people request.  Why is there no auto-increment on the versions of an FPGA build specification versus any other versioned build specification in LabVIEW?  This should be a simple addition to bring the FPGA module inline with other LabVIEW modules.

 

Cheers,

Mac

I know its not necessarily a LVFPGA issue, but its us LVFPGA users that use fixed point numbers most often.  Why don't fixed point numbers always show coercion dots.  If every unnecessary numerical digit wastes chip resources, then isn't it more important that we know about these coercions so that we can avoid them?

 

17841iA5A553AFF2430D61

The first thing you hear about programming FPGAs with LabVIEW is: use single-cycle loops. But if you build a state machine (while-loop + enum + case structure), in many cases you cannot make the outer while loop in a single cycle-loop, because not every state fits into a single-cycle loop. Therefore you have to place the single cycle-loop into every case, which has to run in one cycle, which takes up block diagramm space and is cumbersome. Therefore my idea to create a single-cycle case structure: it uses the same compiling mechanism of the single-cycle loop on every case, which is capable of running inside a single cycle. It would be nice, if this behaviour is configurable, meaning I can decide from case to case, if it is a single-cycle case or not. Some kind of right-click menu options like these: "make this case single-cycle", "make every possible case single-cycle", etc. Of course the mode of the case (single-cycle or not) should somehow be displayed.

 

Regards,

Marc