LabVIEW FPGA Idea Exchange

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

Array to number is very useful for just auto-sign extending numbers, but it would be nice to visually see this without having to go to each instance and inspecting the context menu.  How about some coercion dots.  I don't really care which colors.  Here's an example:

17849i1E94A660F7AB0657

Having two computers, one for developing and one desktop pc for administrative work, I use the desktop as compile server for compiling the FPGA VIs. The compilation takes about 45 minutes, during which I can't develop anything in LabVIEW. By sending the data to the desktop pc, I can resume my work. Though on the desktop machine it's annoying to always leave this program open and get closed accidentally from time to time or I forget to start it in the morning after booting the pc.

 

Suggestions:

- Minimize the LabVIEW FPGA Compile Server to system icon tray

- Option for starting the Compile Server on booting of the OS. 

I would like a way to name all of the connector I/O from an external souce - perhaps an excel file.  I envision importing a single file for all of the I/O.

It would be nice to have control of clock.-independent assignments of signals from I/O nodes (without synchronising registers) without having to specifically having to use a clock for the connection.

 

Intaris_0-1719315020552.png

 

 

Image says it all.

 

We have tried using a static assignment on the top-level diagram, without using a SCTL but it appears that does not work. The example links within a single CLIP, but the idea is aimed at actually doing some connections between multiple different CLIPs without the need for a specific VHDL wrapper for each individual configuration.

Hello,

 

I recently have issue configuring FPGA Vis to be run seemlessy by the same host code, because of incompatible interface between VIs. Here is the Configure FPGA VI Reference Interface :

 

Configure FPGA VI Reference InterfaceConfigure FPGA VI Reference Interface

 

And here are two (differents) interface, fore FPGA 1.vi and FPGA 2.vi respectively, as seen in the context help. I just duplicate the VI for the example and get the tab order modified - see under Registers :

 

Context Help for FPVA 1.viContext Help for FPVA 1.viContext Help for FPVA 2.viContext Help for FPVA 2.vi

 

I think it could be more consistent to have the same kind of display in the configure dialog, with the same control order. It's quite confusing not seeing any difference when configuring a reference to discover that something is wrong at run-time (controls and indicators are separated, and then sorted alphabetically - I only set controls in my example code, no indicators). The context help over the dynamic reference finally helps me to figure out what was wrong but it tokk me a while...

 

Please note that the FPGA FIFOs have to be define if the same order from one bitfile to an other (if there is differents targets, or differents projects). This is correctly reflected by the configuration window.

 

So I suggest having a more coherent display of control and indicators interfaces, that correspond to the effective interface (just like the context help does), i.e. the tab order of the controls under Registers.

 

Best regards,

With even simple examples we experience errors when trying to run Instruction Framework based LabVIEW FPGA VIs.

 

This is a blocker for our using Instruction Framework.

MGT interfacing to the 7915 is provided: https://forums.ni.com/t5/Examples-and-IP-for-Software/Aurora-64b-66b-Streaming-Example-for-the-PXIe-7915-Ultrascale/ta-p/3952187

 

It is not provided for other cards such as the 5785.  Is the interfacing the same?  Could examples for this be provided?

One of the benefits of the Instruction Framework is that one could develop several modules each using Instruction Framework.  The modules can then be integrated and the Instruction Framework modules can be assembled using Collections.

 

This information is not clear and the provided tutorial does not provide information on this use case.

Perhaps there's already a good way to do this, but some structures/nodes are allowed in a Single-Cycle Timed Loop but their behaviour is significantly changed, perhaps breaking your VI.

It would be good to be able to mark VIs in some way as unsuitable for use within a SCTL.

 

An example is the flat sequence structure - you can place this in a SCTL and it can pass intermediate file generation, but the behaviour is as if there was no sequence structure.

Assuming that it isn't always superfluous, this probably indicates invalid behaviour but is not necessarily obvious to detect (e.g. with broken compilation or intermediate files).

 

Some specific node that could be placed on a block diagram and indicate that a VI cannot be placed inside a SCTL would be useful.

Something like a Divide can be used for this, but not trivially easily - you need to actually use the output of the Divide or else the dead-code elimination allows the intermediate files to be happily generated. It took me quite a few goes to get a failure even with SGL precision divide in a SCTL... wiring to a structure or an indicator is not enough, it must be something that actually uses the value.

Currently, in LabVIEW you can right click a VI's icon at the top right of the front panel to find all instances including where the VI is referenced in a static reference node. Also, when you use have a "Open FPGA VI Reference" in "build specification" or "VI" mode, you can double click the node to open the referenced block diagram. Once the FPGA front panel is open, there's no easy way to get back up to the caller. It would be cool if we could extend the right-click-find-all functionality so that when you right clicked a top level FPGA VI, it would search where that VI was referenced in any "Open FPGA VI Reference" nodes. Currently, when you right click and search, it just says no instances found.

