LabVIEW FPGA Idea Exchange

I've developed a small test utility for testing FPGA code on my windows machine before proper FPGA testing and have noticed something I think could be improved.

If I have a graph or any other indicator with DBL default data type within a conditional disable, the compiler still throws an error regarding an unknown state (DBL).  Although the terminal is in the diagram disable, the object seems to remain on the FP (but also in the code being sent to the FPGA compiler).

Can we actually remove the graph (or other culprit control) in the background before starting the actual compile so that I don't need to drop and re-connect every time I want to switch execution systems?

Shane.

On PC and RT targets, when you right click on a specific property in a property node, you can directly open the help for that property:

However, on an FPGA target, you can't open the Help for a specific property or method by right clicking:

What happens if you click on 'Help'? It takes you to a page that explains the purpose of a property node. Rarely if ever is that what I actually want. Instead, I want to know about 'Linearization Coefficient 1.' My only option is to open up the Help and search for that specific property, which may or may not be easy to find.

My suggestion is to add a direct link to the help for every FPGA property and method in the right click menu.

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.

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.

Old Title: FPGA Case Structure Needs To Display Enum Values

In LabVIEW the case structure can show enum values, while the FPGA case only shows the numeric value. Would like to see the below example capable in FPGA.

I have to remember to place a comment next to every memory element so that I can quickly know its size.  This is especially important because I can't get to the property window if I'm viewing the vi outside of the FPGA Target Scope. I can view the data type of a memory/FIFO element by hovering over the wire that goes into a read/write property with the context help window open, so I don't really care about that.  However I cannot view its size.  This could be fixed in one of two ways, add it to the context help when you hover over the element or display it directly on the memory element.

Typical Xilinx IP core icon like FFT and DDS looks like this - in expanded mode:

The connector labels are very hard to read. I guess everybody agrees on that this could be improved. And it is not that there is a "standard" narrow width to obey, for instance FIFO is wider than the Xilinx IP icons.

Thanks for considering this.

I have been working with FPGA for quite a while, and realized that manually opening and editing DMA, Target Scoped, P2P, VI scoped Memories, and project scoped memories can be very tedious and time consuming.  Wouldn't it be great if there was a way to edit FPGA FIFOs and Memories from a single place.  This notion gave birth to the FPGA FIFO Editor and FPGA Memory Editor.  These editors would give the ability to see, create, remove, and edit FIFOs or Memories for that specific project (list both project and VI scoped items).  Furthermore, their could be some additional logic built into the Editor that would alert the user when they have tried to configure something incorrectly (for instance an R Series target only has 3 DMA FIFOs, alert the user when they have configured more than that).

Listed below is  a mock-up of the FPGA FIFO Editor.

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.

The latest Virtex-7 FPGAs have something like 20 times the computing power of the biggest FPGA supported by LabVIEW FPGA; it would be cool to be able to get those on a FlexRIO card.

Other companies make FPGA boards with up to 32 GB of RAM, the biggest FlexRIO has 512 MB; would be cool to have FlexRIO cards with RAM in the gigabytes.

In a FPGA code, when you click in a function (Math, Array or Comparison) to create the first constant, control or indicator, like in an Add function, it's created as a Double (DBL) type, which is not suitable for this target. In this case, it will be better if the data are created as a Fixed Point (FXP). In other cases, like in Array functions, an Integer (I32) may be a better option. One thing is for sure: Should not be a Double!

Writeable inputs to FPGA I/O nodes can be left disconnected without any warning (or broken VI indication) from the VI in which the I/O node is used. This can cause some vigorous head-scratching if the missing connection is not immediately obvious as in the screen shot below. For obvious reasons, FPGA controls have no connector assignment or "Recommended, Required, Optional" attribute. In that case, and to avoid playing "Where's Waldo" on the block diagram, I suggest making FPGA I/O node input connections implictly "required", and if not, the VI would be broken. This would be the same behaviour as seen with cluster nodes. 

I didn't find something related to this, so I hope it's a new idea.

I use frequently VI scripting on LabVIEW, it is very useful for example to generate template VI's.

but this feature doesn't exist under FPGA, I mean some code is specific to this module, and I think it would be great to be able to generate FPGA VI's programmatically. For example in my job we make FPGA programming for Magnet Security. Even if global structure is the same for all magnets, we have to adapt a lot of things depending on type of magnet and instrumentation available. The idea would be to create ourself a kind of Magnet Safety Editor based on VI scripting specific for FPGA in order to allow non-programmers, but Magnet specialists, to generate themselves an adapted security system.

It's just an example, but when we see powerful of VI scripting for LabVIEW, it would give great results if it extends to FPGA, and even Real-Time  module, why not? 

Fixed point constants like to show you a lot of precision more often than not.  It would be nice to be able to right-click a number and instantly select hide trailing zeros.

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:

1. Attempt to connect to the Compile Server before generating intermediate files.
2. 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.
3. 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.

The loop timer express VI is very useful to time a loop to an exact rate, however... if you want to be sure the loop is meeting the rate requested... you also have to put in tic count VIs like this:

Since the loop timer express VI already is calculating how long it needs to wait in order to achieve the desired loop time, I would prefer it if at least output a bool that indicated it failed to achieve the timing required.

It would be best if it output the actual tics it waited in like I16 form so it could go negative (indicating the # of tics it failed to achieve timing by.

Now that most numeric operators have the ability to saturate it would be nice to be able to differentiate these operations.  I know that the majority of the time you can determine this information easily with the context help but this would make it much easier to spot.  I tend to copy operators that are already being used in my vis than to grab a new one off the pallet.  This would let me know which type of operator I'm copying.