6 replies to this topic

[werner]

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. I hope someone can help.
Greetings

Attached Thumbnails

• 

[JohnRH]

At first glance it looks to me like a classic race condition caused by your use of global variables.

Time prevents me from looking at it too close, but I'll bet that if you get rid of the globals or rigorously control when they get written and read, that your problem will clear.

Edited by JohnRH, 14 July 2009 - 12:32 AM.

[werner]

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...bench_tutorial/)! If I am using a local variable to change the data, nothing happens not even a local indicator changes!

[lindapret88]

This is an interesting post.. thank you for sharing


taux pret auto

[SciWare]

I don't know if it will help at all without seeing the rest of your code but try data flowing those two case structures together, ie left one must complete before right.

[werner]

OK I attached the whole Simulation VI. I deleted the most of the other stuff to make it easier to have a look at it. The FPGA VI is not attached, but what it does is very simple: It has two case structures which will be called over and over again. Both of these case structures who look almost the same are reading the PortA at the same time. Now this is what happens, if I start the simulation "current array index Kl_" and "... Kr_" are always the same. They show a sequenz like this:
0 () 6 () 4 2 1 7 6 4 2 0 6 4 2 ...
or a little bit different like this:
0 () 6() 4 2 0 6 4 2 0 7 5 ...
What I would expect is: 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1....
The brakets () show that the numbers in this case where moving too fast (why? I dont know). The other numbers later are changing, as specified with the delay, every 500ms.

I dont have a solution for this weird behaviour, but I found a workaround. I just changed one PortA blocks in the FPGA with another free port (e.g. PortB). And made another case frame in the simulation VI. Now everything works as expected.

PS.: Ignore the comment below my picture. It was generated from LabView.

Attached Thumbnails

• 

Edited by werner, 15 July 2009 - 07:27 PM.

[ShaunR]

Change the rotate to a logical shift.