Gowin DSP, signed or unsigned? Or does it matter?

[gnuarm]

i have designed multipliers using the old shift and add technique where the multiplier can not be signed.  I'm not certain it will work when the multiplicand is signed although it seems like it should.  I never gave much thought to whether a "proper" multiplier would multiply both signed and unsigned numbers the same.  Turns out it will... if it is made twice as long as otherwise needed and the inputs are sign extended for signed or zero filled for unsigned. 

So that is what the Gowin folks seem to be doing in their DSP units in the GW1N line of FPGAs, or something equivalent.  That is how they model it in simulation. 

Their documentation is pretty weak, but I guess they expect you are well versed with the DSP units from other brands and this is likely very similar.  They list the I/O ports of the module and give an equation for the functionality.  They even have something of a block diagram, but it is some sort of generic diagram with all manner of extra signals.  Trouble is none of this has any prose to explain the functions of the various I/Os or the details of the inner workings.  Then there is the issue of a language barrier.  I've always wondered why companies don't contract with a service to improve the grammar of their manuals.  Certainly that would not be an overly expensive exercise.  Considering they spend many millions on designing the chips, wouldn't it make sense to spend a few bucks on better docs?

I still need to verify this in simulation, but it appears the multiplier is controlled on each operation as to whether the inputs (each is separately controlled) are signed or unsigned.  The result is 36 bits as you would expect from 18 bit inputs.  They just do the math in 72 bits to get the correct result regardless of whether the inputs are signed or unsigned.  After staring at the docs for many days I finally figured this out.  All they needed was a one line explaining the input.  I guess that's what they have, one line in the ports list, but not a very complete one.

ASIGN[1:0]   I    Sign bit for input A

I still don't know why it's two bits here unless that's because there can be two multipliers.  But this is not the sign bit.  This controls the multiplier functionality to work with signed inputs or unsigned inputs.

I hope this is not just me being unfamiliar with these DSP units.  Is all this obvious to everyone else?

[Daixiwen]

Yes implementing a multiplier that is twice as big as needed should make it work with sign numbers. But of course as you said you need to declare somewhere if each input is signed or unsigned. I think most of the multiplier IPs I've seen use generics for that, but signals can also work. I don't use them a lot myself, as I prefer to use the unsigned and signed signal types and instantiating the multipliers directly in HLD code with the * operator.

As for the lack of documentation I think this is a general problem. Even with the "big" manufacturers that give you hundred pages of documentations, finding the exact information that you want is not always easy. I think they don't care, because when engineers determine which platform they will use for a project, the documentation quality doesn't come often into play. Maybe it should more. Also for them the documentation is not a product they sell, so I guess that management doesn't like the engineers to spend too many hours on it if they can't market it directly.

In your case I agree that it is not obvious from the description. A translation problem? "signed/unsigned bit for input A" would be better, but you still need to specify which bit value corresponds to signed and which one to unsigned.

[ejeffrey]

i have designed multipliers using the old shift and add technique where the multiplier can not be signed.  I'm not certain it will work when the multiplicand is signed although it seems like it should.  I never gave much thought to whether a "proper" multiplier would multiply both signed and unsigned numbers the same.  Turns out it will... if it is made twice as long as otherwise needed and the inputs are sign extended for signed or zero filled for unsigned. 

NxN->N multiplication is the same for signed vs unsigned -- the low bits of the product don't depend on whether the input is treated as signed or unsigned.  So if that is all you want you don't need to do anything.  This works because any terms that depends on the implicit sign bits at position >= N are shifted left by N positions and fall off the end of the output word.

If all you have is an unsigned multiplier, one way to implement signed full width multiplication (NxN->2N) is to sign extend the inputs length 2N and use an unsigned 2Nx2N->2N multiplier.  Since signed and unsigned multiplications are the same, the result will be correct.

