Problem modifying FPGA code in an Application Builder-based system

[jtele1]

I've inherited a working test system which uses LabVIEW FPGA, LabVIEW, Application Builder, and third party tools.  The FPGA module (a FlexRIO) is responsible for generating test signals to a DUT and acquiring DUT output data.  The host LabVIEW code controls the FlexRIO and acquires the test data.  Application Builder is used to convert the host LabVIEW code to a Windows DLL so that it can be in turn controlled by higher level data analysis software running on Windows.

All of this currently works, and we're using it on a daily basis to test production devices.

We need to modify the FPGA operation to change the way the tests operate.  We've modified the the FPGA VI to operate as we need it to and rebuilt the FPGA code (resulting in a new bit file), but subsequent runs of the test stack do not show the change to the operation of the FPGA code (the signals it is generating look exactly the same as in the original, unmodified, VI).  We've tried renaming, deleting, and moving the bit file, but operation of the system is always exactly the same, even when the bit file is named differently or not located in the expected directory.  We can't seem to affect the behavior we get out of the FPGA.  It seems like we're not rebuilding something correctly, or that the system somehow has a copy of the old bit file stored away some place that it's using instead of the desired bit file.

We've verified that the newly created bit file is different than the original bit file, so it appears that the FPGA build process is succeeeding.  I see no errors from LabVIEW when I build the FPGA code.

Does a DLL-ized version of LabVIEW host code operate the same as the same VI run from within the LabVIEW environment?  When the DLL loads the FlexRIO, does it do so from the same referenced file path (I have the "Open FPGA VI Reference" properties set to use the bitfile, and the "Run the FPGA VI" checkbox is checked).  We've power-cycled the host PXIe chassis between software runs to make sure the configuration memory in the FlexRIO is cleared.

It seems highly suspicious that we see the FPGA come up and run even when the bit file has been renamed or moved from the directory indicated in the "Open FPGA VI Reference".  I would think that the DLL would attempt to open that file, fail to find it, and trip some sort of error dialog.  But this doesn't occur, the FPGA gets loaded normally, and the test system operates as if nothing had been touched.

Previous developers were able to make this build process work, but it seems we're missing some critical step needed to actually update the code that ends up running on the FPGA.

The system is LabVIEW 2012.

[David-A]

You need to use a Open Dynamic Bitfile Reference in your host VI if you want to provide a path to a different bitfile rather than recompiling your DLL every time you want to use a new bitfile.

Thats because the Open FPGA VI Reference statically stores the bitfile information in the VI when you compile your DLL. Think of the Open FPGA VI Reference as a string constant with a string that is megabytes worth of data in length and you'll get the idea on how the bitfile information is stored in the VI when you statically reference a bitfile.

[jtele1]

Thanks for the reply, that's very informative.  If the DLL is storing the bitfile information, that would explain why deleting the bitfile from the host drive didn't impact the software's ability to configure the FPGA ( the DLL doesn't need the disk file since the DLL contains a copy of the bitstream information).

However (and sorry for not mentioning this), I did rebuild the DLL after rebuilding the LabVIEW FPGA code.  So presumably the new DLL would have included a copy of the revised FPGA code.  But the FPGA behavior didn't change.  Is there a trick when building the DLL that is necessary to get Application Builder to reload or re-reference the revised bitstream file?

Note that I'm not trying to change the bitfile name, just update its functionality and rebuild the software system.

[David-A]

How confident are you that the Open FPGA VI Reference was pointed to the new bitfile? If the bitfile has the same name as the old bitfile it sounds fairly easy to mix the two up.

You can right click the Open FPGA VI Reference and have it show the path to the bitfile directory. This may help clear up any confusion on which bitfile is being used if they are stored in directories that have a name that indicates which version they contain. 

Using the Open Dynamic Bitfile Reference would likely resolve this issue, but it would require you to ship bitfiles alongside the DLL which may be a suboptimal file management experience compared to just building the bitfile into the DLL.

[jtele1]

The FPGA build definition has the bitfile filename hardwired into it, so the name is constant across rebuilds of the FPGA code. So we always have the same bitfile name (and consequently if we're not careful about saving the old files, then the old bitfile will be overwritten by a new build). I could try your suggestion about the alternate calling method, but I'm hesitant about changing a build process that was known to work. It seems to me that I'm somehow not building the software correctly, as if I don't understand something about the DLL build process that's keeping the new FPGA code from being used. To reiterate, our build process is: 1) Modify the LabVIEW FPGA VI 2) "Run" the FPGA VI to compile it (by the way, last night we tried a "Rebuild" on the FPGA code from the right click menu off the VI in the LabVIEW project and that also has failed to change the results) 3) Build the host DLL code by right clicking the DLL build definition in the LabVIEW project and selecting Build 4) Copy the resulting host DLL over to the directory location where the higher level Windows software expects to find it 5) Run the higher level Windows software (at which point we view waveforms generated by the FlexRIO to see if the FPGA's behavior has changed). We've verified that the LabVIEW DLL won't rebuild if we rename the bitfile (LabVIEW gives an error saying it can't find the bitfile). We've also verified that the higher level Windows software won't run if the LabVIEW DLL is renamed in its directory (so we know that that exact copy is being opened by the Windows software). Yet we can't seem to modify the FlexRIO's behavior through this process.

[David-A]

Between step two and three you need to verify that the new bitfile is in fact the bitfile that the Open FPGA VI Reference is pointed to. There is A) the bitfile that Open FPGA VI Reference is pointed to and B) the bitfile that pressing run on the FPGA VI generates. You need to verify that they're the same bitfile. It's easier to do this if you use a build specification rather than pressing run on the FPGA VI.

[jtele1]

I think we've verified this in two ways: 1) If the bit file is renamed, the host VIs referring to it will not open and LabVIEW requests the location for the missing file 2) If the bit file is renamed, the DLL will not build, again with a similar error about the missing file. In both cases, if we rename the file back to its correct name, the VIs will open and the DLL will build. If the host VI were not referring to the bit file of interest (but instead to a different file), then I would think that neither of these errors would occur as the host VI would still be able to find the file its looking for. We're going to attempt to build/rebuild a plain host VI which will refer to the bit file of interest, and run the FPGA code directly from LabVIEW rather than through the DLL. This should tell us if the bit file is the problem (i.e. we're somehow not rebuilding the FPGA code and working with the same FPGA functionality) or the DLL is the problem (if by running the FPGA code via LabVIEW we see the modified FPGA behavior, then we can be sure the FPGA code is being updated and the problem is with the higher level software).