LabVIEW FPGA Idea Exchange

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

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.

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

 

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

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

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  ]

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

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.

 

 

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.

In current versions of LabVIEW FPGA, placing a For Loop inside an SCTL will result in code that cannot be compiled; this is because conventially For Loops work iteratively and therefore require multiple clock signals to drive each new iteration.

 

However, I think a logical implementation of a For Loop within an SCTL would be the generation of multiple parallelised instances of whatever code is inside the For Loop. This would greatly improve readability and flexibility by avoiding the user having to manually create multiple separate instances of the same critical code on the Block Diagram.

 

This would require the For Loop to execute a known maximum number of times.

 

SCTLs.png

 

 

Parallel loops are supported by LabVIEW but not LabVIEW FPGA, this requires us to copy/paste the same blocks multiple times to make them run in parallel.  I would like to see the ability to use parallel loops on FPGA targets as FPGAs are very well suited to this style of programming and the current copy/paste parallelism hinders this.

 

 

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

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.

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

 

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'm currently looking for a way to read out the FPGA version number from the FPGA.

All I found was a way to parse the *.lvbitx, but that's not what I want.

Are there any plans to store the version number in a FPGA register to be read out at runtime?

 

Best regards

Thomas

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.

Currently Measurement & Automation Explorer (MAX) only shows the following information for a typical R-Series card:

 

MAX-R-Series.png

 

It would be helpful to add a "Device Pinouts" tab that shows you all the pin assignments for your Analog and Digital IO:

 

MAX-R-Series-Device-Pinouts.png

 

I have to remember to place a comment next to every memory element so that I can quickly know its size.  This is especially important because I can't get to the property window if I'm viewing the vi outside of the FPGA Target Scope. I can view the data type of a memory/FIFO element by hovering over the wire that goes into a read/write property with the context help window open, so I don't really care about that.  However I cannot view its size.  This could be fixed in one of two ways, add it to the context help when you hover over the element or display it directly on the memory element.

  17825i508503367D458784

This might have already been asked, but I couldn't find any posts.

 

X-Nodes are huge in comparison to the size of a subvi or most anything else on the block diagram of code, so lets shrink them down.

 

Can we remove the Read/Write box?  We already have the little triangle to tell us the function/direction.

Can we use the node name instead of the generic term Data/Element?  It's already there.

 

From there we can model it after a property node using references instead of error lines or we can model it after the IO node which is a little cramped but gets the job done.  Both options retain a purple/pink bar to help identify it's X-node-iness.

 

X-nodeShrink.png

Please give Labview FPGA the ability to program any FPGA.

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.