NI Home > Community > NI Discussion Forums

LabVIEW FPGA Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea
0 Kudos
xl600

FlexRIO Breakout Extender

Status: New
by Member xl600 on ‎10-24-2014 05:13 PM

There needs to be a way to physically probe the FlexRIO card edge when a NI or custom module is installed.  A time honored method of debugging has always been to probe signals with an o-scope or logic analyzer.  To route debugging signals to unused pins (EX: Within a CLIP) for probing seems a necessity when dealing with hardware and FPGAs.

 

Lets get them to design one and make it into a purchasable accessory!

0 Kudos

This has been a huge frustration in my development.  There is no way to debug a Flex RIO + NI1483 FPGA design other than to tweak, compile, and test with actual hardware.  NI should provide a VHDL behavioral simuation of all of their modules so that full end-to-end simulation can be performed using advanced simulators such as ModelSim.  This would facilitate a much more robust FPGA development cycle for their customers who have these types of tools available.

 

For the NI1483, a VHDL simulation combined with a VHDL Camera Link behavioral model would be even better.  But the CameraLink model could be developed by the customers as it (At least) is a standard or can be gleened from camera manufacturer documentation.

I've searched but can't see anything similar - please add a method for setting the timeout for FPGA nodes. This includes the 'Open FPGA reference' and FPGA IO nodes.

 

If you disconnect a cRIO FPGA (e.g. NI 9148) from the network, it takes 20-30s for the IO node or Open FPGA reference to execute. This is really bad for the user experience as if they try to exit their application in this time it may take half a minute for the application to exit. It also means you may have to wait that length of time to realise that your FPGA has disconnected under most use cases (you can obviously have an external watchdog loop to check that the node is executing in a timely manner)

 

Please allow me to configure the timeouts for these nodes similar to the TCP/UDP or VISA nodes. They are very similar in how they operate to the FPGA nodes (i.e. a hardware device driver which is susceptible to disconnects!) so I don't understand why these have been omitted.

 

I wouldn't mind having to set the timeout as part of opening the FPGA reference and then internally have it use the same timeout for other IO nodes as follows:

2014-09-29_17-16-29.jpg

 

 

xl600

Allow project hosted IO module CLIP

Status: Already Implemented
by Member xl600 on ‎09-18-2014 12:32 PM

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!

 

Status: Already Implemented

You can add the modified CLIP in the FPGA target properties like you would a user-defined CLIP.  When you configure the IO module, the modified CLIP will show up along with the rest of the CLIPs.

gregopher

Support SGL as type for User-Defined Variables

Status: New
by Member gregopher on ‎08-22-2014 08:58 AM

I often work with the FPGA in hybrid mode because the Scan Interface covers most of the project requirements 90% of the time.  When NI added support for the SGL datatype to the FPGA module in 2012 (?), they overlooked user-defined variables.  There is currently no built-in support for typecasting a SGL to U32, so passing SGL data back to the host requires FP controls or using custom typecasting solutions (see SGL typecast) on both the FPGA and host layers.

 

Please add SGL as an option for user-defined variables.

 

 

0 Kudos
trevie1970

FPGA Forced Recompile on other Targets.

Status: New
by Member trevie1970 on ‎08-13-2014 02:34 PM

What I would like to see when transferring FPGA Projects from one target machine to another, that I will not be forced to recompile the Vi code when testing the FPGA code whilst passing parameters within the front panel when executed on the new target., Work arounds like creating a small host front panel to allow parameter changes kind of defeats the object of a FPGA Front panel execution.

crossrulz

Allow Type Cast in FPGA

Status: New
by Proven Zealot on ‎08-12-2014 02:29 PM

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.

e.ono

Incremental Compile LabVIEW FPGA

Status: New
by Active Participant e.ono on ‎07-31-2014 07:47 PM

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.

 

 

Intaris

FPGA resource utilisation visualisation

Status: New
by Trusted Enthusiast ‎07-31-2014 06:18 AM - edited ‎07-31-2014 06:20 AM

 

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.

Intaris

Change the font in the Xilinx Log window to fixed width

Status: New
by Trusted Enthusiast ‎07-24-2014 07:42 AM - edited ‎07-24-2014 07:42 AM

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

When you are using same code on different boards, it would be a big help if you could set the "FPGA VI Reference" indicator as "Adapt to source". When I use dirrerent DMA on different target, then the wire break every time I change target:

 

