LabVIEW FPGA Idea Exchange

Post an idea

For debugging, using FPGA VIs in interactive mode can be very valuable. I have, to this day, not been able to find out how LV determines if a bitfile and a VI match.

Therefore whenever I click on the run button for a VI, I'm never quite sure if the bitfile will match or not and often have to wait 1-5 minutes before I can resume working with LabVIEW. This is a very high price to pay for something which I end up cancelling. I would like very much if the IDE would TELL ME that the bitfile and VI don't match before starting a new compilation and thus wasting my time.

This is opposed to a CTRL_Click of the run arrow which explicitly tells the IDE to compile.

support acquire write region on sbRIO

Hi, since there an be a queue for compiling FPGA code, it seems natural to me to also be able to make a queue for generating intermediate files.

I'm working with 10 build specs. for compilation per project and generating intermediate files for my design takes aprox. 3-4 minutes. This means that I need to sit by my computer for half an hour just waiting and clicking build on every build specification. Sometimes I work with FPGA VI which need to build intermediate files for something like 7-10 minutes, so this is a pain.

It would be great if there was a way of just highlighting all build specifications for compilation with shift and just creating the intermediate files for them automatically one by one.

Can this be done?

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)

Show the price of sbRIO on the NI website

View All (1)

Enable Auto Indexing for LabVIEW FPGA

Problem:

Auto-Indexing of LabVIEW is extended to LabVIEW FPGA, only with one small caveat. You can easily auto-index into a loop, but not out of it. You will understand this better if you've already worked with LV FPGA.

In the FPGA paradigm, we enforce compile time resource determinism, by making sure all our arrays are of a fixed pre-determined size. In auto-indexing out of a loop, we may not know what the size of the array is, and hence it breaks the VI with the error "Arrays must be of fixed size". Try to write the following code in LV FPGA, for a better picture:

Solution:

The current workaround is that we have a fixed size Array which we then use in and out of the loop, replacing its

elements, as shown below.

However, an easier and much much more intuitive solution for users would be to just right click the auto-indexed tunnel and set the dimension size.

This definitely means that the number of data flowing out of the loop could be more than our fixed size. We handle that case by providing the user with the "In case of overflow" option.

This would ease our effort in coding LV FPGA as much as it would would improve intuitive coding. Vote for this idea if you think it would make your life a tad bit easier.

FPGA module for 64-bit LabVIEW

With availability of fast FlexRIO cards (such as NI 5761) and FPGA framegrabbers (NI 1483, PXIe-1435, NI PCIe-1433 ) data rates of 1GB/s are becoming commonplace. However, the FPGA Module is limited to communication only with 32-bit LabVIEW. Since, typically you want to store more than 2 seconds of data in RAM,you would like to use 64-bit LabVIEW as your host application. Unfortunately, this isn't possible yet.

While, I can imagine that a full blown 64-bit FPGA Module add on would be pretty difficult to build (and especially test), I believe there is a solid middle ground at this point. I can imagine, coding and compiling the FPGA in the normal 32-bit LabVIEW environment, and then just using a 64-bit host application to Read/Write front panel controls and to read/write the DMA buffers from the FPGA. I don't know the details, but this communication protocols could be very low hanging fruit if it's just a simple matter of recompiling a few key pieces for 64-bit operation.

Since the data rates passing to and from FPGAs will continue to climb, as well as the prevalence of 64-bit OS, a 64-bit version of FPGA Module is needed in the new feature pipeline. This should also be kept in mind as other new FPGA Module features and tools are created, as planning for 64-bit compatability now will make the eventual transition to 64-bit much, much easier down the road.

View All (8)

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 (if the preallocation of arrays option is selected) 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).

Single-Cycle Timed For Loop

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:

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

At present, if you are trying to simulate your FPGA's actual logic, using a custom VI like this:

