LabVIEW FPGA Idea Exchange

Proper unit testing is a key component of large LVFPGA project success.  As the number of modules grows, so does the number of units tests increase.  We are working on automatic continuous integration methods that will continue to monitor the accuracy of all modules and assemblies throughout the project life cycle.  IP Integration node and NI's wrapper around Xilinx IP makes this task more difficult.  When our continuous integration machine refreshes the source code from the repository it has to regenerate these nodes in order to compile.  The "Regenerate IP Integration Node Support Files..." tool does not always properly update all IP.  It seems like the NI wrappers around Xilinx IP are most problematic.  The only way a computer can properly update its version of the node is to open the VI and click through the Xilinx IP generation pages to get it to update.

As a rule we do not commit build products into our source code repository.  One option would be to submit all the support files generated when first creating the IP integration node so that others users might not have to update.  This can become messy and quickly unwielding.  The problem arrises when changes to the IP integration node cause more or fewer support files to be generated.  This then requires deleting some files from the repository and adding others which is tedious and leads to errors.  One compromise would be if the IP integration created one single compact file that contains all the information needed (expect the input vhd, etc. files) that could be committed to the repository.  Even better would be to roll this information into the VI itself.  Neither of these might be ideal if the support file contents take up a lot of disk space.

Regardless there needs to be a better solution to allow for automated continuous integration testing.

Long compile times are a necessary evil of FPGA code.  Even with the vast improvements of Vivado, compile time still ranks as the biggest killer of large project efficiency.  As compile times approach 3-4 hours, their successful completion becomes paramount.  All too often I find that the Xilinx compiler running on the compile worker has completed successfully however some small communication glitch either between my development machine and the farmer or the farmer and the worker has caused the compile to be lost.  It is quite frustrating to know you have a completed bitfile from Xilinx but the NI tools will not perform the final processing steps required to create the lvbitx file.  The only solution is to restart the compile costing another 3-4 hours of productivity.

Typical workflow in our company for these large projects is to spend mornings testing and stressing the compile(s) from overnight.  Then make any bug fixes and incremental feature improvements and try to start a compile by mid-morning.  By mid-afternoon when the compile is complete do the process again so that you can process another build for overnight.  If one of the compiles fails because of timing or resource problems, there's nothing that can be done.  But if it fails because of glitches in NI's compile wrapper code, that becomes a waste of a half of a day of productivity.

I propose that the current methods for compiling bitfiles be modified.  The goal is to improve user productivity.  Some of my suggestions include:

• For a given build specification, give it the ability to re-attempt to retrieve the last completed compile. This option would be available even if the VI's that created that compile had been modified.
• If a compile was completed previously for this build specification and there has yet to be a successful lvbitx generation, prompt the user before doing anything that would destroy the ability to retrieve it.
• Make sure that all of this still works when changing connections to the worker.  For example if I start my compile at work then take my laptop home and want to login to my VPN at night to check on my compile
• Don't remove any chance to get a compile if there was a communication error.  Right now when I get the communication error, I see a red X in the compilation status and my only option is to remove it from the list.

When there are many controls on the front panel of the FPGA, selecting the control from a Read/Write Control node in the host can become a pain.  It is one very large list of controls on the front panel of the FPGA.  This list has no scrollbar, no browse, or search feature, and no obvious way of grouping controls.

Here is one example of a front panel, and a video showing how long it takes to scroll through the list of contorls.

And here is the video of me scrolling through the controls:  http://screencast.com/t/PLzptTwq58aw

There is plenty of room for improvement.  Here are just a few ways I think NI could make this better.

Browse and Search

When using a Property Node, or Invoke Node, the very top option is to "Browse..."  From here a list of all properties, or methods can be seen in a resizeable window.  Here you can also search, and sort alphabetically.  The Read/Write Control node could have similar functionality making selection of controls easier.

Front Panel Selection From FPGA

There could be an option for creating a node by selecting the controls on the front panel of the FPGA.  A solution that may work today, is to select the controls, then invoke a custom QuickDrop command that creates the node and puts it in the clipboard so it can be pasted in the host VI.  If this were to become an option, I'd hope there is a way to combine two nodes into one, by concatenating the controls of one onto the other. 

Front Panel Selection From Host

Lets say you already have the Read/Write Control node on the host.  There could be an option by right clicking that would open a new window, showing a static image of the front panel of the FPGA, which the user could then click on.  This would be great because the developer probably already knows the control they want based on the front panel location.  I don't know how possible this is because you could load a bit file which won't have any front panel information. 

Easier Grouping of Controls

Right now there is a way to group controls of an FPGA.  This feature is never talked about, and doesn't work on dynamic bit files.  Here is a discussion where I describe the steps to make controls grouped on the host.  Still this isn't supported on all FPGA setups, and you have to conform to a specific naming convention.  Why can't controls that are grouped on the front panel, just be grouped in the host?

This idea exchange is really for any kind of improvement to the FPGA control selection.