My FGV for the FPGA reference looks like:

 

FPGA ref Adapt to source.png

JordanJMcBain

Memory Persistence/Volatility on FPGA

Status: New
by Member JordanJMcBain on ‎07-17-2014 11:30 AM

Well it seems that persistent/non-volatile memory is not available on FPGA targets for scenarios involving cycling power.

 

Apparently, the recommended approach is to transfer the data to the host and store it to disk.

 

This is a bit problematic in that the choice is either to write data to disk at a high rate or to accept that the most recent data might not be reloaded on restart.  For instance, an operator might expect to know exactly how many revolutions a shaft has undergone after power cycles to the FPGA target. A guaranttee that this information is as up to date as possible probably can't be met (maybe even under transferring data to disk at a high rate).

 

So I'd like to request this. 

Dragis

Run-Time Dynamic Dispatch Support

Status: New
by Active Participant Dragis on ‎06-23-2014 08:35 AM

The LabVIEW FPGA module has supported static dispatch of LabVIEW Class types since 2009. This essentially means all class wires must be analyzable and statically determinable at compile-time to a single type of class. However, this class can be a derived class of the original wire type which means, for instance, invoking a dynamic dispatch method can be supported since the compiler knows exactly which function will always be called.

 

http://zone.ni.com/reference/en-XX/help/371599H-01/lvfpgaconcepts/fpgaclassesinvis/

 

This is not sufficient for many applications. Implementations that require message passing or other more event oriented programming models tend to use enums and flattened bit vectors to pass different pieces of data around on the same wire. All of this packing and unpacking can automatically be handled by the compiler if we can use run-time dynamic dispatch to describe the application.

 

We call for the LabVIEW FPGA module to add support for true run-time dynamic dispatch to take care of this tedious, annoying, and down-right boring job of figuring out how to pack and unpack bits everywhere. Whose with me?

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?

 

 

A very useful feature of the FPGA Butterworth filter is the ability to use it multiple times, saving FPGA resources.

 

However this is not possible for 32 bit wide filters, only for 16 bit filters.

 

It would be useful if the 32bit filters could go multichannel too, at least two channel

 

 

Intaris

Link Wire label to Data format

Status: New
by Trusted Enthusiast on ‎06-04-2014 06:50 AM

I have recently started placing wire labels in my code to keep track of datatypes of wires flowing around my code.  This is very useful to understand what is going on on the FPGA since not all grey wires (FXP) are equal and slight mismatches can mean big trouble in the code.

 

As such I tend to label wires like "Phase FXP+25,0" and so on.

 

What I'd love to be able to do is to place a formatter in a Wire Label to be able to keep such labels up to date because at the moment it's probably more error prone than anything else due to some wires and labels not being synced any more due to code changes or bugfixes.

 

If I can set a wire label to "Phase %s" or similar to place the ACTUAL datatype in the label this would be amazing.

Kirk

Bring FPGA over to 64 bit LabVIEW

Status: New
by Member Kirk on ‎05-23-2014 11:53 AM

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.

spsimona

Smart compilation

Status: New
by Member spsimona on ‎05-02-2014 02:19 AM

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

On the cRIO-9068, the third serial port and the second Ethernet adapter is actually mounted on the FPGA, resources are consumed to redirect to realtime. Currently there are no access to this resource on the FPGA for developers, only from the Realtime.

 

I would like some I/O Nodes for interacting with these devices on the FPGA. NI could put up some examples how they could be used.

 

Today the resources are invisible to the developer, except for the additional long compile time and resources used (about 7%).

 

I attached pictures of the FPGA design and the resources consumed for a blank vi.

 

 

Sincerly,

Jens Eriksen

 

 

0 Kudos

As part of my quest to solve problems arising from over-cautious Register transfers HERE I found a solution which WOULD have worked if I was able to force multiple clocks derived from the same source to be have synchronised start points (so that the iteration counters of the loops are known relative to each other). It seems that clocks derived from the same base clock do not neccessarily all start with Iteration zero at the same time.

 

My suggestion would be to either

  • Give some option to force such loops to have synchronous starts (also when using external clocks) -or-
  • Allow loops with external clocks to terminate so that we can put together out own synchronisation method

Shane

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!
Idea Statuses
Top Kudoed Authors
User Kudos Count
4
3
2
2
2