LabVIEW FPGA Idea Exchange

Post an idea

More detailed Xilinx log feedback

In correlation with another general idea I have posted, I have come to the conclusion that it would be nice to run an analysis of the Xilinx log in order to give feedback over which code has been constant folded by the Xilinx compiler.

Other aspects such as specific resource utilisation would be really cool also (SRL32 vs Regsiters for Feedback nodes). This would obviously be a post-bitfile operation but could at least give some direct feedback as to what the Xilinx compiler has modified in the code (Dead code elimination, constant folding etc.).

run-time selection of FPGA resources

I would like to select which FPGA resources (DMA FIFOs, front-panel controls) are used by a host VI at run-time. This would make it possible to implement multiple copies of the same function on an FPGA and control them with the same driver, passing in a reference to the appropriate resources. For example, my FPGA might be communicating with several identical devices over SPI. I'd like to write one host/real-time driver, and then pass in a reference to which front-panel controls to use for that particular device.

It seems like NI has already done some work in that direction, with the FPGA Advanced Session Resources (appears to be LabVIEW 2014 only) and Software Defined Instruments (only on a limited set of boards). I'm looking for a simple interface that's available on all FPGA targets.

View All (6)

Connector Name

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.

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

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.

support acquire write region on sbRIO

pre and post-build options

When I build a new bitfile for my project, I sometimes (shock horror) make mistakes and bring the whole house of cards crashing down.

In situations like that, I would love to have the last version of the bitfile available for re-testing. Ideally, I could specify a pre- and post-build option for my compilation where I can define my own automatic re-naming and archiving scheme so that I no longer need to do painful re-compiles for reverting my code.

I am aware that this probably applies to more than FPGA but here the compilationt imes are more prohibitive and I feel the need is larger.

Connect SMB Trigger to FPGA

Prompt for Fixed-Point Configuration

Single-Cycle Timed For Loop

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 to obtain a fixed-size array (valid on the FPGA). Below is the simplest possible example:

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

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):

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).

Simple code lock for FPGA targeted VIs

I would like to see some form of simple locking mechanism for VIs that are targeted to an FPGA.

The use case would be where you have compiled a VI for your FPGA target and are currently in the process of debugging/testing it. While running interactively and opening and closing VIs, you accidentally move something on a block diagram without realizing it. The next time you hit the run button LV shows you the "Generating Intermediate Files" dialog and you have now ventured down the one way street to a full FPGA recompile.

I know that source code control or setting all files to read only would also work, but when debugging a project, it is cumbersome to continually check all files in and out, or to continually change the directory attributes.

Just a simple lock/unlock button on the toolbar to keep from shooting myself in the foot while debugging.

....posted as I sit here waiting on a 4 hour FPGA compile for just this reason.

Offset Shift Registers

Index to NI 9802 port access

The NI 9802 (Secure Digital Removable Storage Module for CompactRIO) is a cRIO module that has two SD memory card slots. The problem is that the programmer cannot index the ports as "0" and "1". The solution is to write a code for "0" and repeat it for "1".

The proposal is to allow the user to select memory card by a terminal in the "Method" and "Property" nodes.

Since the maximum amount of memory per card is 2 GB, if more than 2 GB is needed, the programmer should manage to split the data in two cards. Right now the code should be duplicated and selected by a "Case" structure. In many other situations the programmer may need to use one or other card, like when a big file should be saved after the usual check of the available free space in both cards.

View All (4)

Better support for multi-clock IP Cores

There are several functions of Xilinx IPCores which are not natively exposed in their LV counterparts. FIFOs for example, in certain configurations, allow for asymmetric read and write port widths. For multiplexing or serialisation / deserialisation this can be really useful.

However, if we try to create sometihng like this in LabVIEW we end up in a weird situationw here the IPCore offers the functionality, but the graphical context of G prevents us from really using it.

In this image, I have generated an asymmetric FIFO. The node created as a result has TWO clock inputs, one for the read port (shown in blue) and one for the write port (in green). We can't place a single node in LabVIEW in two different clock domains at the same time. When finishing up the IPCore config, we are asked for a single clock (which is then valid for ALL of the inputs and outputs). What we would essentially need is the ability to define multiple groups of I/O and the associated clocks for them. In addition, allowing access to these via a scheme similar to I/O nodes or CLIP references, we could then easily distribute the individual signals to the appropriate places for operation.

The I/O nodes below the IPCore show how this can be used. Most likely it would be a clock constraint so that ALL I/O of a given port (read or write in the FIFO example) are required to be used in the same clock domain. This is theoretically all do-able via a wrapper user CLIP, but if LV could just automate it for us, that would be great.

Support malleable VIs in FPGA targets

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

Ability to save sampling probes

View All (1)