LabVIEW FPGA Idea Exchange

Post an idea

Presently, the Xilinx Compile Tools do not appear in the MAX technical report or NI License Manager. As a result, to determine the version, users must go to Add/Remove Programs in the control panel to determine which versions they have installed. It would be great for troubleshooting if the Xilinx Version could be implemented into the MAX technical report.

In addition, the Compile Worker states that the version of Xilinx used is 12.4, regardless of whether you are using 12.4 or 12.4 SP1. It would be useful for the compile worker to note which version it is using. Specifically, often the compilation chooses the compile tools based on what it was compiled with previously. When upgrading to 12.4 SP1, the user may think the compiler automatically uses the new compile tools and has no visual cue to verify the compile tools version used.

When LabVIEW 2009 and prior, after the compilation of FPGA VI, the bitfile was automatically downloaded to EtherCAT. However, from 2010, that process became manual; after the compilation, you need to go under the Build Specification, right click on the bitfile created, and select Download. Regular cRIO does it automatically, and I don't see the point of manually downloading it.

Does anyone know the point of doing this? And if it was not intended, I like auto download a lot better. But at the same time, 2009 and prior, the bitfiles were not shown under the build specification, which bothers me also. So the conclusion is that, I think it will be better to show the bitfile under the Build Speficcation AND download it automatically to EtherCAT.

Wouldnt it be nice if, when you build an FPGA, rather than poping up a modal window, and preventing you from doing anything usefull for 10 mins or so (or more, dependant on the FPGA vi), LabVIEW went away and generated the intermediate files in the background?

After all, the actual compilation is now performed asyncronously (and you are using the cloud compile, arent you? ), so why should we sit and watch the intermediate files being generated?

Imagine the hours you would save a week, just by being able to get on and do something else.

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

Angry Manu.net.

View All (4)

Auto Increment

View All (3)

I know that when connected to the compile server the local compile status window will show you when a compile is done, however that does seem to severely limit productivity in that the only way you can get back to working in LV is to disconnect from the compile server. The downside is that you don't get any feedback as to when your compile has completed. This is especially true if your compile server is running on a remote machine.

Why not add a feature to LabVIEW to allow disconnecting from the compile server but still provide a background polling feature to update the user when the compile has completed. Something as simple as a dialog box telling me that my compile is ready would be great. It would allow me to get back to work on other sections of the code while still closing the loop on the running FPGA compile process and alerting me that it is done.

If the system polled once every minute or so that would be more than adequate.

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)

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.

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

Compiles Started over a VPN

I have several FPGA projects that require significant compile time (up to 1.5 hours), and for that I am thankful to have my compile server running on a separate computer.

The issue comes with the seven Pre-Compile steps that occurs before LabVIEW sends to the code to the compiler. On one particular project this action alone can take up to 35 minutes during which time I can do nothing on that machine.

I would like to see much of this precompile time moved from the development environment to the compile server. There already exists a mechanism for updating the user with the compile status so those precompile errors could be annunciated in a similar fashion.

Get the development system back online as quickly as possible.

View All (1)

LabVIEW FPGA Idea Exchange

Como configuro FPGA en el Compact- Rió?

Check for Invalid Use of Global Variables in LabVIEW and Alert User Before Compiling

Make It Easier to Determine Current Xilinx Compile Tools Version, and Distinguish Between Xilinx 12.4 and Xilinx 12.4 SP1

Procedure of Downloading Bitfile to EtherCAT

Email and SMS Notifications by Compile Server

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

Non-modal intermediate file generation

Improvements of Timing Violations Debuging

Simple code lock for FPGA targeted VIs

Better check for Compile Server

Don't compile if not needed !

Auto Increment

Prompt the user when an FPGA compile has completed

FPGA Emulator Mode WITH REAL I/O

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

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

FPGA Bitfile Name & Location

Compiles Started over a VPN

Fixed Point numbers don't always show coercion dots.

Minimize Pre-Compile actions on the local computer when compiling FPGA code