Welcome to NI Fixed-Point Math Library

[aoh]

This thread is intended to foster discussion regarding the fixed-point math library. Please post any comments or questions about the library here, and I will be happy to respond.

The fixed-point math library contains a set of FPGA IPs for elementary mathematical functions that work with the LabVIEW FPGA Module. These IPs are grouped into two categories: basic elements and fixed-point math VIs. The basic elements perform integer computation, while the fixed-point VIs perform fixed-point computation. National Instruments implemented all the VIs as configurable nodes. The VIs generate optimized FPGA code according to your configuration. Meanwhile, all VIs support bit-true and cycle-accurate simulation. So you can develop and simulate your applications on the desktop first and then compile them and deploy them to FPGA targets.

System Requirement:  LabVIEW 8.5, LabVIEW FPGA 8.5

Thanks,

Ao Huang

Message Edited by Support on 11-07-2007 08:11 AM

[Mr._Jim]

Ao,

I started using the library today, and I'm very grateful for your efforts.  Particularly, having the ability to pipeline the calculations has helped me avoid timing constraints that I was previously running into using conventional LabVIEW arithmetic functions.  The extra parameters and options that this library offers seem practical and useful at first glance.  I may have some questions for you as I continue development.

Many thanks,

Jim

[aoh]

Hi, Jim,

Thanks for trying this product. Feel free to post your question here if any. And I'm looking forward to your feedback about the product so that we can make it stronger.

-Ao

[altenbach]

Is there a strict requirement of having LV FPGA (which I don't have) or could I install it in plain LabVIEW for exclusive use in simulation mode?

[aoh]

Hello, altenbach,

Unfortunately, the installer of the library checks if LV FPGA 8.5 is installed. It does not continue if not.

thanks,

-Ao Huang

[Mr._Jim]

Hi Ao,

As I've been compiling prototypes for what I'm trying to do, I'm really very happy with how much more I can now put on the FPGA.  I do have one suggestion, though I don't know if it's a realistic one:

On functions that take multiple cycles, it would be nice to be able to have the option to only update the numeric output when the "output valid" boolean becomes true.  Normally it's not a problem, since the "input valid" boolean on subsequent functions takes care of it, but for the final output to a terminal this has greater importance.  It's been a minor inconvenience for me to come up with ways around this, such as storing the previous valid output on a shift register or putting the terminal in the case statement.  The developing intermediate values had been causing problems with some calculations later on.

Other than that, I haven't had any problems at all.

Thanks,

Jim

[WalkerTexasRanger]

Hi Ao,

I had a chance to play with the tools and I'm very pleased so far.  Is there any general tutorial or suggestions on using and configuring Fixed Point Data Types (i.e. tradeoffs between Word/Integer length, Adapt to Source, notes of wisdom)? 

Thanks for the help and keep up the good work.

Walker

[Mr._Jim]

I agree with Walker. (great name. )

Documentation is pretty sparse for fixed point, although the manual for the Fixed Point Library is really quite good in explaining the library itself.  One source that I found that offered at least "fixed point 101" was this tutorial:  http://zone.ni.com/devzone/cda/tut/p/id/3115 .  Although it's not specifically related to this implemenation of fixed point, the first couple of sections are useful.  I checked the LabVIEW help, and while it's a good start, it's kind of confusing.  In the end, I learned most of what to do by intuition and trial and error.

The hardest part is anticipating the range of numbers you're going to be using and which level of precision you'll need.  That's where the word length and the integer word length come in.  What really confuses me, though, is what a negative "integer word length" means.  I see the result of increased precision, but I think I've missed something there.  I'm going to go back and read some more.

I have two requests for the developers of fixed point (not necessarily this library):
1.   We desperately need a good tutorial exclusively for this implementation of fixed point.  If there is one, I'd love to be made aware of it.
2.   It would be really helpful to have a "Data Type" choice on the context menu when right clicking fixed point constants and front panel objects.  I'm finding that I'm constantly tweaking this, and it's a pain to go through properties every time.

Jim

[MCCurtis]

2.   It would be really helpful to have a "Data Type" choice on the context menu when right clicking fixed point constants and front panel objects.  I'm finding that I'm constantly tweaking this, and it's a pain to go through properties every time.

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.

For front panel controls (or if you don't want your types changing automatically for you) there's currently no way to change the fixed-point configuration other than the property page, which I agree can be a pain to use.

[aoh]

Mr. Jim 写:
Hi Ao,

As I've been compiling prototypes for what I'm trying to do, I'm really very happy with how much more I can now put on the FPGA.  I do have one suggestion, though I don't know if it's a realistic one:

On functions that take multiple cycles, it would be nice to be able to have the option to only update the numeric output when the "output valid" boolean becomes true.  Normally it's not a problem, since the "input valid" boolean on subsequent functions takes care of it, but for the final output to a terminal this has greater importance.  It's been a minor inconvenience for me to come up with ways around this, such as storing the previous valid output on a shift register or putting the terminal in the case statement.  The developing intermediate values had been causing problems with some calculations later on.

Other than that, I haven't had any problems at all.

Thanks,

Jim

The behavior is by designed such that one additional register at the output stage is saved since it is not necessary for most scenarios.  And it's also pretty easy for users to latch the result. Your walkaround does work. And see the attachment for another one.  Thanks for your feedback.

-Ao