Impossible simulation condition with LabVIEW FPGA

[yuval_yohai]

Hello,

I am working with LabVIEW 2013 FPGA in simulation mode.

While trying to analyze one of my code problems I have noticed an impossible and very frustrating simulation condition.

Please have a look at the photo I have attached.

Same lines, same clock cycle yet different values.

Is there an explanation for that?

It is impossible to debug my code while not knowing if this is a simulation error or an exact behaviour of the code (which makes the whole LabVIEW FPGA unusable).

Reagrds,

Yuval Yohai

[natasftw]

None of those are the same line.  You can't put a probe on the same line.

The problem isn't the stability.  The problem is you're expecting a simulation to be 100%. 

I'm expecting you've got the same line being wired into the greater or equal and that's hidden behind the probe's number.  Because these aren't equal, you're concerned.  But, you haven't shown us what values are going into the greater/equal even by probing that line.  The coercion dot on the input shows this.

What's your actual complaint?  You're working with a SCTL, which is something that exists on the FPGA.  How would this reasonable exist in simulation?  I'm looking through the code for anything that might be as damning as you suggest but honestly not seeing what's concerning you.

[yuval_yohai]

Hello natasftw,

Thanks for your response.

This is a part of a larger application which I am trying to debug. I have found timing problems and started going deeper to find out their source. Then, while tracking probe 43 (in the picture) I have noticed its values are wrong, yet, its inputs are correct. When I did the presented test I got out these resutls which are impossible to understand.

The line of probe 35 is the same line of probe 34. The value flow into the case. The case is allways false (see probe 39). How come that on the same clock I get different values?

BTW, the same problem applies to probes 38,36. There are two different values on the same clock while they are both on the same line.

Regards,

Yuval

[ZX81]

I see what you mean.  The probe 34 gets a value of 41 BEFORE probe 35 does.  But it seems obvious 34 gets its value from 35.

1. Does that behavior show up at the beginning of the sampled period?  (shift the display to t=0)

2. Were all probes set up at the start of the simulation?  

In both cases, I'm looking for a simulation bug, where the displayed values for one of the probes is out of sync.  In particular, since the 'true' case gets executed rarely, the number of values recorded for 34 will be a little less than the number of values recorded for 35 (one less for each 'true' case).  An easy bug for the simulator would get the data out-of-sync each time, instead of putting a blank (or more accurately the calculated value) in place of the missing sample.  If I'm right, where it's off by 6 here, at the beginning, it will be correct, and get off by 1 more each time the count makes the case 'true'.  A quick way to test that is to put a probe in the 'true' case, and see if it is WAY off.

3. Have you checked for hidden tunnels?  It looks unlikely here, but it's easy to accidentally create tunnels that go to the wrong thing, but right on top of another tunnel.  Try moving the tunnels a little, to see if one is hidden underneath.

4. Is the shown case 'false'?  Inside the FPGA, the +1, and other elements may actually execute regardless of whether the input to the case is 'true' or 'false'.  But the results will get ignored for the wrong case, and saved for the right case.  So you may see values on probes that aren't really executing.  But that would mean the simulation is more accurate than I would expect.

[yuval_yohai]

Hi ZX81,

Thanks fpr yoiur reply.

Here are the answers according to your numberings:

1. Probe 34 gets the values of probe 35 very late in turms of number of clocks. I could live with 1 clock delay but this is too much, besides, at the beginning of the simulation the values are correct. This phenomanon is drifting as the simulation goes on and the delay getting larger and larger.
2. The program was stopped, then probes added in, then run from scratch. I also restarted LabVIEW completely and the problem persists. I made your request and put probes in the TRUE case as well. The inconsistancy continues. I will add another photos of TRUE and FALSE. In the new photos you will see I have changed the code a bit and used external shift registers. The problem perssists.
3. I did checked, in fact I have re-drawed the whole problematic area from scratch again just to make sure.
4. I couldn't find evidence to that.

As general, I am quiet desperate from this by now and in an urgent need for a way to debug my code therefore I will rebuild this portion of the code using select nodes rather then cases. I hope that will do. I will post here my results.

