# NI Labs

cancel
Showing results for
Did you mean:

## Re: Welcome to NI Fixed-Point Math Library

Hi, Walker, Jim,

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).

-Ao

Message 11 of 23
(9,629 Views)

## Re: Welcome to NI Fixed-Point Math Library

Hello Ao,

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.

Once again, thanks for your efforts.

Jim
Message 12 of 23
(9,619 Views)

## 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.

Jim
Message 13 of 23
(9,630 Views)

## Re: Welcome to NI Fixed-Point Math Library

Hi, Mr. Jim,

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. :-)

Best regards,
Richtian
Message 14 of 23
(9,600 Views)
Highlighted

## Re: Welcome to NI Fixed-Point Math Library

Hi Richtian,

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.

Jim
Message 15 of 23
(9,590 Views)

## Re: Welcome to NI Fixed-Point Math Library

This new Math Library is very powerful IP for LV FPGA users. If you would like to request and discuss other IP needs, add your feedback/discussion to this thread about IPNet:

Rick Kuhlman | LabVIEW FPGA Product Manager | National Instruments | ni.com/fpga

Message Edited by Rick K on 11-09-2007 09:50 AM
Message 16 of 23
(9,510 Views)

## Re : Welcome to NI Fixed-Point Math Library

hi,

nice library! but what is the difference between the "fixed point add" function and the native add function from Labview ? the native add function can also handle fixed-point.

best regards

boris

Message 17 of 23
(8,844 Views)

## Re : Welcome to NI Fixed-Point Math Library

Hi trolll,

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.

Best regards,
Ellen

Message 18 of 23
(8,834 Views)

## 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 input
The 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 ln2
where 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?

David
Message 19 of 23
(8,524 Views)

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

Hi dwisti,

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.

Does this make sense to you?
Message 20 of 23
(8,513 Views)