From: dgreig on
Challenge : 18*18 data with one data vector unsigned and the other
signed. FPGA DSP block actually
has separate signals to set the sign of each
operand.
If the operands are the full data width of the
DPS block inputs it is not possible to
"sign extend" the unsingned operand.

Anyone been able to achieve this task?

Best Regards

David Greig
From: Kolja Sulimma on
On 26 Apr., 17:20, dgreig <dgr...(a)ieee.org> wrote:
> Challenge : 18*18 data with one data  vector unsigned and the other
> signed. FPGA DSP block actually
>                        has separate signals to set the sign of each
> operand.
>                        If the operands are the full data width of the
> DPS block inputs it is not possible to
>                        "sign extend" the unsingned operand.
>
> Anyone been able to achieve this task?


Signed Mutlipliers usually are unsigned mutlipliers of one bit less
with extra logic to get the sign right.
Therefore you should think of Xilinx DSP block as a 17x17 multiplier.

Use an extra conditional adder after the multiplier to get 18x18 in
your case.

Kolja
From: dgreig on
On Apr 26, 6:10 pm, Kolja Sulimma <ksuli...(a)googlemail.com> wrote:
> On 26 Apr., 17:20, dgreig <dgr...(a)ieee.org> wrote:
>
> > Challenge : 18*18 data with one data  vector unsigned and the other
> > signed. FPGA DSP block actually
> >                        has separate signals to set the sign of each
> > operand.
> >                        If the operands are the full data width of the
> > DPS block inputs it is not possible to
> >                        "sign extend" the unsingned operand.
>
> > Anyone been able to achieve this task?
>
> Signed Mutlipliers usually are unsigned mutlipliers of one bit less
> with extra logic to get the sign right.
> Therefore you should think of Xilinx DSP block as a 17x17 multiplier.
>
> Use an extra conditional adder after the multiplier to get 18x18 in
> your case.
>
> Kolja

Okay, for Altera there are actually "signa" and "signb" controls for
inputs a and b respectively, so it is physically possible to have
signal a_i : unsigned(17 downto 0);
signal b_i : signed(17 downto 0);
signal axb_o : signed(35 downto 0);

Suppose the application is DSP on physical data that happens to be
unsigned by nature with the other operand signed - if the data
consists of 18 "good" bits and the application requires all 18 then it
is undesirable not to utilise all of the resources.
Perhaps suppose it is image sensor data and feature detection DSP.
Data is naturally unsigned and the other operand mostly signed. In
this case say 9*9 and 2D DSP. Losing a bit off the image data is
certainly undesirable and the alternative cosly or limits function if
18*18 multipliers have to be inferred as a kludge.

Best Regards

DG
From: glen herrmannsfeldt on
dgreig <dgreig(a)ieee.org> wrote:
> Challenge : 18*18 data with one data vector unsigned and the other
> signed. FPGA DSP block actually has separate signals to set the
> sign of each operand.

> If the operands are the full data width of the DPS block inputs
> it is not possible to "sign extend" the unsingned operand.

> Anyone been able to achieve this task?

For twos complement multiply, you subtract instead of add if the
sign bit is one. So all the signed/unsigned control input does
is to turn an adder into a subtractor. Signed or unsigned, an
N by N bit product fits into 2N bits.

-- glen
From: Pete Fraser on
"dgreig" <dgreig(a)ieee.org> wrote in message
news:8c1c9a60-fef0-4aa2-aa00-54761db33af0(a)s41g2000vba.googlegroups.com...

> Perhaps suppose it is image sensor data and feature detection DSP.
> Data is naturally unsigned and the other operand mostly signed. In
> this case say 9*9 and 2D DSP. Losing a bit off the image data is
> certainly undesirable and the alternative cosly or limits function if
> 18*18 multipliers have to be inferred as a kludge.

One trick I've used is to convert the unsigned data to signed
at the filter input, then back to unsigned on the output.
Most of the video filters I built in the late 70s worked that way.
Once you've wrapped your brain round mid-grey being 0, it's
easy to deal with.


 |  Next  |  Last
Pages: 1 2 3
Prev: data2mem
Next: Booting Linux from my own bootloader