Multiply add Xilinx Core IP

[Intaris]

I'm traing to get the Xilinx CoreIP version of a multiply add function up and running (Virtex 5 target LV 2012 SP1).

When I configure it as I think is required the result is way off.  I can get the multiply part to work but I can't get the addition part to work correctly, I very obviously have some alignment issues.

The signals I want to work with (a*b)+c are

a = +- 16,-7 FXP

b = + 12,0 FXP

c = +- 16,1

How am I supposed to set up the inputs so that these numbers can be calculated?  I can get a*b working so that the output after bitshifting -7 is correct but then the value when adding the c parameter is way off (presumably 7 bits off but I don't know how to rectify that).

Shane.

[dan_u · Accepted solution]

The Xilinx core does not know about the FXP representation. It just knows bit patterns. So you have to take care about the bit alignment.

<+-,16,-7> * <+,12,0> => <+-,28,-7>

Now you have to add a number that matches the bit representation. If the number you want to add is <+-,16,1> you have to shift it 12 bits to have the correct word length (16 to 28), then shift it another 8 bits to correct the integer bits (-7 to 1). This is a total shift of 20. So you have to convert c into <+-,36,1> and pass that number.

[Intaris]

There is a LabVIEW wrapper around the IPCore though and it's a bit unclear what that does with the associated information regarding input data format.  It certainly doesn't seem to do any conversion of its own.....

The documentation is sorely lacking and using the LV wrapper for the IPCore gives the impression that the precisions / widths which are entered may be automatically adjusted.  This clearly seems not to be the case.

I just tried the suggestion and founf that I need a shift of 19 for the number to be added and 1 for the final result.....  Probably because of mixed signed and unsigned FXP there's a difference of 1 versus your answer.  Still, Without your input I would have remained in the dark.

Thanks.

[dan_u]

I agree it's very confusing. Maybe my explanation is wrong, but this is what I ended up with when I tried to use this node a few months ago.

[Intaris]

---

@dan_u wrote:

I agree it's very confusing. Maybe my explanation is wrong, but this is what I ended up with when I tried to use this node a few months ago.

---

No, I think the explanation fits very well with the observed behaviour.  I do agree on the confusing aspect of the LV wrapper allowing detailed settings of FXP input values yet it seems to simply treat all input values as bit arrays without performing and shifts or conversions.  To define the inputs and outputs purely to get rid of coercion dots seems counterintuitive.  I got stuck assuming LV was doing something based on my settings for the input FXP formats.  Seems like that assumption was incorrect.