From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
06-12-2018 03:13 PM
Unfortunately no Wizards live here.
I was however able to confirm the problem children subVIs are the IBGT_Combiner.vi, IGCT_Combiner.vi and the ISF_Fault_Reporter.vi. Copying these subVIs with a new name, *_FPGA3.vi, and then replacing the original subVIs with the new *_FPGA3.vi on the FPGA3 Main VI fixed the compile issue. The common thread to these VIs is global FIFOs. I wonder if anyone could elaborate more on this issue. Is it expected behavior or a bug? We're going to try to change these FIFOs and see if that fixes the problem.
11-08-2018 03:00 AM
Good morning every one,
I'm facing the same issue and it's quite annoying, especially because the compiling time is very long. Some one solved it? or at least have an idea of how facing it?
11-08-2018 04:24 AM
If you use the code in more than one project and the definition of those FIFOs differ even slightly, that will cause a re-compile notification. Arbitration, FIFO length, you name it, they all count as changes. In fact, even the same configuration, but different project path may be enough, I don't know.
Personally, I instantiate as much as humanly possible in my code so that I have as close to zero dependencies on project-defined items as possible. Unfortunately, DMAs cannot yet be instantiated ont he BD.
11-08-2018 04:36 AM
Hi Intaris,
thanks for your response. It is strange, because in fact I just have one project open. I really don' t understand this issue..
11-08-2018 04:55 AM - edited 11-08-2018 04:55 AM
Hmm, yeah. I've run into cases like these in the past too, something internal to NI changes for some reason (also utilised in more than one target perhaps?) and the whole hierarchy needs to be re-compiled.
We use practically no NI VIs in our FPGA code now, pretty much only our own VIs, NI Primitives and Xilinx IPCores.
11-13-2018 11:27 AM
The problem in our project was related to the use of subVIs that were writing to Target-Scoped FIFOs. The references to the FIFOs were originally hard-coded into the subVIs and the project uses three different targets resulting in the top-level VIs needing to synchronize the multiple instances of the subVIs every time the top-level opened and thus prompting a recompile. I think the "best" fix would be to change the FIFOs to VI-scoped, but we haven't tried this yet. Instead we found two other work arounds:
1. Change the subVIs so that each target's subVIs have a unique name. To be clear not all subVIs needed unique names, only those writing to this FIFO. This worked but was a bit tedious to update all the subVI instances to the correctly named versions and it undermines the reusability of the VIs (now can only be used on one target versus all project targets).
2. Make the FIFO reference an input to the subVI instead of hardcoding it in the subVI. This is the change we presently have implemented. Now the subVIs accept the FIFO references as inputs and each target provides different references therefore eliminating the need for any instance synchronization.
Hope you find this helpful. It took us a while to figure this out. I figured it out by watching closely which VIs were saying they had changes that needed to be saved. This provided the clue needed to track down what part of the code was causing the problem.
Best,
Pegasaur
11-13-2018 06:14 PM
I use version 2.
Note that you can select whether the reference required Read, Write or both. This way, you can actually wire up DMA FIFOs, or normal FIFOs depending on whether you have a test running or your "full" software.
I find it a most useful way of doing things.