That's pretty inefficient.  It is much easier if you have a signed multiplier as a primitive, then you only need to extend one bit since a signed N+1 bit number can hold up to 2^N-1.  So you can just sign or zero extend by a single bit and then use a N+1xN+1 multipler and you can handle singed or unsigned inputs easily.  That is equivalent to recognizing that in the previous version, the upper word of the extended inputs is either 0 or all ones so there is no reason to do all that math.  You can also use this to work out how to build a signed multiplier out of an unsigned one without extending by 2N.

For DSP applications the signedness of the arguments would usually be pre-determined but if you are making a CPU you would want a signal to tell it whether to treat the inputs as signed or unsigned.

[SiliconWizard]

You make a good point,  and that's something I used for multiplies in the RISC-V core I developed. It uses a single (n+1)x(n+1) multiplier for all mul operations, signed x signed, unsigned x unsigned and signed x unsigned. So the trick is to use a signed multiplier, and not a unsigned one.

[gnuarm]

You make a good point,  and that's something I used for multiplies in the RISC-V core I developed. It uses a single (n+1)x(n+1) multiplier for all mul operations, signed x signed, unsigned x unsigned and signed x unsigned. So the trick is to use a signed multiplier, and not a unsigned one.

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

[BrianHG]

You make a good point,  and that's something I used for multiplies in the RISC-V core I developed. It uses a single (n+1)x(n+1) multiplier for all mul operations, signed x signed, unsigned x unsigned and signed x unsigned. So the trick is to use a signed multiplier, and not a unsigned one.

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

Not completely true.  Just use an unsigned multiplier & handle the sign externally/in parallel.  If you wan an input to be signed, all you do is feed the multiplier the 'absolute value' of your signed number.  And if that number is negative, pass that sign info along to the output.  The input and output 2's compliment correction would be done by combinational logic.  Little trick, but, knowing how dedicated hardware multipliers are handled in FPGA, exceed 1 single bit too many and what would have used a single 18bitx18bit element may end up taking 2 of them.  This are efforts you should only consider if you need every last hardware multiplier block.

With Altera, just programming A * B in Verilog / VHDL will just automatically use what is nesary for speed, but, calling Altera's megafunction LPM_MULT does allow you to specify & restrict the number of multipliers elements used as well as selecting a trade off speed VS hardware blocks, and include pipelining function for enhanced speed with huge multiplier bit sizes.

Apparently recently discovered (working on my ellipse drawing algorithm in another thread), Altera seems to already consider a signed 19x19bit multiplier as an unsigned 18x18bit multiplier while handling the extra bit signs in extra gates outside the dedicated hardware 9x9bit multiplier elements in the CycloneIV series.  They must be doing something similar to what I used to do manually.

[SiliconWizard]

You make a good point,  and that's something I used for multiplies in the RISC-V core I developed. It uses a single (n+1)x(n+1) multiplier for all mul operations, signed x signed, unsigned x unsigned and signed x unsigned. So the trick is to use a signed multiplier, and not a unsigned one.

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

That's exactly what we were saying by talking about a (n+1)x(n+1) multiplier instead of n x n. It's still much better than a 2n x 2n multiplier as the OP talked about.
Now you can also use an unsigned n x n multiplier, as BrianHG said, and handle the sign separately. I tried both approaches actually, and the "best" one (area/speed) largely depends on "n", and/or the latency you're ok with if you pipeline all this.

[ejeffrey]

You make a good point,  and that's something I used for multiplies in the RISC-V core I developed. It uses a single (n+1)x(n+1) multiplier for all mul operations, signed x signed, unsigned x unsigned and signed x unsigned. So the trick is to use a signed multiplier, and not a unsigned one.

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

But you only have to extend it one bit not double the size.

[gnuarm]

@Brian, we are talking two different things.  Sure, you are only doing signed or unsigned or even a consistent mix of multiplies, then yes, the tool will select the right hardware. 

