Unsigned value to be used in multiplier in FPGA

[pigtwo]

Hello all,

I'm working on a project where I want to take in data with an ADC and do some basic DSP on that data using a Spartan 6.  The part I'm a little confused on is that the ADC doesn't output a signed value.  Obviously it's just a scaled value of reference voltage.  But to use it in a multiplier I need to convert it to a signed value.  What I'm think I should be able to do is subtract my unsigned value by about roughly half of the max value.  This should essentially convert the unsigned value to a 2's complement value.  For example if I have a 4 bit value, I would subtract by 8.  Thus converting 0 to -8 and 15 to 7.  Which would correspond to the values in 2's compliment. 

Does this make sense?  It's a little weird to me but I don't immediately see a problem with it.  I should note here that I don't really care about the absolute value of this data.  The intention is to take a very basic amplitude measurement of this data.  So it's only the relative value that matters. 

I have to imagine this is common thing so maybe there is a more appropriate way to handle this problem. 

Thank you!

[nctnico]

Just feed it into the multiplier as unsigned. It is the same as a signed number but always positive but you have to be careful to not set the highest bit to 'one' because in a signed number that is the sign bit.

[pigtwo]

I thought that as well and for this case it seems like it would work as long as the multiplier is one bit larger than the unsigned data.  Maybe I'm not thinking about it correctly but say I have a 12 bit unsigned value, I would have to use a 13bit multiplier.  And I would have to make the 13th bit zero to make sure it never goes negative.  Is this correct? 

[nctnico]

Yes, that is correct.

[hamster_nz]

I should note here that I don't really care about the absolute value of this data.

If this is the case, you can just flip the high bit (XOR it with a '1') and treat it as a signed value, (or subtract 2^(n-1) if you like that better)

But you have to be quite careful when playing with data that can use the full range of values, for example if you filter the samples and your filter has a gain greater than unity at any frequency it is really easy to get odd errors and 'pops' that are hard to track down.

Because of this you are most likely better off converting to signed values (as above), and then also adding sign-extending by one bit. That way you will have equally sized 'guard bands' above and below the range used by your samples. This will be a great help in avoiding overflows and underflows.

As the multiplier bits on Spartan6 are 18x18 bits there is minimal cost to doing this.

[pigtwo]

@nctnico Thank you for the confirmation.

@hamster_nz Ah ok, that makes sense.  So DSP is not my strong suit at all.  I've read a book about it once but that's it.  In regards to the filter having a greater than one gain causing overflows.   I'm using Matlab to design my filter and it gives small fractional coefficients.  To quantize these I gain them up by some power of two.  Then at the end I divide the value of the accumulator by that same power of two.  So even though I gain up the coefficients(thus increasing the gain of my filter) there wont be overflows because I gain it back down at the end thus avoiding overflows on the output.  Is that correct assuming my original filter doesn't have a gain greater than unity?  Or is the overflow you're mentioning happening some where else?

Thank you!

[hamster_nz]

@nctnico Thank you for the confirmation.

@hamster_nz Ah ok, that makes sense.  So DSP is not my strong suit at all.  I've read a book about it once but that's it.  In regards to the filter having a greater than one gain causing overflows.   I'm using Matlab to design my filter and it gives small fractional coefficients.  To quantize these I gain them up by some power of two.  Then at the end I divide the value of the accumulator by that same power of two.  So even though I gain up the coefficients(thus increasing the gain of my filter) there wont be overflows because I gain it back down at the end thus avoiding overflows on the output.  Is that correct assuming my original filter doesn't have a gain greater than unity?  Or is the overflow you're mentioning happening some where else?

Thank you!

It can become a problem like this:

Imagine you have a FIR filter with a kernel of five coefficients : ( -0.2, 0.1, 0.7, 0.1, -0.2 )

The DC gain is -0.2 + 0.1 + 0.7 + 0.1 0 - 0.2 =  0.9, so less than unity, so it looks like it should be safe from underflows and overflows.

You might choose to implement it with a signed 16-bit value, multiplied by five signed 16-bit fixed point coefficients, totaling into a 32-bit accumulator. For a DC input the output will be no greater than about +/- 30,000 counts.

However, for some inputs (e.g. a sine wave at 1/4th the sample frequency) it will have gain greater than unity - in fact it will have at f/4 it will have a gain of 1.3x - any input at this frequency that is more than +/- 25206 counts will cause an overflow.

The same thing can happen if your filter causes different frequencies to be delayed by different amounts. What looks to be safe at first glance isn't, for some pathological inputs.

I most cases, having some extra dynamic range up your sleeve is usually helpful. 

[pigtwo]

Ah, ok.  Thanks for the clarification.  I was curious about the theoretical problem here but as you mentioned the Spartan 6 has 18 bit multipliers so this shouldn't be an issue for me as my input is 12 bits.