Why does Modelsim insist so many bits for a multiplication?

[fl]

Hi,

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.

Could you explain what rule behind Modelsim to give such a warning?

Thanks,

----------------
architecture behave of example_signed_unsigned is
signal rs_SUM_RESULT : signed(4 downto 0) := (others => '0');
signal ru_SUM_RESULT : unsigned(4 downto 0) := (others => '0');
signal rs_SUB_RESULT : signed(4 downto 0) := (others => '0');
signal ru_SUB_RESULT : unsigned(4 downto 0) := (others => '0');
signal rs_mpy_RESULT : signed(9 downto 0) := (others => '0');
signal ru_mpy_RESULT : unsigned(9 downto 0) := (others => '0');

begin

-- Purpose: Add two numbers. Does both the signed and unsigned
-- addition for demonstration. This process is synthesizable.
p_SUM : process (i_clk, i_rst_l)
begin
if i_rst_l = '0' then -- asynchronous reset (active low)
rs_SUM_RESULT <= (others => '0');
ru_SUM_RESULT <= (others => '0');
elsif rising_edge(i_clk) then

ru_SUM_RESULT <= unsigned(i_a) + unsigned(i_b);
rs_SUM_RESULT <= signed(i_a) + signed(i_b);

end if;

end process p_SUM;

p_mpy0 : process (i_clk, i_rst_l)
begin
if i_rst_l = '0' then -- asynchronous reset (active low)
rs_mpy_RESULT <= (others => '0');
ru_mpy_RESULT <= (others => '0');
elsif rising_edge(i_clk) then
ru_mpy_RESULT <= unsigned(i_a) * unsigned(i_b);
rs_mpy_RESULT <= signed(i_a) * signed(i_b);
end if;
end process p_mpy0;

 

[fl]

On Tuesday, October 20, 2015 at 10:38:12 AM UTC-4, Tim McBrayer wrote:

On 10/20/2015 10:12 AM, fl wrote:
Hi,

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.


Your 9-bit product assumption is the problem; 9 bits are not enough to store 5 bits * 5
bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers. 2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511
Max unsigned 10-bit value: 2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.
--
Tim McBrayer
MathWorks

Thanks. You said is correct for unsigned number multiplication. I just
verify that it is correct for signed number multiplication. But the
puzzling thing is that there are such examples on the web: Q15 multiplies
Q15, the result is Q31. There is a sign extension bit. I always clip the
MSB of the multiplication result, then often round to 16-bit.

Thanks for your article. Now I am puzzling on fixed point multiplication when thinking about the multiplication product. First of all, Q.x format could be signed, or unsigned number, is it right?

After reading other online docs, I put it here to rephrase my question:
Then, for signed numbers Q.a and Q.b, the product is Q.(a+b). Q.a has to use (a+1) bit to represent it. Q.b has to use (b+1) bit to represent it too. So, the result has one redundant sign extension bit. When I write VHDL code, Modelsim insists on using 10-bit result for two signed integers Q5.0 multiplies Q5.0. Why does it not consider sign extension bit?

 

[Rob Gaddi]

On Tue, 20 Oct 2015 08:49:37 -0700, fl wrote:

On Tuesday, October 20, 2015 at 10:38:12 AM UTC-4, Tim McBrayer wrote:
On 10/20/2015 10:12 AM, fl wrote:
Hi,

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that
it insists the result be 10-bit. Otherwise, it issues a warning.


Your 9-bit product assumption is the problem; 9 bits are not enough to
store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers. 2^5
has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511 Max unsigned 10-bit value: 2^10
- 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.
--
Tim McBrayer MathWorks

Thanks. You said is correct for unsigned number multiplication. I just
verify that it is correct for signed number multiplication. But the
puzzling thing is that there are such examples on the web: Q15
multiplies Q15, the result is Q31. There is a sign extension bit. I
always clip the MSB of the multiplication result, then often round to
16-bit.

Thanks for your article. Now I am puzzling on fixed point multiplication
when thinking about the multiplication product. First of all, Q.x format
could be signed, or unsigned number, is it right?

After reading other online docs, I put it here to rephrase my question:
Then, for signed numbers Q.a and Q.b, the product is Q.(a+b). Q.a has to
use (a+1) bit to represent it. Q.b has to use (b+1) bit to represent it
too. So, the result has one redundant sign extension bit. When I write
VHDL code, Modelsim insists on using 10-bit result for two signed
integers Q5.0 multiplies Q5.0. Why does it not consider sign extension
bit?

Because the "sign extension bit" is not redundant information in exactly
one case. In your format -1 is represented 1.0000. 1.0000 * 1.0000 = -1
* -1 = 1 = 01.00000000.