That is not the situation.  This started when I was talking about doing fixed point on a hard IP DSP function in an FPGA and I was having a hard time understanding the docs.  Someone asked me if the hardware was for signed or unsigned.  When I got to the bottom of the issue I found they had designed the hardware to handle either signed or unsigned.  The simulator software uses a standard multiply on a pair of SLV types using a library to assume the data is unsigned.  When I dug into it the simulation is sign/zero extending as controlled by a user input (real time, not a generic) to twice the input width producing a result that is four times as wide as the input and twice the bits as required on the output, then truncating to the 2N bit result.  I'm sure they don't bother calculating the extra bits. 

But yeah, if you are synthesizing the multiplier, it can be whatever you want it to be.

[gnuarm]

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

That's exactly what we were saying by talking about a (n+1)x(n+1) multiplier instead of n x n. It's still much better than a 2n x 2n multiplier as the OP talked about.
Now you can also use an unsigned n x n multiplier, as BrianHG said, and handle the sign separately. I tried both approaches actually, and the "best" one (area/speed) largely depends on "n", and/or the latency you're ok with if you pipeline all this.

Sure, if you are synthesizing a multiplier, you can make it do what you want.  But i don't think just sign extending it one bit will do the trick to make the same hardware work with both unless you mean to use N bits for unsigned values and N+1 bits for signed values on the same hardware.  In essence you are talking about just making everything one bit larger, but restricting the "unsigned" type to N bits with the sign bit set for positive values.  That's not really mixing signed an unsigned types on the same hardware. 

[gnuarm]

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

But you only have to extend it one bit not double the size.

If you have N bit data that can be either signed or unsigned I don't believe sign/zero extending the data by one bit will not fix the issue of using a single multiplier for both. 

Do a 4 bit example.  A simple one is multiplying 0xF times 0xF treating that as -1 times -1 or 15 times 15 by extending the sign bit by one or adding a zero for the unsigned case.

Code: [Select]

      1_1111
      1_1111x
      -------
      1_1111
     11_111
    111_11
   1111_1
 1_1111
------------
11_1100_0001

Toss the two high bits and you get 11000001 which is not 1.  It is also not 0xE1 which is the unsigned result, but then with the sign extension I would not expect to see that work. 

To make this work you have to double the input data width.  Otherwise you need to take the complement of the negative values and track if the result needs to be complemented.

[Daixiwen]

The trick with doubling the size of the multiplier to do signed multiplication is only interesting if the hardware multipliers in the FPGA can only do unsigned operations. In that case it is often the best solution for latency. As for the size, it does use a lot less logic around the hardware multipliers than other algorithms, but of course requires bigger multipliers, or combining of several multipliers.

Converting a signed vector to absolute value before multiplying it and then negate the value again when needed usually adds a lot of latency and will create a less optimal module. It's only advantage is that it uses smaller multipliers. Only use it if you are really limited in how many multipliers you can use in the FPGA.


But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed. Those in Altera FPGAs need to be configured in one or the other mode at compile time, contrary to the FPGAs used by the OP. If you need a module that can be dynamically configured and changed between unsigned and signed, as for example in an ALU, the n+1 trick can be useful. That said if you have enough logic resources and are looking for the lowest latency, instantiating both an unsigned and a signed multiplier and muxing between the two could generate faster logic.

I used a lot "usually" in here, as your mileage may vary, depending on the synthesis tool, and how close your signal sizes are to the limits of the hardware multiplier blocks. If one of those algorithms make the size go one bit over the maximum size of the hardware multiplier, it can force the synthesizer to add lots of logic, changing the results.

So if you want to make your design optimal, test different solutions and see what works best. And of course start by deciding if you want to optimize for logic resource usage or for speed, as it may lead to different solutions.

[Daixiwen]

If you have N bit data that can be either signed or unsigned I don't believe sign/zero extending the data by one bit will not fix the issue of using a single multiplier for both.

Extending the size by one bit works, but only if you use a signed multiplier. In that case, when the input is unsigned, extend it with a zero. It will generate a signed value equal to the unsigned one. If the input is signed, sign extend it and you will still have the same value.

