LabVIEW FPGA Idea Exchange

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.

Hello,

I've been thinking to an experiment in wich I would need to acquire single shot spectra at 1MHz, with a sinlge line camera (1024 pixels, 12 bit), and then manipulate this spectra performing this kind of operation:

[ (spectrum1 - spectrum2)/spectrum2 + (spectrum3 - spectrum4)/spectrum4 + ... + (spectrumN-1 - spectrumN)/spectrumN ] / N

As I don't have experience with FPGA, do you think it would be possible to do this kind of things considering that the data flow (1M*1024*12) will be something like 2GB/s?

Thank you,

Daniele

Similar to the overflow-status-functionality (which I missused in the picture below) it would be useful to make it possible to include handshaking bit(s) in the signal as well. It is true that this could be implemented using a cluster. However the additional cluster-level will imply a multiplication of type definitions; moreover a built in handshaking-bit-functionality could be included directly in the high-speed math functions an registers, so that a seperate 'output valid' terminal would not be necessary.

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.

View All (3)

Sometimes I just want to compile a lot of Bitfiles (Be it for a release or a debugging test case) and I have to right click each and every Build spec and choose "Build". then wait about 10 seconds and do the same again for the next build spec.

How about being able to select multiple build specs and then select "Build Selection" and have time to go for lunch while the PC queues up all the compilations?

I don't use a compile farm and everything is done locally but at least the queuing could be automated.

Shane.

When working with CLIP-generated clocks we need to have good UCF files for proper compilation control (Something we now have after WEEKS of debugging ).

At the moment the ucf files MUST be in Users\Public\Documents\National Instruments\FlexRIO\IOModules for the code to work even though all other CLIP-relevant files can be located anywhere.

Please let us use the ucf file located int he same directory as the CLIP we're using otherwise we'll end up with cross-linking nightmares between users who don't have the right version in their local folder.

Shane

View All (2)

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?

The "FPGA I/O Properties" that can be set for an I/O point under an FPGA target consist of just the name for the I/O point.

On the other hand, the "Shared Variable Properties" that can be set for a similar I/O point under a cRIO chassis are much more extensive and include a description field.

I'd like to see a similar description field included/available for the FPGA I/O points. As it is information that is maintained as part of the "project", the reduced functionality normally associated with an FPGA should not be an issue.

As long as I'm wishing, it would also be nice to be able to export/import names/descriptions/properties from something akin to the "Multiple Variable Editor" for both "FPGA I/O Properties" and "Shared Variable Properties" and if an I/O module is moved from the FPGA level to the cRIO level or vice versa, allow us to transfer or import the relevant properties from one level to the other.

View All (1)

Dear All,

I am attempting to write some FPGA code, for a cRIO 9074, to act as a data logger for 50 sensors that I am fitting to a small lifeboat. I hope to save all the data to the 9802 SD card module. From my understanding, it should be possible to take the sensor input signals into the FPGA chip, compile them into an interleaved data group and then output them straight on to the SD card from the FPGA. This means there is no RT controller required; making the system more reliable and quicker. Is this correct? Or is my knowledge wrong?

I have tried to look for some example of this on the web but I am struggling to find any which do NOT use a RT control. Can anyone point me in the direction of some examples?

Few extra details: Sampling frequency = aiming for 10 KHz (will be reduce if system cannot handle it), Input modules include; 9236 strain gauges, 9234 accelerometers, 9205 analogue voltage inputs, anymore questions fire away.

Thanks in advance!

Pete

View All (1)

I just manually transferred a fairly large LabVIEW FPGA project from one target to another (7965R to 7966R). It would be nice to be able to click on the RIO target in the project and have an option to "Migrate to New FPGA Target" in the context menu. The menu would open a new dialog where you could select the new RIO target and then it is automatically added to the project and populated the VIs, FIFOs, derived clocks, memory blocks, etc. from the original target. The user can choose whether or not to delete the original RIO target.

This would also make it very easy for users to transfer sample code from the LabVIEW Example Finder to the correct FPGA target (insead of having the folder labeled "Move These Files").

I've developed a small test utility for testing FPGA code on my windows machine before proper FPGA testing and have noticed something I think could be improved.

If I have a graph or any other indicator with DBL default data type within a conditional disable, the compiler still throws an error regarding an unknown state (DBL). Although the terminal is in the diagram disable, the object seems to remain on the FP (but also in the code being sent to the FPGA compiler).

Can we actually remove the graph (or other culprit control) in the background before starting the actual compile so that I don't need to drop and re-connect every time I want to switch execution systems?

Shane.

View All (1)

When using external ram on the FlexRIO products it would be nice to have a memory map tool built into LabVIEW FPGA.

Many traditional FPGA release processes for companies require a memory map. Currently LabVIEW only allows the user to create memory partitions, but the user has no control on where the partitions are laid out in memory.

This can cause problems during the release process because the simulation is not repeatable because the memory element being accessed may be in a different location.

This feature will not impact the functionality of LabVIEW, but will make it easier to use LabVIEW FPGA in companies where Verilog, and VHDL languages were the only options for FPGA's and the release process is hard to change.

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW FPGA Idea Exchange

Reference Inputs to Module Property Nodes

Shrink Method nodes

fpga data analysis

Option to include handshaking bit in signal (fpga)

read clock rate from clock reference

Include co-simulation with ISim

Add Device Pinouts Tab for R-Series Cards in MAX

Build Selection option

Custom UCF file location

Drivers for the Atlys Spartan 6 board

VI scripting for FPGA programming

Add Description Field to FPGA I/O Properties.

Fix tha latch point for FPGA property nodes

Default data type Single Precision (SGL)

Data logger with NO RT controller, using 9802 SD card module

Auto-Migrate to New RIO Target

FPGA Graph handling

Powering NI sbRIO device

Como configuro FPGA en el Compact- Rió?

memory map