FXP encoding error

[Xonmyth]

Hello!

I came across something really strange today, two FXP constants, both are configured/encoded the same way but they show different maximum value. Am I missing something and if not then why is it so.

LabVIEW 2019.0.1f3 (32bit). FPGA Module.

I would appreciate if anyone has an explanation for this.

Thanking you,
X

[DavidBoyd · Accepted solution]

X,

That's definitely a strange one.  Your second FXP constant (ADj) seems to be corrupted in some way.  Were I you, I would simply delete it from the block diagram and create a replacement from the palette.  If you really want an explanation, you may want to capture the existing constant first on an empty BD (check to see if the derangement survives!) and send the VI to NI for analysis, but I wouldn't expect any earth-shaking news.

I certainly couldn't reproduce that set of parameters through the FXP configuration dialog!

Best regards,

Dave

[Xonmyth]

Hi Dave,

Thank you for your input. I did follow your suggestion and created a new one which works normally. The ADj constant also gets fixed if it try to play with its bit values.

Also, placing the FXP constant in question on a blank BD did survive the derangement for me. I do not know if it will do the same for anyone else. I have attached the VI, if you are curious.

It is just that I lost a lot of time due to this little guy. hehe. I wish there is way to prevent/ check this. It did not even show any coercion dot. 

X

[DavidBoyd]

X,

I did a little more digging into this FXP oddity (thanks for providing the BD constant, it was a great springboard for this).  I found some property nodes I'd never noticed before (you need scripting support enabled) which could explain how this constant came to be.  Apparently, there are both "actual" and "desired" versions of FXP representation for constants (and like properties for their controls/indicators).  This may hold the clue.  The standard property page doesn't expose these, though, so if you didn't create that constant, someone else seemingly must have used those nodes.

It would seem obvious that the "desired" range can't exceed the boundaries of "actual".  For signed FXPs, I would've always assumed that range was essentially symmetrical (within one LSB) around zero, but "desired" changes this.

I don't yet understand the use case for "desired" vs "actual".  Perhaps someone more knowledgeable may chime in here?

Best regards,

Dave

 

[Intaris]

---

@DavidBoyd wrote:

X,

That's definitely a strange one.  Your second FXP constant (ADj) seems to be corrupted in some way.  Were I you, I would simply delete it from the block diagram and create a replacement from the palette.  If you really want an explanation, you may want to capture the existing constant first on an empty BD (check to see if the derangement survives!) and send the VI to NI for analysis, but I wouldn't expect any earth-shaking news.

I certainly couldn't reproduce that set of parameters through the FXP configuration dialog!

Edit: Any source of data which is a FP control or a VI input will count as using the full range of the datatype. Anything on the same BD will be handled differently. Since the properties are part of the "datatype", it will propagate out of VIs though AFAIK. It's actually a really nice and clever implementation which I value. It saves people a lot of resources on FPGA without even knowing it's there. But for people like me who does a LOT of their own optimisind, it confused the heck out of me in the beginning. Until I understood what was actually going on.

Best regards,

Dave

---

It's not corrupted, it's a very "hidden" almost "secret" feature of LabVIEW.

If you perform a +1 on a standard FXP +8,8, it will expand the datatype to FXP +9,9. But if you do another +1, it doesn't need to expand further because the "numerical" maximum of the datatype is different from the theoretical maximum. LabVIEW keeps track of this and skips expanding datatypes until it's actually neccessary.

I will admit it's confusing at first, but it really has to do with the compiler being kind of smart but not telling anyone about it.

If you perform another +1 on the datatype, you'll see it's "maximum" increases by one more, but the datatype will NOT expand. Add 256 to it and it will.

[raphschru]

I think it allows to simplify the scripting, so you can specify what is the minimal desired range/precision, and it automatically finds the closest actual representation that can hold your desired one without losing precision.

Now how and why were Xonmyth's constants like that, I couldn't tell. Were they created manually? By scripting? If manually, from an existing control/constant, from a property node item, from an IO node, ... ?

Regards,

Raphaël.

[DavidBoyd]

Thanks, @Intaris, please note that I effectively retracted my "corrupted" guess with my second reply, after I had a closer look.

I appreciate your "increment" example, though I'll have to go away for awhile and try this out.  Again, my blind spot was the concept of a "desired" range for a fixed-point entity.

Dave

[Xonmyth]

Hi @David @Intaris @raphschru

Thank you all for your inputs. I would like to clarify that no scripting was used. Constant was created manually. The code was made for FPGA target. I started from scratch and it did not involve any other person.

How two constants come into play:

I used the known FXP as reference for any and all conversions needed. I think the issue originated in between the High performance multiplier and fxp conversion in step 1.

When running this code on FPGA, I was seeing calculated value being higher than what the FXP is defined for. And constant from Step 2 were showing values lower than what those FXP are  defined as. I have seen a result like this but that happened once, long time ago, because I had a coercion dot.

Maybe using strict typedef may help here.

X

 

[Xonmyth]

Hi David,

Thank you digging into such details. That was very kind of you.

After reading your findings, I think maybe there was something that LabVIEW internally determined under the scope of "Desired" VS "Actual". I do have a handful conversions taking place on the BD. Maybe it visually converted to the "desired" value but internally the "actual" remained something else that it determined.

I will read more about it.

X

[Intaris]

---

@DavidBoyd wrote:

Thanks, @Intaris, please note that I effectively retracted my "corrupted" guess with my second reply, after I had a closer look.

I appreciate your "increment" example, though I'll have to go away for awhile and try this out.  Again, my blind spot was the concept of a "desired" range for a fixed-point entity.

Dave

---

I was exactly the same until I realised there's a method to the madness. Now I just think it's a cool feature, but one which NI could definitely explain a little so that we at least know it's intentional.