Also, this is why I loathe Q notation; no one ever quite follows what it
means. Instead I use Ux.y and Sx.y. A signed number with a total of 5
bits and a range of [-1, 1) is S1.4. 1 integer bit (with a value of -1)
and 4 fractional bits of values 1/2, 1/4, 1/8, and 1/16.

When you multiply it's trivially simple to track the binary point; you
add integer bits together and you add fractional bits together. S1.4 *
S1.4 = S2.8, or to be completely explicit:

S1.4 [-1,1) * S1.4 [-1,1) = S2.8 [-1,1].





--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[glen herrmannsfeldt]

Tim McBrayer <Tim.McBrayer@mathworks.com> wrote:

On 10/20/2015 10:12 AM, fl wrote:

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.

Your 9-bit product assumption is the problem; 9 bits are not enough
to store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers.
2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511
Max unsigned 10-bit value: 2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.

But for signed, 15*15 fits in 9 bits, and (-16)*(-16) also fits.

The real question is what VHDL says about it.

The verilog rules for add are funny, and many get it wrong.

-- glen

 

[Mark Curry]

In article <n05ple$nu2$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

Tim McBrayer <Tim.McBrayer@mathworks.com> wrote:
On 10/20/2015 10:12 AM, fl wrote:

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.

Your 9-bit product assumption is the problem; 9 bits are not enough
to store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers.
2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511
Max unsigned 10-bit value: 2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.

But for signed, 15*15 fits in 9 bits, and (-16)*(-16) also fits.

Glen - huh? The (max negative) * (max negative) case does NOT fit
in 9 bits for signed either.

(-16)*(-16) = 256 = 'b01_0000_0000
you need 10 bits - you need the sign bit at the output too.

Or I'm missing your point?

Regards,

Mark

 

[Tim McBrayer]

On 10/20/2015 10:12 AM, fl wrote:

Hi,

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.

Your 9-bit product assumption is the problem; 9 bits are not enough to store 5 bits * 5
bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers. 2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511
Max unsigned 10-bit value: 2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.
--
Tim McBrayer
MathWorks

 

[Rob Gaddi]

On Tue, 20 Oct 2015 16:14:18 -0400, rickman wrote:

On 10/20/2015 12:11 PM, Rob Gaddi wrote:
On Tue, 20 Oct 2015 08:49:37 -0700, fl wrote:

Also, this is why I loathe Q notation; no one ever quite follows what
it means. Instead I use Ux.y and Sx.y. A signed number with a total
of 5 bits and a range of [-1, 1) is S1.4. 1 integer bit (with a value
of -1) and 4 fractional bits of values 1/2, 1/4, 1/8, and 1/16.

When you multiply it's trivially simple to track the binary point; you
add integer bits together and you add fractional bits together. S1.4 *
S1.4 = S2.8, or to be completely explicit:

S1.4 [-1,1) * S1.4 [-1,1) = S2.8 [-1,1].

Now I'm lost. 5 bit signed integers would be -16 to 15. Max range of
the product would be from -16 * -16 yielding -256 which is a 9 bit
signed number, no? My understanding is that you need 1 bit for the sign
and n-1 bits for the significands (or whatever they are called). So the
product will be able to eliminate one of the sign bits and use 2 * (n-1)
+ 1 or 2n - 1 bits total.

Nope. -16 * -16 = +256. 01_0000_0000b if you're in 2's compliment and
thus the MSB has a negative value.

Your notation of the product, S2.8 implies there is a larger range in
the product than [-1,1), no? The product will be S1.8 I think.

There is a larger range in the product, it's [-1, 1]. The inclusion of
+1 as a possibility is a righteous pain in the ass and requires you be
willing to give up an entire bit to its existence if you can't preclude
it.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Rob Gaddi]

On Tue, 20 Oct 2015 16:20:40 -0400, rickman wrote:

On 10/20/2015 12:58 PM, Mark Curry wrote:
In article <n05ple$nu2$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
Tim McBrayer <Tim.McBrayer@mathworks.com> wrote:
On 10/20/2015 10:12 AM, fl wrote:

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no
matter
unsigned or signed number. When I try it with Modelsim, I find
that it insists the result be 10-bit. Otherwise, it issues a
warning.

Your 9-bit product assumption is the problem; 9 bits are not enough
to store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers.
2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511 Max unsigned 10-bit value:
2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.

But for signed, 15*15 fits in 9 bits, and (-16)*(-16) also fits.

Glen - huh? The (max negative) * (max negative) case does NOT fit in 9
bits for signed either.

