signed/unsigned multipliers

[Altera_Forum]

I can't seem to find a way to instantiate a multiplier that will dynamically select between signed and unsigned multiplication. This is on a Cyclone II, but applies to other parts as well. 

 Reading the Cyclone II documentation it is clear that signa, signb inputs does what I want, but none of the multipliers created with the Wizzard exports that as an input signal. Trying to infer it with the code below doesn't work (bug in Quartus II?); it complains that no logic depends on input_sign. However looking at the RTL with Tools/Netlist Viewers/RTL Viewer clearly shows it being used, however the technology map viewer shows input_sign as disconnected and signa and signb hardwired to ground.  This looks like a bug to me, but I could be doing something wrong.   module mult(input clock, input input_sign, input input_a, input input_b, output reg output_c); reg a, b; reg sign; always @(posedge clock) begin sign <= input_sign; a <= input_a; b <= input_b; if (sign) output_c <= $signed(a) * $signed(b); else output_c <= $unsigned(a) * $unsigned(b); end endmodule

[Altera_Forum]

I am not sure if your input bus resize is doing what you want. 

I suggest you instantiate two mult(signed,unsigned) then connect inputs to both. switch the output per input_sign.

[Altera_Forum]

Signed/unsigned is a parameter rather than an input port to lpm_mult. So it can't be changed during run time. I didn't try, but I guess, that in case of a hardware multiplier, two multiplier instances and a multiplexer are inferred from your code for this reason. A software (logic cell) multiplier should be able to incorporate the signed/unsigned switch during fit. 

 As said, the input size should 2*9 bit. I guess, assigning the input to a 18 bit value forces the multiply operands to be positive, thus signed multiply is eliminated. Also, cause the full multiply result is 36 bit, you don't get it correctly in the signed case.

[Altera_Forum]

Moreover I am not sure why use signed/unsigned in same design?

[Altera_Forum]

Thanks for your input FvM 

   --- Quote Start ---  Signed/unsigned is a parameter rather than an input port to lpm_mult. So it can't be changed during run time. I didn't try, but I guess, that in case of a hardware multiplier, two multiplier instances and a multiplexer are inferred from your code for this reason. A software (logic cell) multiplier should be able to incorporate the signed/unsigned switch during fit.  As said, the input size should 2*9 bit. I guess, assigning the input to a 18 bit value forces the multiply operands to be positive, thus signed multiply is eliminated. Also, cause the full multiply result is 36 bit, you don't get it correctly in the signed case.  --- Quote End ---    You maybe right the lpm_mult take signess as a parameter, but that's besides the point. The RTL inferred from the above Verilog is correct as can be seen with the RTL technology viewer. Yes, it does infer two multipliers, but if you read http://www.altera.com/literature/hb/cyc2/cyc2_cii51012.pdf page 12-5, it is explicitly stated that "Two signals, signa and signb, control whether a multiplier’s input is a signed or unsigned value. ... The signa and signb signals can be changed dynamically to modify the sign representation of the input operands at run time." Furthermore, if you inspect with the post mapping technology viewer, the signa/signb signal is visible, but wired to ground - ignoring the inferred RTL.  So there are two issues - Quartus II 8.1 fails to handle my example correctly, and - I don't know a workaround.  Why do I care? I'm implementing a processor that has both a signed and unsigned multiplication. The workaround you both suggest would hurt performance due to the additional mux.

[Altera_Forum]

I didn't check the device handbook. As said, signed is a parameter in lpm_mult, and as far as I understand, lpm_mult is generally used in multiplier inference. It may be the case, that the device handbook discusses a hardware feature, that has been forgotten in the Quartus software. You should ask Altera support how to access the said feature through Quartus.

[Altera_Forum]

Signed and Unsigned arithmatic is identical. the only difference is that signed arithmatic has the sign extended forward. This is why it is a parameter, not an input signal to select signed or unsigned. 

 so for example:  take the following 4 bit number:  1011 = 11 or -5  if this was put into an 8 bit multiplier (or 18 bits in the case of a cyclone 2), the number becomes: 00001011 for unsigned 11111011 for signed  You can do real time selection of signed or unsigned yourself, and therefor only use 1 mulitplier. What you have to do is set the signed/unsigned parameter to unsigned and then do all the sign extension yourself (or preferably, dont use the lpm library at all, just imply it). Rmember that all inputs then have to become 18 bit numbers. But it can be done quite easily.

[Altera_Forum]

Hi tricky, 

    --- Quote Start ---  Signed and Unsigned arithmatic is identical.  --- Quote End ---    I am afraid they are not. not only MSB meaning is different, addition/subtraction are similar(taking into account carry bit difference). multiplication/div are different.     --- Quote Start ---   the only difference is that signed arithmatic has the sign extended forward. This is why it is a parameter, not an input signal to select signed or unsigned.   --- Quote End ---  actually the document referred to, does say signa signb are inputs and not parameters.     --- Quote Start ---   so for example:  take the following 4 bit number:  1011 = 11 or -5  if this was put into an 8 bit multiplier (or 18 bits in the case of a cyclone 2), the number becomes: 00001011 for unsigned 11111011 for signed    --- Quote End ---  why do you think 1011 is negative or positive to start with. The multiplier inputs are meant to fully represent the range of bitwidth in each case, no room for sign extention...    --- Quote Start ---    You can do real time selection of signed or unsigned yourself, and therefor only use 1 mulitplier. What you have to do is set the signed/unsigned parameter to unsigned and then do all the sign extension yourself (or preferably, dont use the lpm library at all, just imply it). Rmember that all inputs then have to become 18 bit numbers. But it can be done quite easily.  --- Quote End ---   I am not sure?