The double trick only works to convert an unsigned multiplier to a signed one. And of course with some extra logic around it you can also make it universal, accepting both signed and unsigned inputs.

[BrianHG]

But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed. Those in Altera FPGAs need to be configured in one or the other mode at compile time, contrary to the FPGAs used by the OP. If you need a module that can be dynamically configured and changed between unsigned and signed, as for example in an ALU, the n+1 trick can be useful. That said if you have enough logic resources and are looking for the lowest latency, instantiating both an unsigned and a signed multiplier and muxing between the two could generate faster logic.

Altera's do have the option for a 'signed enable' input for each multiplicand so the multiplier can operate dynamically in any modes.

[SiliconWizard]

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

That's exactly what we were saying by talking about a (n+1)x(n+1) multiplier instead of n x n. It's still much better than a 2n x 2n multiplier as the OP talked about.
Now you can also use an unsigned n x n multiplier, as BrianHG said, and handle the sign separately. I tried both approaches actually, and the "best" one (area/speed) largely depends on "n", and/or the latency you're ok with if you pipeline all this.

Sure, if you are synthesizing a multiplier, you can make it do what you want.  But i don't think just sign extending it one bit will do the trick to make the same hardware work with both unless you mean to use N bits for unsigned values and N+1 bits for signed values on the same hardware.  In essence you are talking about just making everything one bit larger, but restricting the "unsigned" type to N bits with the sign bit set for positive values.  That's not really mixing signed an unsigned types on the same hardware.

No no, we (I say we because two of us were talking about the same thing) are saying that you can use a single, again signed (n+1)x(n+1) multiplier.
Of course you also need to sign extend both inputs, which then become (n+1)-bit wide. But it's just one bit, so that's very cheap (as far as the sign extension part is concerned). There's nothing else to do.

Edit: to make it clearer - in case you think it's not: you can make this configurable to cover all combinations of signed/unsigned. Inputs that are to be considered signed have to be sign-extended, inputs that are to be considered unsigned have to be zero-extended.

[gnuarm]

But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed. Those in Altera FPGAs need to be configured in one or the other mode at compile time, contrary to the FPGAs used by the OP. If you need a module that can be dynamically configured and changed between unsigned and signed, as for example in an ALU, the n+1 trick can be useful. That said if you have enough logic resources and are looking for the lowest latency, instantiating both an unsigned and a signed multiplier and muxing between the two could generate faster logic.

Altera's do have the option for a 'signed enable' input for each multiplicand so the multiplier can operate dynamically in any modes.

Yes, that is what is going on in the Gowin part, they have control signals to select sign or zero extension on each input on each multiply operation.  But no one addressed the example I provided that shows the N+1 case failing with -1 x -1. 

If your data is always signed, how do you change a multiplier to work with signed inputs without making it larger?

[BrianHG]

But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed. Those in Altera FPGAs need to be configured in one or the other mode at compile time, contrary to the FPGAs used by the OP. If you need a module that can be dynamically configured and changed between unsigned and signed, as for example in an ALU, the n+1 trick can be useful. That said if you have enough logic resources and are looking for the lowest latency, instantiating both an unsigned and a signed multiplier and muxing between the two could generate faster logic.

Altera's do have the option for a 'signed enable' input for each multiplicand so the multiplier can operate dynamically in any modes.

Yes, that is what is going on in the Gowin part, they have control signals to select sign or zero extension on each input on each multiply operation.  But no one addressed the example I provided that shows the N+1 case failing with -1 x -1. 

If your data is always signed, how do you change a multiplier to work with signed inputs without making it larger?

You mean something like this SV code?

Code: [Select]

input logic signed [15:0] a;
input logic signed [15:0] b;
output logic signed [31:0] y;