(-16)*(-16) = 256 = 'b01_0000_0000 you need 10 bits - you need the sign
bit at the output too.

Or I'm missing your point?

Opps, I was thinking 1_0000_0000 would be a negative value, duh. Now I
remember that this is the defining case for multiplication and requires
the full 2n bits... just as Rob said. If your data is for any reason
limited to Âą(2^(n-1)-1) then one less bit is needed for the product.
Such is the case if an unsigned value was negated to produce the signed
value.

I don't get his product notation becoming S2.8 rather than S1.9 though.
If the range of the result is [-1,1) there is still only one bit left
of the binary point, or am I wrong about that too, lol?

Nope. The LSB in S1.4 was 2^-4 = 1/16. The LSB of the product,
therefore is 1/256, 2^-8. Likewise, as you pointed out, the
representation of +1 is 01.0000_0000b, i.e. 2^0. The representation of
-1 therefore is 11.0000_0000b, -(2^1) + 2^0 = -2 + 1 = -1. The total
representable range is [-2,2), but if you get there from the product of
two S1.4 numbers on [-1,1) then you've got a number that is S2.8 [-1,1].
So the number is, by virtue of what it actually represents, not capable
of using the entire range representable by its format.

That S/U notation, and actually carrying along explicit ranging
information, is why I can write fixed-point code that is right the first
time these days. God knows I didn't get any smarter, I just started
using a notation that is so explicit and bloody stupid that it shouts
your mistakes from the rafters.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[rickman]

On 10/20/2015 12:11 PM, Rob Gaddi wrote:

On Tue, 20 Oct 2015 08:49:37 -0700, fl wrote:

On Tuesday, October 20, 2015 at 10:38:12 AM UTC-4, Tim McBrayer wrote:
On 10/20/2015 10:12 AM, fl wrote:
Hi,

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that
it insists the result be 10-bit. Otherwise, it issues a warning.


Your 9-bit product assumption is the problem; 9 bits are not enough to
store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers. 2^5
has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511 Max unsigned 10-bit value: 2^10
- 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.
--
Tim McBrayer MathWorks

Thanks. You said is correct for unsigned number multiplication. I just
verify that it is correct for signed number multiplication. But the
puzzling thing is that there are such examples on the web: Q15
multiplies Q15, the result is Q31. There is a sign extension bit. I
always clip the MSB of the multiplication result, then often round to
16-bit.

Thanks for your article. Now I am puzzling on fixed point multiplication
when thinking about the multiplication product. First of all, Q.x format
could be signed, or unsigned number, is it right?

After reading other online docs, I put it here to rephrase my question:
Then, for signed numbers Q.a and Q.b, the product is Q.(a+b). Q.a has to
use (a+1) bit to represent it. Q.b has to use (b+1) bit to represent it
too. So, the result has one redundant sign extension bit. When I write
VHDL code, Modelsim insists on using 10-bit result for two signed
integers Q5.0 multiplies Q5.0. Why does it not consider sign extension
bit?

Because the "sign extension bit" is not redundant information in exactly
one case. In your format -1 is represented 1.0000. 1.0000 * 1.0000 = -1
* -1 = 1 = 01.00000000.

Also, this is why I loathe Q notation; no one ever quite follows what it
means. Instead I use Ux.y and Sx.y. A signed number with a total of 5
bits and a range of [-1, 1) is S1.4. 1 integer bit (with a value of -1)
and 4 fractional bits of values 1/2, 1/4, 1/8, and 1/16.

When you multiply it's trivially simple to track the binary point; you
add integer bits together and you add fractional bits together. S1.4 *
S1.4 = S2.8, or to be completely explicit:

S1.4 [-1,1) * S1.4 [-1,1) = S2.8 [-1,1].

Now I'm lost. 5 bit signed integers would be -16 to 15. Max range of
the product would be from -16 * -16 yielding -256 which is a 9 bit
signed number, no? My understanding is that you need 1 bit for the sign
and n-1 bits for the significands (or whatever they are called). So the
product will be able to eliminate one of the sign bits and use 2 * (n-1)
+ 1 or 2n - 1 bits total.

Your notation of the product, S2.8 implies there is a larger range in
the product than [-1,1), no? The product will be S1.8 I think.

--

Rick

 

[rickman]

On 10/20/2015 12:21 PM, glen herrmannsfeldt wrote:

Tim McBrayer <Tim.McBrayer@mathworks.com> wrote:
On 10/20/2015 10:12 AM, fl wrote:

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.

