Accessing FPGA conditional disable symbols from the host machine

[solarsd]

Hi,

Is there a way to programmatically access FPGA conditional disable symbols from the host machine? I would like to have a host VI that could know whether e.g. the FPGA bitfile was compiled with ENABLE_AO or no.

[nathand]

No, there's no way to do this because the value of conditional disable symbols are not part of compiled code. At compile time the conditional disable determines whether to include or exclude portions of code from the build, and once the build is finished there's no built-in way to know what value of those symbols was used for the compilation.

You should add a couple of indicators to the FPGA front panel and hard-code constants to them that indicate the values of the relevant conditional disable symbols. The cost in FPGA logic is minimal. The constants should of course be placed in a conditional disable block, but the indicators should not.

[pobrepablo1]

just to illustrate nathan's point

. 

[Dragis]

I agree with nathand. In general, you want to be able to query information about the compiled FPGA application rather than rely on whatever the current set of conditional symbols is. So use conditional symbols in the FPGA to set up configuration registers (or any other feature you want to use to communicate the values with the host) and then ask the FPGA for that information when you open a reference to it on the host.

[solarsd]

nathand:

Thanks for the tip. I was about to resort to something like this, but I thought that this would be wasteful in terms of FPGA resources, I didn't know it was minimal. By the way, do you happen to know in more detail how something like in the example by pobrepablo1 (btw, thanks for the illustration) would be implemented in the hardware? What's the cost of a FPGA front panel control? I was getting the impression that it is substantial - in one case I was only able to fit the VI into my FPGA by changing some controls to constants.

I find such symbol behavior odd, to be honest. I realize that these symbols are gone after compilation, but everything is managed in a LabView project, so the symbols should be available throughout. I believe changing the value of a symbol will trigger a FPGA bitfile recompile anyway, so the "source" and binaries are kept in sync. The FPGA "bitfile", as I see it, must have some host code interfacing with the FPGA card hardware driver, that's where the state of such symbols should be exposed to the user in my opinion. Just trying to understand the logic behind this.

[nathand · Accepted solution]

---

@solarsd wrote:

Thanks for the tip. I was about to resort to something like this, but I thought that this would be wasteful in terms of FPGA resources, I didn't know it was minimal. By the way, do you happen to know in more detail how something like in the example by pobrepablo1 (btw, thanks for the illustration) would be implemented in the hardware? What's the cost of a FPGA front panel control? I was getting the impression that it is substantial - in one case I was only able to fit the VI into my FPGA by changing some controls to constants.

---

You can get an idea of the resource utilization from Resource Utilization Statistics for FPGA VIs. By way of example, I picked an FPGA at random from the ones listed, and the table shows that a boolean control or indicator uses 3 flip-flops and 3 lookup-tables, which is almost nothing. A constant uses 0 resources (no logic). If your conditional disable constant can have more than 2 values, an 8-bit value isn't a lot more expensive. If you have more than 256 possible values for a conditional disable, you're probably doing something wrong 😉 Of course, I would not recommend using a string as in pobrepablo's example, since that would be very expensive. That's as much detail as I can provide.

---

@solarsd wrote:

I find such symbol behavior odd, to be honest. I realize that these symbols are gone after compilation, but everything is managed in a LabView project, so the symbols should be available throughout. I believe changing the value of a symbol will trigger a FPGA bitfile recompile anyway, so the "source" and binaries are kept in sync. The FPGA "bitfile", as I see it, must have some host code interfacing with the FPGA card hardware driver, that's where the state of such symbols should be exposed to the user in my opinion. Just trying to understand the logic behind this.

---

You can configure LabVIEW to open a bitfile on the FPGA directly, without the VI that was used to compile it. In this situation the VI and bitfile aren't in sync, and the bitfile could have been compiled in a different project with a completely different set of conditional disable symbols. The only way to guarantee that the bitfile is compiled with the right settings is an indicator on the front panel. You can take a look at the bitfile, it's just XML, and it doesn't even include the version of LabVIEW used for the compile. You can use a bitfile from one version with a host from another so long as the bitfile format hasn't changed. The conditional disable symbols are stripped before the VI (in intermediate form) is handed off to the Xilinx tools that actually create the bitfile. NI could add additional information, such as the value of conditional disable symbols, to the XML bitfile but there would need to be enough demand for them to do that and they'd then also need to add a mechanism to access that information. I could be wrong, but I'm not sure enough people would find that useful to be worth making the change, when it is so easy to add a front-panel item. Still, you could post it to the FPGA idea exchange and see if there's interest.

[solarsd]

Thanks!

That was really helpful and with all the details I needed.