Usage of the DSP48 Node

[westgate]

Hello,

i have some questions about the DSP48 Node in Labview FPGA.

In http://forums.ni.com/t5/LabVIEW/Questions-about-the-High-Throughput-Math-Functions/m-p/1485014#M5609... i asked some questions about the HighTroughput Math Functions. I think i unterstand them now and ich think i know how the HT Multiply is using the DSP48.

As i read the DSP48 Labview Help i came to the Xilinx Document http://www.xilinx.com/support/documentation/user_guides/ug193.pdf which brought me to some Questions.

1. On Page 66 at "Two Input 48Bit Addition" there is a description that i can use the DSP48 as Adder. The Inputs A (30Bit) and B (18Bit) are put together and are then the Input A:B (48Bit).

Is there a Build in Function how i can split a Number in A and B? Or is there a way to simply change the Input of the DSP48?

In the Moment is use this Function. Is this Function ok? Do i get latency by the shift operations?

Is there a easier way?

2. On Page 49 at "25 x18 Multiply Plus 48-Bit Add/Sub". There is a description how i can do a 25x18 Multiply and add 48Bit afterwards. I think this is very helpfull. Is there a possibility that the HT Multiply is configurable in the same way? I mean that it would have a input C for Addition Subtraction?

3. On Page 77 at "96-Bit Add/Substract" it is descriped how to work with 96Bit Numbers. As the FXP Datatype is maximum 64Bit how could i work with 96Bit Numbers in Labview FPGA?

Thats everythin for now.

westgate

[StephenD]

Hi

(1) Currently there is not a built in function to split the FXP value in this specific way.  There are other programmatic ways to split the value in addition to your method. Here are two alternate ways that come to mind.

(2) The HT Multiply does not support the adder.

(3) Unfortunately, there is not an easy way to work with bit widths greater than 64 in LabVIEW FPGA. I've never had a need to work with anything greater 64 bits.  The only way I can think that it is possible is by using multiple FXP types in parallel and manually controlling where each bit goes through every operation.  While this would be difficult and tedious, it is still possible. Even if LabVIEW supported FXP bit widths greater than 64 bits, it would still be necessary to split the data type prior to doing other operations using the DSP48E. In addition, if 64 bits is only needed internally for part of the design, then it could be written in VHDL and imported into LabVIEW FPGA with the IP Integration node.

Hope this helps,

Stephen

[westgate]

Hi

1. Using the Number to Array and then the Split Array Function ist maybe the easiest way. When i look to the

"Estimated Ressource Utilization Guides" it seems to use nearly no logic Ressources. Thank you for this solution i havent tought of it.

Does the fact that it uses nearly no resources mean that it is only a wiring operation? This would mean it has only the delay of the signal traveling trough the wires?

2. Ok.

3. As i unterstand little of VHDL is it possible to use Datatypes with more than 64bit in VHDL? I know it would consume many resources but my algorithm needs more than 64bit.

westgate

[StephenD]

(1) Yes, As far as I know, this method should simply be a remapping of the bits and result in no extra logic requirements.  I think this is also true of the second method since the FXP conversions are configured to truncate and wrap, but I have not compiled it in hardware.

(3) Yes, VHDL allows for arbitrary bit widths using std_logic_vectors. If you could post more information on your application, I might be able to suggest some alternatives to using VHDL.

Stephen

[westgate]

We are trying to implement an Algorithm where we can find the length of a and b of an Elipse.

We have the Koordinates x and y of a set of points and we try to use the algorithm of this Paper.

The Problem is the Algorithm computes x and y to the power of 8. This means we get very very big numbers.

If we say x and y can be 1000 we have 10Bit for them. In the worst case we then get 80Bit for one Pixel (10Bit x 8). As we have to calculate the sum and if we asume that we also can have 1000 Ellipse Points we need 90Bit.

Maybe somebody has a suggestion of an alternative algorithm. 

[StephenD]

I'm not an expert in fitting data sets to elipses, but after doing a quick google search I found several papers each with many references.  It seems very possible that there may be a better algorithm after doing a literature search.

More importantly, I don't think it is necessary to keep around all of the bits of the algorithm after every computational stage.  Not even double precision floating point could keep 90bits of percision.
 My guess is that if you have 10bits of percision at the input, you will probably not need more than 20bits of precision at the output and that you probably really only need about 16bits at the output. If this is the case, then you should not need more than 64 bits at any stage within the computation.

Typically when I create a new algorithm that needs to be implemented in Fixed Point, I first create a host based implementation in fixed point. By knowning the precision needed at the final output, I can figure out the bit precision each previous stage's outputs need to be.  Starting with this estimate then I can then vary the bit widths at each stage using the host model to reach the desired performance.