Still waiting for some light on the metter.

Regards,

Yuval Yohai

[dkfire]

---

@yuval_yohai wrote:

Hello @natasftw,

Thanks for your response.

This is a part of a larger application which I am trying to debug. I have found timing problems and started going deeper to find out their source. Then, while tracking probe 43 (in the picture) I have noticed its values are wrong, yet, its inputs are correct. When I did the presented test I got out these resutls which are impossible to understand.

The line of probe 35 is the same line of probe 34. The value flow into the case. The case is allways false (see probe 39). How come that on the same clock I get different values?

BTW, the same problem applies to probes 38,36. There are two different values on the same clock while they are both on the same line.

Regards,

Yuval

---

Just one comment there, 36 and 38 is NOT on the same wire, there is a tunnel/border crossing.
The time when a output of the case structure is pressent depends on all the functions within the case structure. You have e.g. a write to memory in the case structure, how many circle does that take? 

Remember that LabVIEW is dataflow, nothing can come out of a structure until all the code in the structure has completed. 

[ZX81]

I think #1 in your reply confirms my suspicion.  To avoid it, only put probes on wires at the same cases.  I.E. Only put probes outside one case, but inside the other.  I would say to wire from probe [3] to a temporary tunnel at the outside case, and probe between the cases, but that's already [2], and to wire from probe [4] to a temporary tunnel on the outter case, but that is already [5].

What I think is happening is something like this:  

On the outter loop interation, [I] =  98   99  100                                                               101  102

Probe 2 =                                           98   99  100                                                                   0     1

Probe 3 =                                           98   99 (no value, because it isn't executed)          0     1

Probe 4 =                                           99   100 (no value, because it isn't executed)        1     2

Probe 5 =                                           99   100   0                                                                    1     2

But what gets displayed is

[2]:  98  99  100  0

[3]:  98  99    0     1

[4]:  99  100  1     2

[5]:  99  100  0     1

In reality, probes 2 and 3 are the same value (when 3 is executed), and 4 and 5 are the same value (when 4 is executed), but the display is wrong.  That would be an NI software bug (a pretty dumb one, too).

There may not be anything you can do about it, except to only probe from the same area.  Does the .vi behave like you would expect, if you ignore the timing of the probes?

[ZX81]

I can replicate the bug.  And it is a LabView simulation bug, even in LV-2014-SP1.

In my case, I stripped down the problem to a much simpler case.  I put a timed loop (2.5MHz derived clock), with a condition that would only be met occasionally.  With only one case statement, I couldn't replicate it.

I added a second case statement inside the previous one, and have it kick off even less often.  But I can see the bug show up before it ever does its special case.

When I look at the Sampling Probe Watch Window, I can see several probes that should always track their values together (like yours; one is an input to an increment, the other two are outputs).  While I scroll the watch window, the first 20 steps track nicely.  But when I scroll to see the 22nd step, one probe shifts, and steps 14-23 are off by one (the output comes BEFORE the input).

I tried with a timed loop (2.5MHz derived clock), and with a simple while loop.  Each time, the error was an even number of loop iterations, not 40MHz clocks.

In one case, I was able to see a case where the input to a case block's tunnel led the output by two loop iterations (one clock is possible, but it should be instant).  If I scroll the Samplilng Probe Watch Window to the right, then back, the display for the exact same place shifts, and shows that the output LEADS the input.  If I scroll left, then back, the output LAGS the input again.  That's conclusive proof that the display is wrong (the same record is displayed differently).

Removing all my probes from the inner case statement DIDN'T fix anything.  But when I brought all the signals together (I used a cluster to give them somewhere to land), I was able to probe all the signals at that single level, and it worked great.  That is, probes 25, 26, 27, 28, 29, and 24 worked as expected.  16, 18, 20, and 23 were screwy.

[T-REX$]

Hey ZX81,

Any chance you could attach that VI for me? I'd like to reproduce it on my end and file a bug report if I can...

[ZX81]

Sure.  I put it in a dummy FPGA; I'm sure any kind will work (or rather fail).