FPGA LVOOP Issue

[Qbits]

I am trying to understand why the LabVIEW compiler (when creating intermediate files) is having problems when shifting the data back around in a loop.  If I don't use a shift register it compiles fine.

 

My thought is that this has something to do with dynamic dispatching, but since the data type isn't changing between iterations (when using the shift register) it should be fine.

 

Attached is the code (LabVIEW 2012).

 

Does anyone have any insight why I'm having a problem?

 

Thanks.

 

 

 

Test FPGA.zip

[shoneill]

Well I'd guess that the compiler doesn't know yet that the VI guarantees the same output object type as the input.  I agree that this should work, but the compiler needs to check for situations where it KNOWS the type will be maintained abd it seems to be lacking here.

 

I would say that you should file a bug report.

[JamesMc86]

The issue is actually not related to OOP. The error I see is related to the references within the object. It is illegal to use these on a shift register as it allows the potential for it to be changed but its value must be resolved at compile time.

 

If you create a shift register then wire a reference too it then it will normally break the VI immediately. Obviously an issue here is that the compiler doesn't resolve this in an object until code generation, it would be useful if you can specify these as invariant somehow, possibly the ideas exchange as it is intended behaviour, but it does limit what the objects can do.

 

Cheers,

James

[shoneill]

Yeah, ran into this today again.  It's not specifically an LVOOP issue but I found something unusual today regarding this combination.  I'm using LV 2012 SP1.

 

Normally if you pass an FPGA reference (FIFO, Register and so on) out of a structure you'll be warned by the compiler that this is not allowed.  There's an extra error for that. (Dynamic references not supported).

 

If, however, you pass an object which CONTAINS a reference out of the structure, LV will not tell you about that but rather will complain that the next piece of code which tries to do something with the reference does not have a proper named reference.  LV marks the references within the object as possibly variable when exiting the structure but doesn't raise an error on that.  My error message was for a FIFO reference today even though I was using registers only.  IT had me stumped for quite a while actually.  Having the error being associated with the wrong part of the code makes tracking down the problem harder but I'm assuming it's the same with shift registers.

[Aristos Queue]

shoneill -- I think that the handling of the "reference goes into something before leaving the loop" is the same for the class as for clusters and arrays. Can you check? I seem to recall that this was desirable as there was some use case for using the FIFO as an ID and not as a FIFO, or something like that. It isn't my area of expertise, just something I remember overhearing a while back.

[shoneill]

I know arrays don't work, you can't even CREATE an array of Register references.

 

Clusters I don't know.  Never tried.  But then again, aren't Objects just clusters with attitude?

[Aristos Queue]

Clusters I don't know.  Never tried.  But then again, aren't Objects just clusters with attitude?

Generally, yes, which is why I think they have the same behavior in this regard.

[shoneill]

For me it would be nice if the compiler threw a message when a cluster (or object) leaving a structure as hinted at above would produce an error that dynamic references are not supported, just as it happens when a naked FIFO reference leaves a structure.  This would have saved my a couple of hours last time since the error was suggesting that the problem was occurring somewhere much later in the chain than was required to fix the problem.