Your 9-bit product assumption is the problem; 9 bits are not enough
to store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers.
2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511
Max unsigned 10-bit value: 2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.

But for signed, 15*15 fits in 9 bits, and (-16)*(-16) also fits.

The real question is what VHDL says about it.

The verilog rules for add are funny, and many get it wrong.

That is what I've read and why I'm looking for a book that explains this
clearly before I commit to using Verilog.

--

Rick

 

[rickman]

On 10/20/2015 12:58 PM, Mark Curry wrote:

In article <n05ple$nu2$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
Tim McBrayer <Tim.McBrayer@mathworks.com> wrote:
On 10/20/2015 10:12 AM, fl wrote:

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no matter
unsigned or signed number. When I try it with Modelsim, I find that it
insists the result be 10-bit. Otherwise, it issues a warning.

Your 9-bit product assumption is the problem; 9 bits are not enough
to store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers.
2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511
Max unsigned 10-bit value: 2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.

But for signed, 15*15 fits in 9 bits, and (-16)*(-16) also fits.

Glen - huh? The (max negative) * (max negative) case does NOT fit
in 9 bits for signed either.

(-16)*(-16) = 256 = 'b01_0000_0000
you need 10 bits - you need the sign bit at the output too.

Or I'm missing your point?

Opps, I was thinking 1_0000_0000 would be a negative value, duh. Now I
remember that this is the defining case for multiplication and requires
the full 2n bits... just as Rob said. If your data is for any reason
limited to ą(2^(n-1)-1) then one less bit is needed for the product.
Such is the case if an unsigned value was negated to produce the signed
value.

I don't get his product notation becoming S2.8 rather than S1.9 though.
If the range of the result is [-1,1) there is still only one bit left
of the binary point, or am I wrong about that too, lol?

--

Rick

 

[rickman]

On 10/20/2015 4:46 PM, Rob Gaddi wrote:

On Tue, 20 Oct 2015 16:20:40 -0400, rickman wrote:

On 10/20/2015 12:58 PM, Mark Curry wrote:
In article <n05ple$nu2$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
Tim McBrayer <Tim.McBrayer@mathworks.com> wrote:
On 10/20/2015 10:12 AM, fl wrote:

I know if 5-bit multiplies 5-bit, the result will be 9-bit, no
matter
unsigned or signed number. When I try it with Modelsim, I find
that it insists the result be 10-bit. Otherwise, it issues a
warning.

Your 9-bit product assumption is the problem; 9 bits are not enough
to store 5 bits * 5 bits at full precision. It requires 10 bits.

Take the simplest example, multiplying two unsigned 5-bit numbers.
2^5 has range 0 to 31.

Max value of multiplication: 31 * 31 = 961

Max unsigned 9-bit value: 2^9 - 1 = 511 Max unsigned 10-bit value:
2^10 - 1 = 1023

Thus, 5 bits * 5 bits requires 10 bits for a full precision result.

But for signed, 15*15 fits in 9 bits, and (-16)*(-16) also fits.

Glen - huh? The (max negative) * (max negative) case does NOT fit in 9
bits for signed either.

(-16)*(-16) = 256 = 'b01_0000_0000 you need 10 bits - you need the sign
bit at the output too.

Or I'm missing your point?

Opps, I was thinking 1_0000_0000 would be a negative value, duh. Now I
remember that this is the defining case for multiplication and requires
the full 2n bits... just as Rob said. If your data is for any reason
limited to Âą(2^(n-1)-1) then one less bit is needed for the product.
Such is the case if an unsigned value was negated to produce the signed
value.

I don't get his product notation becoming S2.8 rather than S1.9 though.
If the range of the result is [-1,1) there is still only one bit left
of the binary point, or am I wrong about that too, lol?

Nope. The LSB in S1.4 was 2^-4 = 1/16. The LSB of the product,
therefore is 1/256, 2^-8. Likewise, as you pointed out, the
representation of +1 is 01.0000_0000b, i.e. 2^0. The representation of
-1 therefore is 11.0000_0000b, -(2^1) + 2^0 = -2 + 1 = -1. The total
representable range is [-2,2), but if you get there from the product of
two S1.4 numbers on [-1,1) then you've got a number that is S2.8 [-1,1].
So the number is, by virtue of what it actually represents, not capable
of using the entire range representable by its format.

That S/U notation, and actually carrying along explicit ranging
information, is why I can write fixed-point code that is right the first
time these days. God knows I didn't get any smarter, I just started
using a notation that is so explicit and bloody stupid that it shouts
your mistakes from the rafters.

Ok, thanks. This was a useful example. I guess I haven't actually used
this sort of calculation before.

--

Rick