NI Labs

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Hope this helpful.Smiley Happy

-Ao

Message 11 of 23
(11,613 Views)
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
0 Kudos
Message 12 of 23
(11,603 Views)


@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
0 Kudos
Message 13 of 23
(11,614 Views)
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
0 Kudos
Message 14 of 23
(11,584 Views)
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.

Thanks for your help,

Jim
0 Kudos
Message 15 of 23
(11,574 Views)
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:

http://forums.ni.com/ni/board/message?board.id=features&thread.id=300


Rick Kuhlman | LabVIEW FPGA Product Manager | National Instruments | ni.com/fpga
Check out the new FPGA IPNet for browsing, downloading, and learning about LabVIEW FPGA IP Cores ni.com/ipnet



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

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

0 Kudos
Message 17 of 23
(10,828 Views)
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


帖子被Ellens在02-25-2008 08:17 PM时编辑过了
0 Kudos
Message 18 of 23
(10,818 Views)
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
0 Kudos
Message 19 of 23
(10,508 Views)
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
(10,497 Views)