Then you know that your custom VI test bench only has one case for methods (just a general method case, not a case for each method available). There are ways to get around this problem--for example, this example emulates a node and suggests using a different timeout value for wait on rising edge, wait on falling edge, etc, but one still has to write the code for the different methods.

My suggestion is as simple as this: make test benches easier to use by handling all of the methods and properties with a set behavior. That way, all one has to set up when creating a test bench is the input and output on each I/O read/write line. At the very least, it would be nice to have the ability to read what method is being called, so the appropriate code can be set up without complicated case structures.

The IO Sample Method for the 9205 is very useful in that it can tell the card what channel to scan from two samples ahead, putting the appropriate sample into the pipeline to be read from. Without this method, if one wants to switch channels, the two samples currently in the pipeline will have to be discarded, adding conversion time. With the IO Sample Method, it allows users who know what future samples they want to request to keep up the maximum conversion rate.

More RAM, bigger FPGAs

View All (4)

View All (6)

Pipeline structure

My original problem was that I in the FPGA have an array of data, where I need to do some calculation, where the only appropriate way was to use a pipeline. The pipeline is a very strong tool in the FPGA, but I think the LabVIEW tools could be changed so the pipeline is easier.

My old implementation if the pipeline:

Suggested implementation of single cycle pipeline, with shift registers in the tunnels, so all the code is run on each of the 5 elements in the array.

Maybe there should be added a number of iterations (like the “for loop”), if the number of data, is not defined by the array size.

In another project I have a continuous running pipeline, I have implemented in different ways, but one simple is as shown:

Before

Here the new pipeline sequence could also be used, maybe like following:

Here it should be stated in the loop tunnel, that the input data is read continuous.

Here I have shown in both examples, that it should be single cycle times loops, but maybe the pipeline structure should also be able to run with another timing (determined by the slowest frame).

I have seen the idea about the timed frame, it will help on the last example, but there will still be need for a pipeline structure.

View All (6)

NEW FPGA VI reference property nodes ...

Hello,

It should be nice to be able to get some general informations, on windows, about a FGPA VI using its reference.

For example it should be interesting to get ...

The main cycle loop frequency
A version ID
The CRC of the bitfile
...

This kind of informations could be usefull in case of dynamic bitfiles downloads ...

Or when you try to connect to a running target, you could ask dynamically to get informations ...

I think this kind of informations are known by Labview FPGA ... but only the property nodes are missing.

Thanks.

INLINE VI'S for FPGA ...

Hello,

In Labview 2010, the implementation of INLINE VIs has been improved. But this feature is not aivalable in Labview FPGA.

When you are looking for ticks/space you have to replace the VI calls by their content ... and then the FPGA VIs becames rapidly unreadable.

I think that inline VI could be very interresting in FPGA because ...

Ability to create userfriendly / updatable / readable / clear FPGA diagrams
Optimize the time/space needed to call a real VI

By default, FPGA VIs should all be "Inline" VIs !

Manu.

64 bit FPGA tick-counter

View All (2)

LabVIEW FPGA Idea Exchange

Turbo Boost the speed of FPGA compiles under Windows (Method included!)

Interactive mode: ASK before starting a new compilation if source and bitfile don't match

support acquire write region on sbRIO

Support arrays of references (and named clusters w/o front panel items)

Lets enqueue creating intermediate files

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

Show the price of sbRIO on the NI website

Enable Auto Indexing for LabVIEW FPGA

FPGA module for 64-bit LabVIEW

Make index array more similar to unbundle cluster

Single-Cycle Timed For Loop

Single-Cycle Timed For Loop

Accurate simulation of FPGA methods, etc. in simulated I/O modes

Add IO Sample Method to 9203 and other Pipelined Cards

More RAM, bigger FPGAs

Drive a host timed loop with LabVIEW FPGA IRQ

Pipeline structure

NEW FPGA VI reference property nodes ...

INLINE VI'S for FPGA ...

64 bit FPGA tick-counter