always_comb y=a*b;
You can also make output y [15:0] and it will save gates and still be signed.
Of course, you may make that logic always_ff @(posedge clk)  y<=a*b; to make it synchronous.
The compiler will use a 15x15bit multiplier automatically while using bit 16 to determine the sign & flip the beginning 15 bits using the 2's compliment rule.

If the compiler decides to use hardware multipliers, it cannot split apart a 9x9 element.  So in the case of the above code with an Alter Cyclone, it will use two 9bit multipliers to make that code work.  Even if I did a 10 bit multiplier, it would eat two 9bit elements unless I go specifically into the megafunction and turn down the speed hint setting to 1 out of 9.  The resulting multiplier would use 1 multiplier element plus some logic elements to make up the difference, but, the FMAX will be 100MHz instead of 275MHz.

[gnuarm]

Yes, that is what is going on in the Gowin part, they have control signals to select sign or zero extension on each input on each multiply operation.  But no one addressed the example I provided that shows the N+1 case failing with -1 x -1. 

If your data is always signed, how do you change a multiplier to work with signed inputs without making it larger?

You mean something like this SV code?

Code: [Select]

input logic signed [15:0] a;
input logic signed [15:0] b;
output logic signed [31:0] y;

always_comb y=a*b;
You can also make output y [15:0] and it will save gates and still be signed.
Of course, you may make that logic always_ff @(posedge clk)  y<=a*b; to make it synchronous.
The compiler will use a 15x15bit multiplier automatically while using bit 16 to determine the sign & flip the beginning 15 bits using the 2's compliment rule.

If the compiler decides to use hardware multipliers, it cannot split apart a 9x9 element.  So in the case of the above code with an Alter Cyclone, it will use two 9bit multipliers to make that code work.  Even if I did a 10 bit multiplier, it would eat two 9bit elements unless I go specifically into the megafunction and turn down the speed hint setting to 1 out of 9.  The resulting multiplier would use 1 multiplier element plus some logic elements to make up the difference, but, the FMAX will be 100MHz instead of 275MHz.

You are showing source code without considering implementation.  I'm not at all clear what your point is.  I'm not synthesizing a multiplier.  I am using the hard IP multiplier in the part as part of the DSP unit which really should be called a MAC since that's all it is really.  I guess DSP sounds sexier. 

Above you talk about the synthesis tool complimenting the value and using an unsigned multiplier.  While that is possible, I don't see any indication of that being done in this case.  Their simulation code sign/zero extends the data to 2N bits input to the multiply expression. 

BTW, to do a larger multiply take 4 multipliers rather than 2.  Split each input in two and now you have four partial products to calculate and add.  The Gowin hardware seems to support that with separate inputs they call CASI and CASO, 55 bits wide.  The DSP block also has two 18 bit multipliers to directly support 18 x 36 bit inputs. 

Working with fixed point seems to mean the intermediate scale factors are adjusted to maintain the radix point, then scaling at the end to get the final output from the calculation.  If I do all that, maybe it would not be any harder to work in floating point.  To adjust the radix point after a calculation the result can be run through the multiplier again acting as the barrel shifter.  Maybe I should just make everything signed with 17 bits of precision and keep track of the exponent separately. 

[BrianHG]

Floating point is a different animal all together.  Your FPGA should have optimization withing it's core to handle float or doubles and it should skip a good potion of expanded notation internally.  Altera calls these DSP elements and they do use the multiplier blocks in the older Cyclones and the newer Cyclones, like V which have fewer DSP elements instead of the 9x9 multiplier elements can perform multiple pipelined floating point 32bit arithmetic functions using the same DSP block.  This makes for better accelerated ALU designs where you may want to do more than just multiply.

