10-23-2014 05:19 PM
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.
10-23-2014 05:58 PM
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.
10-23-2014 06:31 PM
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.
10-24-2014 11:47 AM
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.
10-24-2014 12:02 PM
10-24-2014 12:17 PM
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.
10-24-2014 07:37 PM