Welcome to NI Fixed-Point Math Library

Re: Welcome to NI Fixed-Point Math Library

Your request for document is reasonable. Unfortunately, we don't have a comprehensive tutorial on Fixed-Point itself yet. Basically you configure fixed-point data type according to the range and precision of the value you want to represent. The range determines the signed/unsigned and integer word length. The precision determines the fractional word length:

For a signed FXP, the value range is: [-2^(iwl-1), 2^(iwl-1)-2^(-fwl)]

For an unsigned FXP, the value range is [0, 2^iwl-2^(-fwl)]

where iwl is integer word length, and fwl is the word length of the fracational part. iwl+fwl is the word length. So if you are aware of the range and precision of a parameter, you can infer an appropriate FXP format according to the formula above.

The integer word length is actually a logic concept, which denotes a scale factor, thus can be negative. For example, for an 8-bit unsigned FXP number "11001001" (201 in decimal), the real value it represents is 201/2^(8-iwl).

Re: Welcome to NI Fixed-Point Math Library

Thank you for explaining the negative word length - that's very helpful and it now makes sense to me. Regarding the latched output, I agree with you - saving the additional register and leaving it up the user seems like a better idea. I appreciate the additional workaround, too.

Re: Welcome to NI Fixed-Point Math Library

MCCurtis wrote:For fixed-point constants you can turn on "Adapt to entered data" from the popup menu. This will pick the best fixed-point configuration based on the number you type in.For front panel indicators you can turn on "Adapt to source" from the popup menu. The indicator will change adapt to whatever numeric type is wired to it.

Hi MCCurtis,

That's a good idea, and I did try using those. However, at first I was using the "adapt to..." options, but I had mixed results with them. I found that, while debugging the routines, I had to tweak the parameters pretty often to achieve the precision I needed and to get the calculations just right, especially when considering the full range of what might be inputted. I think the "adapt to..." options are a good starting point if you're not really sure what the settings should be, but experience has made me a bit leery of them.

I'm sure everyone that uses fixed point will start to develop their own preferences. Thanks for the suggestion.

Re: Welcome to NI Fixed-Point Math Library

I have some suggestions based on my experience. In general, you can always apply 32 bit word length as the API interface for a small algorithm block. Yes, it's wasting some resources. But it can relieve your effort from guessing the best word length. Of course, in the small block, you can use longer word length. The next important step is to decide the integer word length. Instead of try-and-error in the fixed-point domain directly, you can considering figuring out a good start point in the floating-point algorithm. Imagine that you have a probe for each wire. Once you feed enough typical data inputs to the algorithm, you will know what are the max and min values ever appearing on the wire. All the above are done in the floating domain. But it helps you decide the integer word length of each wire. Does this make sense to you? :-)

BTW, if you need any fixed-point filters, you may want to try Digital Filter Design Toolkit for LabVIEW. :-)

Re: Welcome to NI Fixed-Point Math Library

That's pretty good advice, and those are basically the methods I'm using -- now that I've figured out what I'm doing. I tend to figure out the range within reason, but when I'm not sure or there's something unpredictable, I pick a happy medium where the parameters should cover most cases. So far, that's been working out well.

Re : Welcome to NI Fixed-Point Math Library

The FXP Add provides overflow flag while Add cannot now. The overflow signal can be very useful especially in fixed-point applications. Except for this difference, FXP Add in the library is almost the same as the Add on both timing and resource usage.

Re: Welcome to NI Fixed-Point Math Library

I have a question about the FXP natural logarithm function. In the Fxpmath_User_Guide.pdf pg. 48 of 50, it states:

Preprocessing on the inputThe input value to x must be within the range [1/e, 1). If the input is out of this range, preprocess the input according to the following formula to convert the input into the range [1/e, 1).

ln(M2^E) = ln(M) + E ln2where 0.5 >= M >= 1.0

Why does M (mantissa) have to be greater than or equal to 0.5? Can't this be 1/e?

回复： Re: Welcome to NI Fixed-Point Math Library

It's ok to have M>=1/e. The FXP natural logarithn function can still get a correct result on it.

We suggest using 0.5<=M<1.0 because the preprocessing to get such an M can be much easier on FPGA target. You can shift the original argument's binary point until it is just to the left of the most significant non-zero bit. The fraction M then satisfies 0.5<=M<1.0 which is within the required range [1/e, 1). Shift is a relatively simpler operation on FPGA. So we recommend this way to make the input inside the range.