[Altera_Forum]

Tricky, I recommend you do your homework on this one. The lower n-bit of the result of n-bit by n-bit multiplication is indeed the same whether signed or not, but the top n-bit aren't. And no, it's not trivial to get them.

[Altera_Forum]

I found, that the altmult_add MegaFunction is the most simple way to instantiate a hardware multiplier with variable signed/unsigned inputs. You can set the number of multipliers to one and adjust all MegaFunction parameters according to your needs. Basically, also the cycloneii_mac_mult or cycloneiii_mac_mult can be used, but there is no documentation on it.

[Altera_Forum]

I think Tricky's workaround is not far off, except that the multiplier should be specified as having signed inputs. Then either sign- or zero-extend each input (by 1 bit, say) based on whether it is a signed or unsigned value, which is trivial. That way, any unsigned value will always become a positive signed value, and a signed value will retain its sign. 

 I still don't understand why signa and signb aren't available though.

[Altera_Forum]

--- Quote Start ---  Hi tricky,  I am afraid they are not. not only MSB meaning is different, addition/subtraction are similar(taking into account carry bit difference). multiplication/div are different.   --- Quote End ---    Yes they are.....  take the following example:  0111 x 1011   Lets assume it is unsigned (7 x 11). Add 0's forward   00000111 x 00001011  result =   00000111 + 111 + + 111 ---------------- 01001101 (77)Now do the same but assume its signed (7x-5)  sign extend both inputs to 8 bits  00000111 x 11111011  00000111 + 111 + + 111 + 111 + 111 .... etc -------------------- = (..111)11011101 (= -35) now if you had treated this as unsigned (251 x 7) the result would be 11011011101 (1757) see the resemblence yet?     --- Quote Start ---   I still don't understand why signa and signb aren't available though.   --- Quote End ---  That is because the LPM library applies accross ALL technology, and some may not have specific signa/signb inputs. You will have to instantiate the specific multiplier for the technology you are using to get full access to internal signals.

[Altera_Forum]

You have chosen an example that works. 

 Now consider this: I want to multiply these two 3 bit values through same unsigned multiplier:  111 * 011 = ?  if viewed as unsigned, implies 7 * 3 = 21 [10101 correct]  if viewed as signed, implies -1 * 3 and should give -3  [ but 10101 is wrong now, means -11]  I don't know what you mean by sign extension here but let us try one bit extension:  0 111 * 0 011  7 * 3 = 21 0000 0000 10101 correct  1 111 * 0 011 15* 3 = 45 i.e. 101101 i.e./= -3  Correct ?, Wooooooo

[Altera_Forum]

--- Quote Start ---     Am I missing something?  --- Quote End ---    Yes. You need to sign extend 111 to 111111  so -1 x 3 =    11 + 11 + 11 + 11 + 11 +11 -------- 111101 = -3   Sign extension just means take the MSB and keep adding it to the front to the input up to the length of the result. Unsigned numbers are really signed numbers with an implied '0' sign bit

[Altera_Forum]

I just did my extesion correctly..see above post

[Altera_Forum]

you have to sign extend the inputs to the length of the output.  

 so for 2 4 bits inputs you get an 8 bit result. The sign extension has to go on for the full 8 bits (ie. treat the inputs as 8 bits)

[Altera_Forum]

Well, so far so good even with 1 bit extension...edit(no I was wrong in my numbers)  

You really know the tricks tricky ! Is this proven over whole range of values? Where did you get it from? Anyway, the problem of resizing inputs is not that attractive because you are going say from 8x8 mult to 16x16 , no way...if 9x9 also means 16x16 given the current mult grain

[Altera_Forum]

its just the standard 2's compliment rules. -ve numbers are just the same as the unsigned upper range. 

 The signa/b inputs will simply be to sign extend the inputs to the hardware multiplier. Using an appropriate type (signed/unsigned in VHDL) should get these turned on/off by the synthesisor.  But if you're not on the limit of the length of input (18x18 for most FPGA multipliers) you can manual sign extend up to the 18 bit limit and then ignore the top bits from the 36 bit result to get the correct answer.

[Altera_Forum]

--- Quote Start ---  I still don't understand why signa and signb aren't available though.  --- Quote End ---   They are available in MegaFunction, see my previous post.  Regarding the sign extension point, I don't see that it works without additional logic, provided, that the full multiplier resolution (e.g. 9x9 = 18) with Cyclone hardware multipliers shall be utililzed. As an example 0x1ff * 0x1ff should have a result of 0x3ffff (-1) in signed arithmetic and 0x3fc01 (261121) in unsigned.

[Altera_Forum]

--- Quote Start ---  They are available in MegaFunction, see my previous post.  Regarding the sign extension point, I don't see that it works without additional logic, provided, that the full multiplier resolution (e.g. 9x9 = 18) with Cyclone hardware multipliers shall be utililzed. As an example 0x1ff * 0x1ff should have a result of 0x3ffff (-1) in signed arithmetic and 0x3fc01 (261121) in unsigned.  --- Quote End ---     Whoops:  -1 x -1 = 1  0x1FF x 0x1FF = 0x3F801 when unsigned and 0x00001 when signed

[Altera_Forum]

Just to be clear: 

 0x1FF x 0x1FF becomes   0x001FF x 0x001FF for unsigned 0x3FFFF x 0x3FFFF for signed before any calculation is done.