Designing Reliable Embedded Systems Presentation

[Burt_S]

Sometimes our specifications are conservative so I did a little research on the 9802, but it looks like the 2 MB/s is a pretty accurate upper bound.  Unfortunately I am running out of suggestions at this point.  I have no doubt that you have already considered this, but is there any way you could send the data over a network to be logged somewhere else? 

Also it looks like you are achieving the rates you need up until the 80% utilization, but I figured I would link an article on optimizing File I/O in LabVIEW RT just in case it could help.

http://www.ni.com/white-paper/3746/en/

[Daklu]

Burt,

Once again, thanks for the links.  I had heard of the implicit enable signal before, but it never occurred to me it (the Enable Clear signal, to be specific) could be used to control whether or not the bitfile is "running."  Makes sense though.  I think I'm starting to get it.  Here is my current understanding--tell me where I go wrong:

Running and Stopping an FPGA vi

Invoking the Run method on an fpga refnum resets the Enable Clear signal, allowing the vi to run.

Invoking the Abort method on an fpga refnum sets the Enable Clear signal, which stops the vi.

Invoking the Reset method on an fpga refnum sets the Enable Clear signal and resets all memory to the default values.

The Open FPGA Reference "Run the FPGA VI" option controls the state of the Enable Clear signal when the bitfile finishes loading.

Closing an fpga refnum sets the Enable Clear signal.  If "Close and Reset" is selected, it also resets the fpga memory (assuming there are no other open refnums.)

The fpga build option "Run when loaded to FPGA" controls the state of the Enable Clear signal when the bitfile finishes loading.

Loading an FPGA vi

Opening an fpga reference loads the bitfile when it is called.

The RIO Device Setup "Autoload on device powerup" causes the bitfile to load whenever the system is powered on.

The RIO Device Setup "Autoload on device reboot" causes the bitfile to load whenever the RT system reboots.

Okay, that's all the background information.  Here's the question I've been trying to articulate:  Is it correct to say the RT Watchdog only resets (reboots) the RT target, and the System Reset function only resets the fpga target, keeping in mind that certain combinations of the options above may cause rebooting one target to also reboot the other target?

Other questions:

- Having the run-when-loaded option available in two different locations always confuses me.  When the settings conflict, how does LV decide whether or not to run the vi?

- I'm still curious about the "Do not autoload VI" option in RIO Device Setup.  What's the use case for that option?

[Aaron_G]

I believe that there is an exception to the Invoking the Abort method. Specifically, if you have poorly written code that calls multiple opens (same bitfile) on the FPGA and you do not close the extra references (leak them), then the Abort, Close, and Close and Reset methods do not work since there are still "active" handles. At least this was the case with LabVIEW 2012.

[Burt_S]

I think you have summarized everything pretty well.  One addition I will make is that the Open FPGA Reference function only loads the bitfile if it sees that it isn't loaded already.  If the same bitfile is already present, it will instead give you an active handle to it.  Also from my understanding, running an FPGA VI that is already running will restart the execution of that VI but will not clear out things in memory.  If you were running a state machine on the FPGA for example, re-running the VI would place the FPGA back to its initial state.

For your question, the System Reset IO node on the FPGA actually only resets the RT target as well.  The FPGA may also get reset if the RT application is programmed to do so when it re-loads, or if you have downloaded the FPGA to flash memory and have configured it for 'Autoload on device reboot'.  If you are wanting the ability for the FPGA to reset itself, you can place your entire FPGA program in a while loop that begins by reinitializing everything.

When you say having the run-when-loaded in two different locations, I am assuming you mean on the FPGA open and in the build specifications.  The purpose for the setting in the build specifications is so that the FPGA can start running when it is loaded from flash.  In order for this to work, the compiler must change the default behavior of the FPGA VI to running so that it can execute without interraction from the host.  When used properly, the two settings actually should disagree with each other.  If I am loading the VI from flash, then I generally want my FPGA Open function to connect to the already running VI without re-running it.  The flag in the FPGA Open should therefore be set to false while the build specification flag is set to true.  Alternatively if I am not loading the bitfile from flash, then the bitfile won't load until I call the FPGA Open function.  In that case, its better not to check the flag in the build specification so that I have control over whether or not I want it to run immediately when opened.

A best practice that I have learned is never to set the 'Run the FPGA VI' option inside of the Open FPGA function.  If the bitfile is loaded to flash then this is usually a bad idea.  If its not loaded from flash, I usually want to call the 'Reset' method anyway to clear out memory in the FPGA.  I also don't like having important configurations like that hidden from me at first glance, so I prefer to call the 'Run' method explicitly.

I have never once used the 'Do not autoload VI' option in the RIO Device Setup.  I can't think of a use-case where you would want the bitfile loaded to flash, but don't want it to start running automatically.  That is not to say that there isn't a valid use case that I just haven't come across yet though.

[Burt_S]

I wanted to summarize by saying that in the end this is actually pretty simple in that everything generally falls into one of two use-cases.

If you need the FPGA to be running independent of RT, and would like it running at powerup, load it to flash memory.  This means you check the flag in the build specifications, you use the 'Autoload on device powerup' option, and don't don't run or reset the FPGA on the RT side (at least not automatically, you might if run into a different condition that calls for it).

If you don't care about having the two independent, don't check the flag in the build specification, and instead open a reference in RT, call the reset method, and then run it. 

Picking one of these two options has yet to let me down.