LabVIEW FPGA Idea Exchange

Post an idea

Hello,

I have a LabView project which includes a Windows part and a FPGA part.

To simulate my windows part i use Conditional Disable Symbols in order to bypass the FPGA calls. ( Ex: DEBUG = TRUE/FALSE)

These project Conditional Disable Symbols are not used im my FPGA Vi's.

BUT, when i change the Conditional Disable Symbols values ... i have to rebuild my FPGA code ! This is not good !

The "Bitfile validity" check should be a little more intelligent.

The "bitfile update detection" should only take in account the Conditional Disable Symbols it uses.

Thank for reading.

Manu.

View All (3)

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)

Basic building blocks

FPGA Emulator Mode WITH REAL I/O

Recompiling an FPGA VI can be time consuming when debugging a large program. The emulator mode is not useful when the process includes debugging real I/O connections (vs. emulator simulated). I would propose a useful "fix" to the emulator I/O problem. Could the emulation mode have the ability to use all the I/O's as "pass through" connections from the FPGA to the host in order to actually use the I/O's. This would involve a very simple FPGA VI that connects all the I/O's to appropriate indicators or controls. If this pre-compiled VI is downloaded and running on the FPGA during emulation mode, then you could actually debug real I/O connections without compiling your entire VI.

View All (1)

Hello,

For the moment, there is only one clock assigned with the FPGA main VI. "The top level clock"

This clock is used by the code created on the main block diagram. (Outside SCTL)

Today, if you need an other clock ... you have to use SCTL's ... but using SCTL generates many problems, because not all instructions are allowed in SCTL's !

I think that XILINX can handle a kind of partition !

My need would be, for example, to have one partition running at 40MHz ... and an other at 80MHz ... without having necessary to use SCTL's.

This is only an idea ... i think that behind my idea something heavy must be done !

The Top would be, to be able to share data between the different partitions (using FIFO for example) ... but i think this is one more difficulty !

The partition mechanism could be created in Labview FPGA as follow ...

With multiple top VI's : On per partition
Or, with a special structure in the main vi block diagram : Partition structure, with a clock as input : Like a mega SCTL, without SCTL limitations.
Or, by adding a clock input to the while loops
...

Thanks for reading.

View All (2)

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.

Improved documentation for FPGA memory

When setting up memory in LV FPGA these seems to be one important setting missing....description.

Good programming practice defines that we should have descriptions in our code, similar to the VI description of a global variable. This would also help out immensely when using bit packed memory blocks to define status bytes and such as the description of the individual bit meanings could be added to the description and not having to be dropped as block diagram comments everywhere one of the nodes is used.

When you configure Memory in LV FPGA, there is no way to find specific references to particular memory blocks using the search function. The search will show "ALL" memory access nodes, not just the ones you are looking for. Additionally a text serach will not catch the text from the X Nodes. This can be particularly tedious if you have many nodes in your hierarchy and are looking to only see references to a particular memory block.

I would like to see the search improved to allow filtering of the memory nodes the same way that we can search for global variables (find definition and find references)

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.

When working with LabVIEW FPGA if so much as the value of a block diagram constant is changed, the entire application must be recompiled.

It seems that there could be a smarter method to deal with recompiling that might allow selected portions of the block diagram to be recompiled without the need to recompile the entire app.

Some of the tradeoffs might be lower FPGA utilization efficency and timing constraints, but allowing minor changes to the FPGA code without the overhead of a complete recompile would certainly make debugging applications much faster.

I am not necessarily proposing an implementation just posting an idea that seems like it would add value to the LV-FPGA development experience.

MAX access and configure I/O module

View All (5)

FPGA Bitfile Name & Location

FPGA bitfiles should not have any dependency on the project name or target name. What if you change the name of your project? What if you change the name of the target? These dependencies should only correspond to the VI and its location in the project tree and FPGA target. FPGA bitfiles should be in the same directory as the vi but with a different extension.

Change the automatic name and path of FPGA bitfiles from:

.\FPGA Bitfiles\ProjectName.lvprog_TargetName_ViName.vi.lvbitx

to

.\ViName.vi.lvbitx

Parallel loop support

Parallel loops are supported by LabVIEW but not LabVIEW FPGA, this requires us to copy/paste the same blocks multiple times to make them run in parallel. I would like to see the ability to use parallel loops on FPGA targets as FPGAs are very well suited to this style of programming and the current copy/paste parallelism hinders this.

Compiles Started over a VPN

Differentiate Saturating Operations

Memory Initialization VI Input

Memory initialization is one of the more tedious aspects of LVFPGA coding. A lot of my LVFPGA vis have multiple memory elements that I need to access simultaneously for a given operation. I've tried to streamline the initialization process by making all memory initialization vis read from an init values file and populate the array indicator. However now I have to have multiple initialization vis reading from different points in the same init values file. If I could somehow get a parameter into the memory initialization vi, I could programmatically select from where in the init values file to read. Here is how this could work:

LabVIEW FPGA Idea Exchange

Conditional disable symbols should not systematically alter validity of FPGA bitfiles ...

Pipeline structure

Basic building blocks

FPGA Emulator Mode WITH REAL I/O

Multi top clock, for main VI ... Multi partition FPGA code ...

NEW FPGA VI reference property nodes ...

Improved documentation for FPGA memory

Improved Search Scope for IO and Memory X-Nodes

INLINE VI'S for FPGA ...

Allows locking of parts of the block diagram to minimize compile time

MAX access and configure I/O module

FPGA Bitfile Name & Location

Parallel loop support

Compiles Started over a VPN

Differentiate Saturating Operations

Memory Initialization Browse Button Default

Memory Initialization VI Input

Logic operators and Fixed Point numbers

Configure Memory / FIFOs from Outside FPGA Target Scope

Array to number coercion dot when sign extending