Global Variables on headless FPGA

[NICommunityAlias]

Hi all,

So I wrote a program to run a multichannel PID control loop on a 9047 cRIO FPGA.  Each channel needs at least 3 values, for the P, I, and D constants, and a few others besides.  While building and testing the code, my workflow obviously involved a host program that I used to set and modify these constants using a .tsv config file and a FIFO buffer.

However, now that the program is ready to go, I would like it to run entirely on the FPGA - that is, if there were a power outage, or other interruption, I would like the FPGA to turn on, start running its bitfile, accept the inputs crunch the values, and send out appropriate outputs withOUT the user having to 'log in' in essence, using the host and set the PID constants.  These constants don't change often, per channel, given the large amounts of control channels, the associated hardware of each may require maintenance, refurbishment, or replacement, probably a few edits a year.

What I have resorted to, is simply creating an array of clusters in a global variable vi that itself lives on the FPGA target, at least according to the file structure shown on the project file - and, one assumes, has the associated variables and their initialized values written to the FPGA hardware on compilation.  The FPGA cycles through the indices of the array and unbundles the clustered values into their appropriate memory blocks for use elsewhere in the code.

Am I correct in this assumption?  Will this work?  Is there a smarter way to do this?  I can't test this system as we are down for maintenance, and the system is locked out.  Once we come out of maintenance, there will be an extremely limited window to do any shakeout of new code - I don't expect to be able to revise this code, so it either needs to work the first time or be rolled back to the old system, that requires a running host program, until the next maintenance.  Any advice is helpful.

[crossrulz]

Your "global" would be starting you out with whatever value you last compiled it with, not the last thing you set it to.

What I do is I use the RT of the cRIO as the message handler between the PC and the FPGA.  If the PID settings change, the RT can store the new values in a configuration file of some sort (ini, xml, json, etc.).  When the cRIO boots up, the RT can read those settings and set up the FPGA.

[NICommunityAlias]

This would actually be fine.  We need the *ability* to change these values, but they should not change with a frequency greater than ~yearly.

What I really, really need is the ability to *set* these values such that the FPGA on boot has access to them.  If it's necessary that I recompile the software every time I need to tune a channel, that would honestly not be the biggest imposition, given that its a qualitative improvement from not being able to do so at all.

I'll quantitatively dial in time-to-tweak once I have a working solution.

I do have a question though.  Between posting this and reading your response (thanks by the way) I did my best to implement it.  Just tested, and it did not seem to have worked.  Did I do something wrong, do you think?  And any ideas where I might have screwed up?  Otherwise I'll keep plugging.

Thanks again for responding!

[crossrulz]

---

@NICommunityAlias wrote:

I do have a question though.  Between posting this and reading your response (thanks by the way) I did my best to implement it.  Just tested, and it did not seem to have worked.  Did I do something wrong, do you think?  And any ideas where I might have screwed up?  Otherwise I'll keep plugging.

Most likely, yes you did something wrong.  What?  That is impossible to say without seeing code.

[NICommunityAlias]

Hmm, well, that would be proprietary information for the company I work for.  I don't think that would be possible.

But, if I'm reading between the lines, you're saying that this is possible in theory, and only bad execution of such on my part in the code would cause it to fail.  That was the essence of my question. 

I think I'll have to accept this answer and solve the rest on my own, maybe with the help of NI Tech Support, who have been much less helpful or responsive than you have so far. 

- Seriously, in terms of turnaround, and actually useable information, this has been a far richer source of info than the last two weeks I've spent trying to pull teeth from Tech Support, who, incidentally I'm cleared to share our code with, and have done so already.  Thanks.

[James_McN]

The extra piece you could be missing is I believe you need to set the values in the global variable and then set them as the default values. (Edit Menu > Make Current Values Default)

Then it should load with these each time.

[NICommunityAlias]

Thanks James,

I believe that I had done this.  I will double check - I'd be more than happy if the answer is I'm a bonehead.  Won't have the option to get under the hood for a while though unfortunately.

[Intaris]

---

@James_McN wrote:

The extra piece you could be missing is I believe you need to set the values in the global variable and then set them as the default values. (Edit Menu > Make Current Values Default)

Then it should load with these each time.

---

Correct, under the obvious assumption that you recompile your FPGA code of course.

There are two fundamentally different approaches here:

1) Changing constants and recompiling (you have solutions for this)

2) Allowing parameters to change at run-time (no recompilation neccessary)

These are very different from an FPGA point of view. Xilinx, when compiling with constants, can make a whole slew of optimisations and assumtions it cannot when the values "MAX" change. As such, your resource utilisation will change between the two solutions (not even accounting for the fabric required for the communications channel chosen). If space is limited on your device, you might get better results with just updating the globals and recompiling. There's a certain certainty about not being able to change values on FPGA, if it runs once, it should always run.