I love the FPGA Desktop Execution Node. I'd love it even more if I could access global variables from the FPGA VI that is being emulated:

 

Globals in DEN.png

 

I normally use globals as opposted to controls and indicators to curve FPGA resource usage in cases where I won't need those values available through the FPGA Interface on the deployed application.

While attempting to debug NI1483 issues, I found it necessary to make modifications to the NI1483 CLIP.  In LabView 2014 and earlier, it's not possible to maintain your own IO Module CLIP directory.  One must maintain all IO Modules within the IO module search path (<National Instruments>\Shared\FlexRIO\IO Modules folder ).  This can be done by copying an existing IO module to a new path within the <National Instruments>\Shared\FlexRIO\IO Modules folder, then editing the *.tbc file to rename the "model" key.  The main issues with this approach are the potential lack of administrator permissions and the difficulty of maintaining source control in a non-project related system directory.

 

The suggestion is thus:

 

1. Give the user an option to select the path of the IO module under the IO module Properties General Category (When Enable IO Module is selected).

 

That's it!

 

I find myself again and again having to memorise bit field index and other things in order to be able to debug FPGA code efficiently.  What I would really like to be able to do is to create an XControl with a compatible datatype (Say U64) and have this display and accept input in the form of human-readable information.

 

The data being transported is simply a U64 and the FPGA code doesn't need to know anything about the XControl itself.  Just allow a host visualisation based on an XControl to ease things a bit.

 

I've already started using LVOOP on FPGA and I think this could be another big improvement in the debugging experience.  Having an input XControl (or a set of XControls) for certain LVOOP modules on the FPGA just gets me all excited.

Working on the FPGA, I use fixed-point precision numbers quite often.  I have grown tired of selecting the FXP representation from the right-click contextual menu (block diagram or front panel), only to then right click again to navigate to the "size" tab to select the configuration.

 

The default configuration is very rarely what I need it to be -- there should be a faster way to change this.

I know that when connected to the compile server the local compile status window will show you when a compile is done, however that does seem to severely limit productivity in that the only way you can get back to working in LV is to disconnect from the compile server. The downside is that you don't get any feedback as to when your compile has completed. This is especially true if your compile server is running on a remote machine.

 

Why not add a feature to LabVIEW to allow disconnecting from the compile server but still provide a background polling feature to update the user when the compile has completed. Something as simple as a dialog box telling me that my compile is ready would be great. It would allow me to get back to work on other sections of the code while still closing the loop on the running FPGA compile process and alerting me that it is done.

 

If the system polled once every minute or so that would be more than adequate.

 

 

Cross Posted

 

I do a fair amount of Pipelining and it would be cool if I could Offset the Input Shift Register from the Output Shift Register.

The default would be to keep them aligned but a right - click would give me the option to offset the input or output Terminal. I think it would be bad form to allow crossing the terminals between multiple Shift Registers so the top Input terminal would correspond to the top Output terminal.Offset Shift registers.JPG

 

I work with malleable VIs a lot on desktop. They can save a lot of boilerplate code. From my understanding, the entire feature has no effect once code is compiled: the VI is converted to an "instance" VI with the proper data types and inlined into the caller. This doesn't seem like it should be problematic to use on an FPGA target.

 

Here are a few FPGA-specific wins that I think VIM support would deliver:

  • Array size adaptation
    • One can imagine writing a "parallel for loop" VIM that simply expands out N parallel iterations for array sizes 0-N
  • Fixed point configuration adaptation
    • Without VIM, if you write a VI that operates on fixed point numbers, it will auto-coerce to the configuration on the controls of the VI

 

When not using Instruction Framework to interface from the Host to LabVIEW FPGA the FPGA VI reference register items cannot be ordered by the user

 

They appear in a random order (order of creation) and it is not easy to find and select them.

 

I am referring to this function: https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgahost/readwrite_control/

The 7976 and 7915 have certain functions (e.g. Basic Elements) in different locations.  Some do not even show up (e.g. Channel is in 7976).

 

NI 7976 LabVIEW FPGA 2018:

 

Terry_ALE_0-1600126303727.png

 

NI 7915 LabVIEW FPGA 2018:

Terry_ALE_1-1600126401252.png

 

Hello,

 

Is there any possibility to use a dedicated file to change the Number of Synchronizing Register

 

Today we need to right click on the DIO + Propriety + Advanced Code Generation + Select Nb of register.

On a SBRIO 9607 I have to do it 96 times and if I change something with the CLIP generator I need to do it again.  

In my design I use VHDL IP so the synchonisation is already done on the VHDL and I don't need extra clock.

2020-01-24_07h57_17.png

 

I try to edit with Notepad++ the .lvproj file and change the NumberOfSyncRegistersForReadInProject or NumberOfSyncRegistersForOutputData but it's not clean...

 

If you have an idea it will save a lot of click.

Thanks