LabVIEW FPGA Idea Exchange

Top Authors

User

Kudos

Post an idea

For some application, I find myself configuring memory blocks for the storage of custom controls which I am maintaining with a type def. Type definitions normally have the advantage that changing them will update them everywhere they are used.

Unfortunately, when I change a type def control for which a memory block has been configured, the memory block does not update this, and my code breaks. It appears that the memory block disconnects the control from its type def when configured. It would be nice if the memory block was reconfigured - as this is what I would expect to happen with a type def control.

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

Allow Parallel For Loops on FPGA

LabVIEW FPGA gives users the ability to prototype FPGA code before they even have the hardware. This is incredibly useful. However, this requires you to manually add your controller, chassis, fpga, and C series modules. The process of adding C Series modules could be improved. Currently, you only have the option to add one module at a time. This isn't too difficult if you only have a few modules. However, if you have a full chassis of modules and a few ethercat expansion chassis, this process can be extremely time consuming. It would be nice if you could add multiple modules at the same time like you can with compactDAQ.

Current method of adding C Series Modules. It takes a long time to add each module individually.

Current method of adding cdaq modules. You can add all of your modules from one screen.

View All (5)

When setting up a custom VI to use as a simulation test bench, you are currently limited to setting a constant path. If you move your VI, send it to another user, change the name, or otherwise change the path of the custom VI, you must enter the FPGA target settings and modify the path. That is, if you moved the project below from user1's desktop to user2's desktop, you would have to enter the properties and change the location. This makes code sharing somewhat tedious.

Using a relative path or a project item would make this feature easier to use.

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)

Hello,

i would suggest some Improvements to the Timing Violations Window.

Highlight the Whole Path with all Element and Wires in the Blockdiagramm when i click on Path in the Timing Violations Window.

Highlight the Element on the Blockdiagramm which i clicked in the Timing Violations Window.

Give the Problem Window of the Timing Violations Window the ability to adjust its size i often have to scroll. (Can be seen in the Timing Violation Window above)

With kind regards

westgate

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.

Better check for Compile Server

If you try to compile while pointed to a Compile Server that is for any reason inaccessible (server is down, firewall, typo in the hostname, etc.) you must wait through the generation of intermediate files, then you receive the error message that LabVIEW FPGA was unable to contact the Compile Server at your configured hostname/IP. Generating intermediate files can be a lengthy process and it shouldn't be necessary to wait through it just to find out if you have configured your Compile Server correctly. Any of the following would be a much better experience:

Attempt to connect to the Compile Server before generating intermediate files.
If the connection to the Compile Server fails after generating intermediate files, give the option of specifying a new Compile Server hostname/IP and retrying without having to re-generate the intermediate files.
At least put a connection check in Tools >> FPGA Module Options... so the user can test the connection to the Compile Server. You wouldn't do this all of the time, but if you run into a problem at least this way you can keep trying new configurations without generating intermediate files. Right now the best way to test new configurations is to create a blank FPGA VI (to decrease the length of generating intermediate files) and keep trying to compile it.

Don't compile if not needed !

Hello,

This morning, after a night of FPGA compilation, i moved my Labview project path into an other location.

(Without modification of relatives path inside the project directory)

And then ... when i tryed to launch my FPGA main VI ... the compilation started again !!!

I would be nice that the "change detection mechanism" which detect if a compilation is required or not, doesn't take care of absolute paths !

I think that the "change detection mechanism" of FPGA code should be modified in order to only take in account the FPGA code dependencies.

The dependencies should not include ...

Absolute path references
disable conditional items ... if not used in the FPGA code
...
All things not directly needed and called by the FPGA code
...

LabVIEW FPGA Idea Exchange

Keep Memory Blocks with Custom Controls Connected to Type Def

Prompt for Fixed-Point Configuration

Single-Cycle Timed For Loop

Single-Cycle Timed For Loop

Allow Parallel For Loops on FPGA

Email and SMS Notifications by Compile Server

Allow the Addition of Multiple C Series Modules at one Time

Use relative paths or project items for custom test bench VIs

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

Add IO Sample Method to 9203 and other Pipelined Cards

Don't recompile if a memory or IO added for a different VI

More RAM, bigger FPGAs

Drive a host timed loop with LabVIEW FPGA IRQ

Improvements of Timing Violations Debuging

Simple code lock for FPGA targeted VIs

Better check for Compile Server

Consider supporting a driver for Spartan-3E-1600KGate Development Board

Don't compile if not needed !

Auto Increment

Offset Shift Registers