(The again, Altera's renaming/relabeling the 'DSP Units' may just be for marketing reasons and it may be the same old junk, just locked into a minimum 18x18bit or 36x36 bit instead of the smaller higher quantity 9x9 units in the older FPGAs...)

[asmi]

But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed.

Multiplier in DSP tiles of Xilinx 7 series FPGAs is 25x18 two's complement signed. There is no unsigned version.

[ejeffrey]

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

But you only have to extend it one bit not double the size.

If you have N bit data that can be either signed or unsigned I don't believe sign/zero extending the data by one bit will not fix the issue of using a single multiplier for both. 

It absolutely will, as long as your multiplier macro is always doing signed multiplication.  A signed N+1 bit register can hold every legal value that an unsigned or signed N bit register.

Do a 4 bit example.  A simple one is multiplying 0xF times 0xF treating that as -1 times -1 or 15 times 15 by extending the sign bit by one or adding a zero for the unsigned case.

Your example does unsigned multiplication on the extended value which is not correct.  The single bit extension only works if your multiplier primitive is doing signed multiplication.

[gnuarm]

But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed.

Multiplier in DSP tiles of Xilinx 7 series FPGAs is 25x18 two's complement signed. There is no unsigned version.

Hmmm...  So how do they implement the signed multiply???  That's what I'm  getting at. 

I did see one page that talked about moderately small modifications to make a signed multiplier.  It involved inverting specific bits in the partial products.  At the time I was still working to come up to speed on what the durn Gowin parts were doing, so i didn't spend much time on it and i don't have the link.  I can't say if that page was accurate or not.  Otherwise the only signed multipliers I've seen either work with the absolute value and handle sign at the end or use the double width option which does seem rather inefficient.  Oh, I have seen any number of web pages that are wrong in some sense if not literally (not being able to do binary arithmetic).

I think a lot of posters here are thinking in terms of what they need to do to USE the multiplier blocks rather than how they are implemented.  As I've said, my initial problem was a lack of documentation on the Gowin devices and my resultant confusion.  I did not realize the Gowin multiplier was controllable for signed/unsigned until someone asked me which it was starting my decent down the rabbit hole.  Obviously this is how all FPGA multipliers are constructed, I just was not aware of that.

[gnuarm]

But AFAIK the hardware multipliers nowadays in FPGAs can do both signed and unsigned operations, so those kind of tricks aren't really needed.

Multiplier in DSP tiles of Xilinx 7 series FPGAs is 25x18 two's complement signed. There is no unsigned version.

Are you sure of that?  If so, you can't use a single block to do 18 bit unsigned multiplies.  That's ugly.  I bet they have a signed/unsigned control like Gowin.  Gowin does the thing where they generate a hunk of code that surrounds the core primitive with a wrapper that drives unneeded signals and feeds the generics to create fixed mode, simpler blocks for you.  Is that what Xilinx is doing, hiding the signed/unsigned control if you are asking for a signed multiply?

[gnuarm]

The problem is the signed multiplier does not work for unsigned or mixed parameters... unless you do the trick of extending the length of the multiplier.  There is no free lunch.

But you only have to extend it one bit not double the size.

If you have N bit data that can be either signed or unsigned I don't believe sign/zero extending the data by one bit will not fix the issue of using a single multiplier for both. 

It absolutely will, as long as your multiplier macro is always doing signed multiplication.  A signed N+1 bit register can hold every legal value that an unsigned or signed N bit register.

Do a 4 bit example.  A simple one is multiplying 0xF times 0xF treating that as -1 times -1 or 15 times 15 by extending the sign bit by one or adding a zero for the unsigned case.

Your example does unsigned multiplication on the extended value which is not correct.  The single bit extension only works if your multiplier primitive is doing signed multiplication.

So how do you do signed multiplication on a bit level?

[asmi]

Are you sure of that?  If so, you can't use a single block to do 18 bit unsigned multiplies. 

Yes I am. And so can be you if you do a 1 minute-long research.

I bet they have a signed/unsigned control like Gowin

And you would lose that bet.

Is that what Xilinx is doing, hiding the signed/unsigned control if you are asking for a signed multiply?

No, you can instantiate the primitive directly and take full control over all inputs, outputs and parameters.