fpga simulation port

[Sabine123]

Hello,
I am trying to simulate a FPGA VI with a "normal" VI. Up to now that is working quite well, but now I have weird effects reading a port. One Port (8Bits) is read out from two(!) different parts of the FPGA VI. The one part is using the higher 4 bits and the other is using the lower bits. With the Simulation I try to count these Nibbles up or down separately. The nibbles should wrap around. (E.g. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1...). The problem in my simulation is that sometimes, especially in the beginning, one step is left out (e.g. 0 1 3 4 5). This error is not happening if I am disabling one of the parts of the FPGA VI where the port is read out. So if the port is only read out from one(!) part in the FPGA VI, it works without these "errors". The most important parts of the simulation VI ist attached.
Some people said me it might be a Race Condition. I cannot see that that is an Race Condition. A Race Condition can only occure if you have two threads accessing one variable. In my case the variable is only read and later changed in one VI at one place. According to my understanding the Simulation VI (from which I attached the picture) is called when the FPGA VI reads from the appropriate port and only after the Simulation VI has finished it can be called again.
Moreover the simulation is only working, if I am using these global variables (which are also used in the tutorial from National Instrument: http://zone.ni.com/r...nch_tutorial/)! If I am using a local variable to change the data, nothing happens not even a local indicator changes!

I hope someone can help.
 

Greetings

[SFK]

Hello Sabine,

what you experience actually is a race condition. Not regarding the data that you store in your global variables, but regarding the variable access itself.

A global variable is a special type of VI with a reserved data space to store your data. Access to memory is granted exclusively only one caller at a time to prevent simultaneous readings of data that is currently overwritten.

So the "skipping" that you see is probably caused by a variation of your manipulation-read-manipulation-read order: a read access is denied as writing still occupies the memory, and the next write begins before the read function tries for the second time...


Unfortunately, there is no direct remedy for this, as all memory operations must be protected from simultaneous access - my best suggestion would be to use a functional global (subVI with a one-iteration loop with uninitialized shift registers) to store and manipulate both nibbles, which would enqueue the port value consisting of both nibbles into a (maybe even single-element) queue which is read (dequeued) in the "other" part of your application.

Best regards,
Sebastian