Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

- Discussion Forums
- :
- Special Interest Boards
- :
- Additional Interest Boards
- :
- NI Labs
- :
- Re: Welcome to NI Fixed-Point Math Library

Topic Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

10-12-2007 01:02 AM

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.

-Ao

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

10-12-2007 07:53 AM

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

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

10-12-2007 08:02 AM

Hi MCCurtis,

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.

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

10-14-2007 08:59 AM

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

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

10-15-2007 09:42 AM

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

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

11-09-2007 09:49 AM - edited 11-09-2007 09:50 AM

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

http://forums.ni.com/ni/board/message?board.id=fea

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

02-25-2008 07:51 AM

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

02-25-2008 08:14 PM - edited 02-25-2008 08:17 PM

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时编辑过了

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

04-23-2008 12:00 PM

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

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

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

David

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report to a Moderator

04-23-2008 09:17 PM

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?