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.

[langwadt]

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?

https://www.dsprelated.com/blogimages/MarkusNentwig/bl_serParMul/img1.png

[gnuarm]

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.

Then that DSP unit is limited in not being able to do 18 bit unsigned multiplies.  Seems a tad restrictive.

[coppice]

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

Look up Booth's algorithm. Most parallel multipliers are either: a) a Wallace tree, which gives you an unsigned result and requires extra logic to give you a signed result; or b) a Booth tree, which gives you a 2's comp signed result, and requires extra logic to give you a unsigned result. Booth's algorithm also works for serial by parallel and pure serial multiplication, producing a signed result.

[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?

https://www.dsprelated.com/blogimages/MarkusNentwig/bl_serParMul/img1.png

However, that does not work...  -1 x -1
 

Code: [Select]

      1111
      1111x
     ------
 1111_1111
 1111_111
 1111_11
 1111_1
 ----------
 1111_0001 = 0xF1 = -15
That's just not right.  Did I do it wrong?  I've been through this a number of times and many, many sources on the web are not right or I'm totally confused.  Many of the web pages lop off the N msbs of the product and show the N lsbs only - saying, "see!"  But if you want the full 2N bits of the product this won't work.

[gnuarm]

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

Look up Booth's algorithm. Most parallel multipliers are either: a) a Wallace tree, which gives you an unsigned result and requires extra logic to give you a signed result; or b) a Booth tree, which gives you a 2's comp signed result, and requires extra logic to give you a unsigned result. Booth's algorithm also works for serial by parallel and pure serial multiplication, producing a signed result.

Yes, I think it was a page showing Booth's algorithm that inverted a few bits to change between signed and unsigned.  i don't recall the detail. 

i guess the simulation code I was looking at that used 2N bits in the inputs and a 4N bit intermediate product was done just to achieve the same result in simulation rather than accurately reflecting the mechanics. 

So a Booth's multiplier with N+1 bit inputs will do the job if the input data is extended appropriately.  Great, thanks.  I don't know why, but it helps me when using tools and devices when I have a better understanding of how they work.  Now I need to work on extending this to floating point so I don't have to futz with the awkward math of fixed point.

[langwadt]

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?

https://www.dsprelated.com/blogimages/MarkusNentwig/bl_serParMul/img1.png

However, that does not work...  -1 x -1
 

Code: [Select]

      1111
      1111x
     ------
 1111_1111
 1111_111
 1111_11
 1111_1
 ----------
 1111_0001 = 0xF1 = -15
That's just not right.  Did I do it wrong?  I've been through this a number of times and many, many sources on the web are not right or I'm totally confused.  Many of the web pages lop off the N msbs of the product and show the N lsbs only - saying, "see!"  But if you want the full 2N bits of the product this won't work.

0xff+0xfe+0xfc-0xf8 = 0xff+0xfe+0xfc+0x07+1  =  0x301  = 0x01

[asmi]

Then that DSP unit is limited in not being able to do 18 bit unsigned multiplies. 

So what? These numbers (18 and 25) are not just random numbers, they were chosen for a reason.

Seems a tad restrictive.

Why? How often do you need 18x25 unsigned multiplication, as opposed to something like 16x16 bit one, or 24x24, or 53x53? All of those can be implemented using these tiles with minimal additional logic (mostly SRLs for sign extension and pipeline registers).

[ejeffrey]

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

It's pretty much the same way you do unsigned multiplication, just remembering the notional leading ones on negative numbers.  You can work out the exact formula by using your initial observation that you can extend out to double width.  This works because the lower N bits of a multipliers output doesn't depend on whether the inputs are signed or unsigned.   Then you write the product as x * y = (a + b<<N) * (c + d<<N).  Since 'c' and 'd' are the sign extension part they are either '0' or '-1' (all ones).  So you end up with a*c using an unsigned multiplier and then doing a couple of conditional subtractions off the high word. Presumably if you are building a multiplier from scratch you just design this into the multiplier, but it is a simple way to "convert" a multiplier macro from unsigned to signed or vice versa.

[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?

https://www.dsprelated.com/blogimages/MarkusNentwig/bl_serParMul/img1.png

However, that does not work...  -1 x -1
 

Code: [Select]

      1111
      1111x
     ------
 1111_1111
 1111_111
 1111_11
 1111_1
 ----------
 1111_0001 = 0xF1 = -15
That's just not right.  Did I do it wrong?  I've been through this a number of times and many, many sources on the web are not right or I'm totally confused.  Many of the web pages lop off the N msbs of the product and show the N lsbs only - saying, "see!"  But if you want the full 2N bits of the product this won't work.

0xff+0xfe+0xfc-0xf8 = 0xff+0xfe+0xfc+0x07+1  =  0x301  = 0x01

Sorry, but that is not right.  I do not know how you justify the step replacing 0xf8 with 0x07+1.  I did the hex math on a calculator and it comes up with 0x3F1

[gnuarm]

Then that DSP unit is limited in not being able to do 18 bit unsigned multiplies. 

So what? These numbers (18 and 25) are not just random numbers, they were chosen for a reason.

Seems a tad restrictive.

Why? How often do you need 18x25 unsigned multiplication, as opposed to something like 16x16 bit one, or 24x24, or 53x53? All of those can be implemented using these tiles with minimal additional logic (mostly SRLs for sign extension and pipeline registers).

The 18 number is picked because it matches the data width of the block rams.  That is what the people from Xilinx said in the FPGA usenet group some years back.  Can't say why 25 is a magic number.  The Gowin part provides two 18x18 multipliers in each DSP unit to allow 36 x 18 multiplies for obvious reasons. 

I don't need 25x18, but I do need 18x18.  I'm not really clear on what point you are trying to make...? 

What I meant by restrictive is that if the multiplier is signed only, then the data width is limited to 17 bits of unsigned math.  Obviously it's not so hard to provide a multiplier that works at full width with either signed and unsigned data since so many do it.

[gnuarm]

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

It's pretty much the same way you do unsigned multiplication, just remembering the notional leading ones on negative numbers.  You can work out the exact formula by using your initial observation that you can extend out to double width.  This works because the lower N bits of a multipliers output doesn't depend on whether the inputs are signed or unsigned.   Then you write the product as x * y = (a + b<<N) * (c + d<<N).  Since 'c' and 'd' are the sign extension part they are either '0' or '-1' (all ones).  So you end up with a*c using an unsigned multiplier and then doing a couple of conditional subtractions off the high word. Presumably if you are building a multiplier from scratch you just design this into the multiplier, but it is a simple way to "convert" a multiplier macro from unsigned to signed or vice versa.

Sorry, I'm not following your abstraction.  It's late, I'll look at it again tomorrow.  Did you mean "Since 'b' and 'd' are the sign extension part..."

Even so, the abstraction does not mean you can ignore the b<<N and d<<N parts since the 2N bit product of interest includes c * b<<N and a * d<<N.  If the product were only a * c we would not be having this conversation. 

[langwadt]

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?

https://www.dsprelated.com/blogimages/MarkusNentwig/bl_serParMul/img1.png

However, that does not work...  -1 x -1
 

Code: [Select]

      1111
      1111x
     ------
 1111_1111
 1111_111
 1111_11
 1111_1
 ----------
 1111_0001 = 0xF1 = -15
That's just not right.  Did I do it wrong?  I've been through this a number of times and many, many sources on the web are not right or I'm totally confused.  Many of the web pages lop off the N msbs of the product and show the N lsbs only - saying, "see!"  But if you want the full 2N bits of the product this won't work.

0xff+0xfe+0xfc-0xf8 = 0xff+0xfe+0xfc+0x07+1  =  0x301  = 0x01

Sorry, but that is not right.  I do not know how you justify the step replacing 0xf8 with 0x07+1.  I did the hex math on a calculator and it comes up with 0x3F1

it is signed numbers, the MSB has negative "weight" so 0xf8 needs to be subtracted not added

or add 0xF8 inverted which in 2-complement is invert all the bits = 0x07 and add one

[ejeffrey]

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

It's pretty much the same way you do unsigned multiplication, just remembering the notional leading ones on negative numbers.  You can work out the exact formula by using your initial observation that you can extend out to double width.  This works because the lower N bits of a multipliers output doesn't depend on whether the inputs are signed or unsigned.   Then you write the product as x * y = (a + b<<N) * (c + d<<N).  Since 'c' and 'd' are the sign extension part they are either '0' or '-1' (all ones).  So you end up with a*c using an unsigned multiplier and then doing a couple of conditional subtractions off the high word. Presumably if you are building a multiplier from scratch you just design this into the multiplier, but it is a simple way to "convert" a multiplier macro from unsigned to signed or vice versa.

Sorry, I'm not following your abstraction.  It's late, I'll look at it again tomorrow.  Did you mean "Since 'b' and 'd' are the sign extension part..."

Even so, the abstraction does not mean you can ignore the b<<N and d<<N parts since the 2N bit product of interest includes c * b<<N and a * d<<N.  If the product were only a * c we would not be having this conversation.

Yes I meant b and d. 

I'm not ignoring them, but since b and d are either 0 or -1 it doesn't require multiplication just subtraction. If x is signed multiplication and * is unsigned:

a x c = a * c -? a << N -? c << N + b*d << 2N

The -? Means " subtract a if c is negative" and vice versa while the last term is shifted past the output register and can be ignored but you need if you calculate with arbitrary width integers

[asmi]

I don't need 25x18, but I do need 18x18.  I'm not really clear on what point you are trying to make...? 

My point is you have too narrow view on your specific task, while DSPs (and all hard blocks in general) have to be as general purpose and cover as many different use cases as possible.
Single-precision floating point multiplication requires unsigned 24x24 multiplication, which can easily be implemented using two DSP tiles (and it just so happened that a DSP slice contains two tiles). This is where 25 is coming from.

What I meant by restrictive is that if the multiplier is signed only, then the data width is limited to 17 bits of unsigned math.  Obviously it's not so hard to provide a multiplier that works at full width with either signed and unsigned data since so many do it.

What kind of experience do you have in ASIC design which would let you say that anything is "obvious"? DSP tile in 7 series can run at over 500 MHz, so each additional combinatorial logic is going to reduce that frequency. What about your gowin FPGAs? How fast their DSPs run? And if the choice is between signed and unsigned multiplicator, the former is an obvious choice.

[coppice]

What I meant by restrictive is that if the multiplier is signed only, then the data width is limited to 17 bits of unsigned math.  Obviously it's not so hard to provide a multiplier that works at full width with either signed and unsigned data since so many do it.

If you want to hammer a DSP peg into a non-DSP hole you have to live with the limitations you find. Most FPGAs are not generic. They are very application specific. Anything which gets in the way of maximum DSP performance will see the device punished in the market place. Few people will be attracted by a wide word unsigned multiply, so there is little compensating upside. Its just a lose lose for the vendor.

[SiliconWizard]

What I meant by restrictive is that if the multiplier is signed only, then the data width is limited to 17 bits of unsigned math.  Obviously it's not so hard to provide a multiplier that works at full width with either signed and unsigned data since so many do it.

If you want to hammer a DSP peg into a non-DSP hole you have to live with the limitations you find. Most FPGAs are not generic. They are very application specific. Anything which gets in the way of maximum DSP performance will see the device punished in the market place. Few people will be attracted by a wide word unsigned multiply, so there is little compensating upside. Its just a lose lose for the vendor.

Agreed!

[gnuarm]

I don't need 25x18, but I do need 18x18.  I'm not really clear on what point you are trying to make...? 

My point is you have too narrow view on your specific task, while DSPs (and all hard blocks in general) have to be as general purpose and cover as many different use cases as possible.
Single-precision floating point multiplication requires unsigned 24x24 multiplication, which can easily be implemented using two DSP tiles (and it just so happened that a DSP slice contains two tiles). This is where 25 is coming from.

And yet many, many FPGAs are not designed this same way.   I guess they are all destine for the trash bin of the FPGA world.  BTW, I don't follow why 25 bits is needed to do 24 bit multiplies.  Is that because the floating point multiplication uses unsigned data and the multiplier can't do full width multiplies? 

The Gowin parts can provide a 36x18 multiply in a single tile and have data paths which I assume is intended to allow multiple units to be combined into higher precision for floating point and other functions. 

I've not even indicated what my task is.  How can my questions be focused on that?  But let's not allow this conversation to become personal.  Let's keep it professional, no?

What I meant by restrictive is that if the multiplier is signed only, then the data width is limited to 17 bits of unsigned math.  Obviously it's not so hard to provide a multiplier that works at full width with either signed and unsigned data since so many do it.

What kind of experience do you have in ASIC design which would let you say that anything is "obvious"? DSP tile in 7 series can run at over 500 MHz, so each additional combinatorial logic is going to reduce that frequency. What about your gowin FPGAs? How fast their DSPs run? And if the choice is between signed and unsigned multiplicator, the former is an obvious choice.

i explained my thought clearly.  The fact that multiple FPGA vendors provide multiplier units that can perform full width signed or unsigned multiplies shows it is not hard to do.  No need to be an ASIC wizard.  BTW, I will be running the DSP unit at 34 MHz.

[gnuarm]

What I meant by restrictive is that if the multiplier is signed only, then the data width is limited to 17 bits of unsigned math.  Obviously it's not so hard to provide a multiplier that works at full width with either signed and unsigned data since so many do it.

If you want to hammer a DSP peg into a non-DSP hole you have to live with the limitations you find. Most FPGAs are not generic. They are very application specific. Anything which gets in the way of maximum DSP performance will see the device punished in the market place. Few people will be attracted by a wide word unsigned multiply, so there is little compensating upside. Its just a lose lose for the vendor.

Sorry, your simile is not clear.  What is the peg and what is the hole?  The DSP units I'll be using in the Gowin parts will do 18x18 multiplies easily in one DSP block and can be switched between signed and unsigned on the fly. 

I really don't get why you say FPGAs are not generic.  FPGAs are all about being generic.  The parts I am using are low end, low cost parts that are intended for general work like picking an MCU.  Only 4 or 9 kLUT and a price tag of $3 or $4.  Once people get over their aversion to using a product from a new company these parts will take off like a rocket!  Sure, A and X will still own the high ground and supply the comms companies with $1000 FPGAs, but that will not be the market in another five or ten years.   There are four mainstream, long term players in the field and there are as many if not more new entrants with low cost devices.  I believe you can buy a 1 kLUT chip for around $1 from Gowin.  I think the 1 kLUT device has no DSP blocks though, that requires a 4 kLUT part at $3, 16 DSP to be exact.   These parts are every bit as generic as a low end MCU.

[asmi]

i explained my thought clearly.  The fact that multiple FPGA vendors provide multiplier units that can perform full width signed or unsigned multiplies shows it is not hard to do.  No need to be an ASIC wizard. 

OK, so please do us all a favor and name FPGA families which have DSP that support both signed and unsigned modes, and run at least at 500 MHz.

BTW, I will be running the DSP unit at 34 MHz.

You don't need any DSP for that kind of frequency. Logic on many decent FPGAs is easily fast enough to handle that.

[NorthGuy]

The parts I am using are low end, low cost parts that are intended for general work like picking an MCU.  Only 4 or 9 kLUT and a price tag of $3 or $4.

The newest Xilinx's XC7S6 has roughly 4k 6-input LUTs, each of them is equivalent to 4 4-input LUTs, so it's roughly 16k LUTs and it costs $15. This doesn't sound strikingly more expensive per-LUT than GOWIN, but it is much faster, and I believe better.

If you look at older Spartan 6, such as XC6SLX4 with 2400 6-input LUTs, it's roughly $10 for about 10k LUTs. If you agree to buy them from China, you can buy for $4, may be even less. Search AliExpress. May be they're better buy than GOWIN.

[nigelwright7557]

Simple store original signs and do a unsigned multiply after changing both numbers to unsigned.
Then use stored signs to correct outputs sign.
++ = +
-+=-
+-=-
--=+
But watch for overflows or double up number of bits for output.

[gnuarm]

The parts I am using are low end, low cost parts that are intended for general work like picking an MCU.  Only 4 or 9 kLUT and a price tag of $3 or $4.

The newest Xilinx's XC7S6 has roughly 4k 6-input LUTs, each of them is equivalent to 4 4-input LUTs, so it's roughly 16k LUTs and it costs $15. This doesn't sound strikingly more expensive per-LUT than GOWIN, but it is much faster, and I believe better.

If you look at older Spartan 6, such as XC6SLX4 with 2400 6-input LUTs, it's roughly $10 for about 10k LUTs. If you agree to buy them from China, you can buy for $4, may be even less. Search AliExpress. May be they're better buy than GOWIN.

That is very Xilinx centric thinking.  If you need a $2 MCU are you going to use a $5 MCU because it is just as cost effective per byte of flash or per MHz?  I would also point out that a 6 input LUT is not at all equivalent to four 4 input LUTs.  If you have an adder, it only needs a 4 input LUT per bit.  Unless you have other logic to combine with that the other 3/4 of the LUT is wasted as an example.  A counter only needs 3 inputs, etc.  Still, it's not all pricing.   I would have likely used the part if it came in a downsided package.  The QFP144 is bigger than my last board is wide.  I don't like BGAs because of the hassle of the ultra fine trace/space and vias required.

I don't understand what you mean about buying "them from China"?  You mean buying counterfeits?  Why would anyone want to buy counterfeit parts?  They likely don't work as well if at all and subjects YOU to being fined for selling counterfeit goods. 

I've never understood why people think you have to use Xilinx or Altera.  I haven't used one of their parts in nearly two decades.  They aren't the only FPGA companies in town and by no means make the only worthwhile products. 

I just found that Gowin might be selling an ARM+FPGA product in a QN88 package that would be ideal to replace the Lattice part that is now EOL and is getting expensive to buy.  Being able to add an ARM is a nice bonus.  I'm not a fan of the large thermal pad that makes it harder to add vias.  My boards tend to be very tiny and dense.  Thermal pads should be for devices that need thermal pads. 

[asmi]

I don't understand what you mean about buying "them from China"?  You mean buying counterfeits?  Why would anyone want to buy counterfeit parts?  They likely don't work as well if at all and subjects YOU to being fined for selling counterfeit goods. 

There is no hassle nor ultrafine trace/space is required in most cases. BGA is the best package there is, especially if high-speed and/or dense design is your goal. No QFN/QPF can get even close for IO density to BGAs.

I've never understood why people think you have to use Xilinx or Altera.  I haven't used one of their parts in nearly two decades.  They aren't the only FPGA companies in town and by no means make the only worthwhile products. 

That's because they are the best. I like to use the best, rather than faffing around with inferior devices.

[NorthGuy]

If you have an adder, it only needs a 4 input LUT per bit.  Unless you have other logic to combine with that the other 3/4 of the LUT is wasted as an example.  A counter only needs 3 inputs, etc.

Xilinx has built-in carry chains for adders and counters (4 carry cells in every CLB), or DSP blocks if you need long or fast. These things don't even count in the number of LUTs.

I don't like BGAs because of the hassle of the ultra fine trace/space and vias required.

You can fan out 1mm pitch BGA with 6-8 mil traces. Doesn't sound like ultra fine to me.

I don't understand what you mean about buying "them from China"?  You mean buying counterfeits?

I don't think they're counterfeits. I think most of them are new, some may be reused. It depends on the seller. So, there's a certain level of uncertainty. I am not a specialist. Nonetheless, Chinese prices are lower. I think it's the same whether you buy GOWIN or Xilinx. If you want to compare prices, you need to compare Chinese GOWIN prices to Chinese Xilinx prices, or Mouser's GOWIN prices to Mouser's Xilinx prices, but not Chinese GOWIN prices to Mouser's XIlinx prices.

I've never understood why people think you have to use Xilinx or Altera. I haven't used one of their parts in nearly two decades.

Look at datasheets and compare. You'll see the differences. It's up to you to weigh costs and benefits.

[gnuarm]

If you have an adder, it only needs a 4 input LUT per bit.  Unless you have other logic to combine with that the other 3/4 of the LUT is wasted as an example.  A counter only needs 3 inputs, etc.

Xilinx has built-in carry chains for adders and counters (4 carry cells in every CLB), or DSP blocks if you need long or fast. These things don't even count in the number of LUTs.

Not sure what you are trying to say.  The carry chain only handles the carry... hence the name.  Every adder and counter uses 1 LUT per bit whether they are 4 input or 6 input LUTs.  Are you suggesting they now have dedicated adder logic entirely separate from the LUTs to process the entire adder function?

I don't like BGAs because of the hassle of the ultra fine trace/space and vias required.

You can fan out 1mm pitch BGA with 6-8 mil traces. Doesn't sound like ultra fine to me.

We aren't talking about 1 mm pitch BGAs.  The parts available for the small Gowin devices are 0.5 or 0.4 mm pitch.  The whole point is to have a very small package to support mobile applications which is the high volume market for low end devices just like the 1,000 pin behemoths are for the high dollar/high profit telecomms and server markets which is where X and A are aligned.

Even with 1 mm pitch BGAs, you can't use a reasonable drill/via size like 10 mil/24 mil.  I don't recall how small the vias have to be, but the bottom line is there are no BGA packages that allow the cheapest boards or part costs.  If nothing else the 1 mm pitch BGAs are high pin counts with correspondingly higher prices because of the longer testing time. 

It was Xilinx people who pointed out the floor of chip production cost was from tester time.  Those are not inexpensive machines and time on them is money.  You can have the smallest die in the world, but you still have to test them, so the higher pin count packages are higher dollar.  64 and 100 pin packages are the sweet spot for the work I do.  QFPs are great and QFNs will do.

I don't understand what you mean about buying "them from China"?  You mean buying counterfeits?

I don't think they're counterfeits. I think most of them are new, some may be reused. It depends on the seller. So, there's a certain level of uncertainty. I am not a specialist. Nonetheless, Chinese prices are lower. I think it's the same whether you buy GOWIN or Xilinx. If you want to compare prices, you need to compare Chinese GOWIN prices to Chinese Xilinx prices, or Mouser's GOWIN prices to Mouser's Xilinx prices, but not Chinese GOWIN prices to Mouser's XIlinx prices.

Sorry, I've not explored the grey market until now.  The AKM factory burned down (it was in a wooden building!) and the parts are 10x the price and not available through normal channels.  So I've bought 10 to see if they will work.  If they do I'll buy 1000 or so to be able to make my current production boards for the rest of this year.

Otherwise I would never touch such products.  I have no idea why you would prefer grey market components over factory new components.  I don't have any reason to prefer any parts just because they have this company's name rather than that company's name on them.  I'm not in love with X or A. 

The Gowin parts I buy will be through Gowin approved US distributors, not grey market Chinese Alibaba channels.  Digikey and Mouser are terrible places to get pricing on FPGAs.  They simply don't discount as a rule.  You might get price breaks up to 100, if that.  All FPGA makers expect you to haggle directly.  I been down that road many times.

I've never understood why people think you have to use Xilinx or Altera. I haven't used one of their parts in nearly two decades.

Look at datasheets and compare. You'll see the differences. It's up to you to weigh costs and benefits.

Why do you think I don't look at data sheets?  That's how I know that Xilinx doesn't even make a part that will fit on my board unless i want to go with more expensive design rules.  It's 21.5 mm wide.  A QFP100 fits very well.  I guess I could use a QFP144 and wrap the pins around the board, soldered to the other side.

[asmi]

Even with 1 mm pitch BGAs, you can't use a reasonable drill/via size like 10 mil/24 mil.  I don't recall how small the vias have to be, but the bottom line is there are no BGA packages that allow the cheapest boards or part costs.  If nothing else the 1 mm pitch BGAs are high pin counts with correspondingly higher prices because of the longer testing time. 

10 mil is not reasonable - it's stone age technology at this point. See the JLCPCB ad at the top of the page - they can manufacture 4 layer boards with 3.5/3.5 mil and 0.25/0.4 mm vias for $7 per 5 boards! It doesn't get any cheaper than that! And you can get controlled impedance at no extra cost! Slightly higher "grade" fabs like WellPCB can go as low as 3/3 mils and 0.15/0.3 mm vias for a bit more money - about $40 per 5 boards, and they will manufacture custom stackup at no extra cost. I use them extensively for my 4 and 6 layer designs, so I have confidence in their quality and ability to deliver, even if they are not the fastest fab around.

Why do you think I don't look at data sheets?  That's how I know that Xilinx doesn't even make a part that will fit on my board unless i want to go with more expensive design rules.  It's 21.5 mm wide.  A QFP100 fits very well.  I guess I could use a QFP144 and wrap the pins around the board, soldered to the other side.

It's very obvious to anyone "in the know" that you didn't look, because if you did, you'd know that there are a lot of packages smaller than 21.5 mm. Smallest 1 mm pitch package is Spartan-7 in BGA-196 package, which is 15x15 mm and has 100 user IO pins, which is more than QFP100 and even QFP144. Not to mention that BGA packages provide far superior signal integrity for high-speed signals. Heck, take a look at the project linked in my signature - it uses that very S7 device, and drives 128Mx16 DDR2 memory, while still leaving almost entire IO bank (50 pins) for other connections. There are 13x13 packages with 0.8 mm pitch, which again can be broken out on cheap JLCPBC process.

If you want the absolute smallest package, take a look at Artix-7 in CP236/CP238 packages (10x10 mm). They are nominally 0.5 mm pitch, but their pinout (see attached pictures) is such that you can easily fully break it out on just two signal layers. You will need to "massage" the footprint a bit to get it to work with JLCPCB's 3.5 mil limit (using some other fab like WellPCB which can do 3 mil will make things much easier), but you can get up to 50K logic cells, and - the coolest part - 2 multi-gigabit transceivers capable of reaching up to 6.25 Gpbs each (depending on speed grade).

[gnuarm]

Even with 1 mm pitch BGAs, you can't use a reasonable drill/via size like 10 mil/24 mil.  I don't recall how small the vias have to be, but the bottom line is there are no BGA packages that allow the cheapest boards or part costs.  If nothing else the 1 mm pitch BGAs are high pin counts with correspondingly higher prices because of the longer testing time. 

10 mil is not reasonable - it's stone age technology at this point. See the JLCPCB ad at the top of the page - they can manufacture 4 layer boards with 3.5/3.5 mil and 0.25/0.4 mm vias for $7 per 5 boards! It doesn't get any cheaper than that! And you can get controlled impedance at no extra cost! Slightly higher "grade" fabs like WellPCB can go as low as 3/3 mils and 0.15/0.3 mm vias for a bit more money - about $40 per 5 boards, and they will manufacture custom stackup at no extra cost. I use them extensively for my 4 and 6 layer designs, so I have confidence in their quality and ability to deliver, even if they are not the fastest fab around.

0.25 mm IS 10 mil.  You can't route the fine pitch BGA parts using 10 mil via holes.  The last batch of boards I built had some $40+ worth of components and I only paid $60 to have built including assembly and test!  Even $5 per board pushes my costs up not to mention the cost of a large part vs. the smaller I/O count I need.  Add in the costs of adding extra layers to escape the BGA footprint and it mounts up quickly.

Why do you think I don't look at data sheets?  That's how I know that Xilinx doesn't even make a part that will fit on my board unless i want to go with more expensive design rules.  It's 21.5 mm wide.  A QFP100 fits very well.  I guess I could use a QFP144 and wrap the pins around the board, soldered to the other side.

It's very obvious to anyone "in the know" that you didn't look, because if you did, you'd know that there are a lot of packages smaller than 21.5 mm. Smallest 1 mm pitch package is Spartan-7 in BGA-196 package, which is 15x15 mm and has 100 user IO pins, which is more than QFP100 and even QFP144. Not to mention that BGA packages provide far superior signal integrity for high-speed signals. Heck, take a look at the project linked in my signature - it uses that very S7 device, and drives 128Mx16 DDR2 memory, while still leaving almost entire IO bank (50 pins) for other connections. There are 13x13 packages with 0.8 mm pitch, which again can be broken out on cheap JLCPBC process.

You seem to be getting angry about this.  As I have said repeatedly, the devices from Xilinx and Altera are either not low cost manufacturing friendly or just not LOW COST!  The Spartan-7 chip you are talking about is $15 compared to $4 from Gowin!!!  Not much comparison there. 

Clearly the designs you build are very different from the ones I typically build.  Please don't think that your needs are everyone's needs.

If you want the absolute smallest package, take a look at Artix-7 in CP236/CP238 packages (10x10 mm). They are nominally 0.5 mm pitch, but their pinout (see attached pictures) is such that you can easily fully break it out on just two signal layers. You will need to "massage" the footprint a bit to get it to work with JLCPCB's 3.5 mil limit (using some other fab like WellPCB which can do 3 mil will make things much easier), but you can get up to 50K logic cells, and - the coolest part - 2 multi-gigabit transceivers capable of reaching up to 6.25 Gpbs each (depending on speed grade).

I don't need 50 K whatever a logic cell is (a Xilinx marketing term with no hardware connection) or multi-gigabit transceivers.  The Artix-7 line starts at $25 for 8 KLUTs!!!  Compared to the Gowin parts at $4 for 9 kLUTs it's no contest!!!

It was actually Lattice that brought down the price of the high speed SERDES in FPGAs.  X and A were charging big bucks for their parts with SERDES and Lattice came out with a low cost line with them.  Then everyone else had to follow suit. 

[NorthGuy]

Not sure what you are trying to say.  The carry chain only handles the carry... hence the name.  Every adder and counter uses 1 LUT per bit whether they are 4 input or 6 input LUTs.

No. An adder requires two LUTs per bit - one LUT generates the result for this bit, the other LUT generates carry out.

You can, however, save some LUTs by combining consecutive bits. This way, to handle two consecutive bits you need three 5-input LUTs (4 bits from the operands and carry in). Since Xilinx's 6-input LUT can be reconfigured as two 5-input LUTs, you only need two LUTs to cover two consecutive bits for the adder. This is compared to two LUTs per bit if you only have 4-input LUTs. This is 2x savings even without carry chains.

If you use carry chains to calculate carry, you can completely eliminate the LUT which generates carry out. In the simplest form, you would have one 6-input LUT per bit which would be reconfigured as 2 5-input LUTs to produce the "generate" and "propagate" signals for the carry chain. So, it's one LUT per bit with 3 free inputs. In contrast, with 4-input LUTs, you would need two LUTs per bit, and only one free input.

What difference the free inputs in the LUTs make? A very big one. Because there's other logic. Say, you may want to mux what you're adding, or you may reset your counter to predefined values based on a number of conditions. You just feed extra signals to the free inputs of your LUTs and they take care of muxing, resetting etc. So, all or part of your logic gets absorbed by these LUTs.

What if you don't have free inputs in the LUTs? You need to designate other LUTs to all the muxing and resetting. Worse yet, these new LUTs will form a separate logic layer. Now you either need to pipeline or to take 40% speed hit because you now have two logic layers instead of one.

Are you suggesting they now have dedicated adder logic entirely separate from the LUTs to process the entire adder function?

This too. They have DSP blocks which do exactly this.

[gnuarm]

Not sure what you are trying to say.  The carry chain only handles the carry... hence the name.  Every adder and counter uses 1 LUT per bit whether they are 4 input or 6 input LUTs.

No. An adder requires two LUTs per bit - one LUT generates the result for this bit, the other LUT generates carry out.

I thought we were talking about FPGAs.  i don't know of any FPGA that doesn't provide logic to allow the carry chain to be optimized in some manner resulting in using 1 LUT per bit of adder/counter.  What parts are you talking about???

You can, however, save some LUTs by combining consecutive bits. This way, to handle two consecutive bits you need three 5-input LUTs (4 bits from the operands and carry in). Since Xilinx's 6-input LUT can be reconfigured as two 5-input LUTs, you only need two LUTs to cover two consecutive bits for the adder. This is compared to two LUTs per bit if you only have 4-input LUTs. This is 2x savings even without carry chains.

You mean it uses one LUT for each bit just like every other FPGA???  Ok, great... but zero advantage.

If you use carry chains to calculate carry, you can completely eliminate the LUT which generates carry out. In the simplest form, you would have one 6-input LUT per bit which would be reconfigured as 2 5-input LUTs to produce the "generate" and "propagate" signals for the carry chain. So, it's one LUT per bit with 3 free inputs. In contrast, with 4-input LUTs, you would need two LUTs per bit, and only one free input.

I don't know if you are speaking from knowledge of how this is done in the Xilinx 6 LUT parts or are speculating.  The whole thing above ignoring the carry chain applies to exactly zero FPGAs I am aware of except for one device Atmel made way back when.

What difference the free inputs in the LUTs make? A very big one. Because there's other logic. Say, you may want to mux what you're adding, or you may reset your counter to predefined values based on a number of conditions. You just feed extra signals to the free inputs of your LUTs and they take care of muxing, resetting etc. So, all or part of your logic gets absorbed by these LUTs.

What if you don't have free inputs in the LUTs? You need to designate other LUTs to all the muxing and resetting. Worse yet, these new LUTs will form a separate logic layer. Now you either need to pipeline or to take 40% speed hit because you now have two logic layers instead of one.

Yes, free inputs are useful *if* you have a use for them.  That's the point.  They initially used 4 input LUTs, not because there is an inherent restriction to 4 LUTs, but because they were found to give the optimal utility of logic and routing. 

The point is there is no basis for saying devices with 6 LUTs are X amount better than 4 LUTs.  Every design is different and has different requirements.  That's why some devices have 1 FF per LUT and others have fewer.  I believe in the case of these Xilinx parts (or at least some I've looked at) they have two registers per 6 LUT.  I suppose splitting LUTs let you use them more effectively. 

That doesn't change the fact that Xilinx has been using the "Logic Cell" equivalent number since long before they had 6 LUTs.  It's a marketing number with no real basis. 

Are you suggesting they now have dedicated adder logic entirely separate from the LUTs to process the entire adder function?

This too. They have DSP blocks which do exactly this.

We seem to be drifting far from any meaningful discussion.   If you like Xilinx that's fine.  I don't know why you are pushing them so hard.  The Gowin devices are what work for me in most of my designs.  They are exactly the company I have been hoping would appear for some time now.  It is very clear that Xilinx and Altera have no interest in the very high volume commodity market for smaller devices (smaller both in gate count and in package size).  Lattice has been working that ground for a while now and Gowin is hitting it hard.  If that's an area you don't work in, fine.  But it is exactly where I want to be.   

[NorthGuy]

If you like Xilinx that's fine.  I don't know why you are pushing them so hard.

I'm not trying to push anything. I'm trying to answer your questions. Why people like Xilinx, why 6-input LUTs are better than 4-input, how carry chain works, dedicated adders etc. etc. Looks like you know all this by yourself. But, for some reason, you don't let your knowledge to affect your evaluation of GOWIN products.

My original point, which I'm trying to carry, is that the GOWIN FPGA are not that cheap as you're trying to portray. Because of 2 factors:

- 6-input LUTs are substantially better than 4-input LUTs
- You're comparing DigiKey's prices for Xilinx chips to discounted prices for GOWIN

This is nothing wrong if GOWIN suits your needs. But it doesn't mean they're going to take over the world as you're trying to describe:

Only 4 or 9 kLUT and a price tag of $3 or $4.  Once people get over their aversion to using a product from a new company these parts will take off like a rocket!

[langwadt]

If you have an adder, it only needs a 4 input LUT per bit.  Unless you have other logic to combine with that the other 3/4 of the LUT is wasted as an example.  A counter only needs 3 inputs, etc.

Xilinx has built-in carry chains for adders and counters (4 carry cells in every CLB), or DSP blocks if you need long or fast. These things don't even count in the number of LUTs.

Not sure what you are trying to say.  The carry chain only handles the carry... hence the name.  Every adder and counter uses 1 LUT per bit whether they are 4 input or 6 input LUTs.  Are you suggesting they now have dedicated adder logic entirely separate from the LUTs to process the entire adder function?

I don't like BGAs because of the hassle of the ultra fine trace/space and vias required.

You can fan out 1mm pitch BGA with 6-8 mil traces. Doesn't sound like ultra fine to me.

We aren't talking about 1 mm pitch BGAs.  The parts available for the small Gowin devices are 0.5 or 0.4 mm pitch.  The whole point is to have a very small package to support mobile applications which is the high volume market for low end devices just like the 1,000 pin behemoths are for the high dollar/high profit telecomms and server markets which is where X and A are aligned.
Even with 1 mm pitch BGAs, you can't use a reasonable drill/via size like 10 mil/24 mil.  I don't recall how small the vias have to be, but the bottom line is there are no BGA packages that allow the cheapest boards or part costs.  If nothing else the 1 mm pitch BGAs are high pin counts with correspondingly higher prices because of the longer testing time. 

xilinx recommended pcb rules for ft256 1mm pitch is 12/23 mil via hole/size and 5/5 mill trace space, that is well with in JLCPCB dirt cheap capabilities

you can get  XC6SLX16-2FTG256C (14500 logic cells) for ~$5 on LCSC

[gnuarm]

If you like Xilinx that's fine.  I don't know why you are pushing them so hard.

I'm not trying to push anything. I'm trying to answer your questions. Why people like Xilinx, why 6-input LUTs are better than 4-input, how carry chain works, dedicated adders etc. etc. Looks like you know all this by yourself. But, for some reason, you don't let your knowledge to affect your evaluation of GOWIN products.

Wow!  You really insist on making this personal?! 

I have stated very, very clearly why I don't use Xilinx products on my boards.  Price is only a secondary issue.  The biggest one is package.  I don't recall who it was posted some misleading info on using BGAs in place of packages compatible with the low cost board fabrication I use.  Such devices all either require very small vias or have such a high I/O count they raise the price considerably where price does become a problem. 

No, you don't need to explain basic carry chains to me.  I believe it was you who started off talking about FPGAs needing two LUTs per bit for adders ignoring that virtually all FPGAs have adder logic built into every basic cell. 

Why are you going on like this?  Can we have a reasonable discussion?

My original point, which I'm trying to carry, is that the GOWIN FPGA are not that cheap as you're trying to portray. Because of 2 factors:

- 6-input LUTs are substantially better than 4-input LUTs
- You're comparing DigiKey's prices for Xilinx chips to discounted prices for GOWIN

I haven't heard any prices anyone else is getting from Xilinx...  I haven't asked for a quote because they don't make a part that will suit my boards.  Do you have such prices?  If not, please stop complaining that I'm comparing bogus prices.  Go to the Edge web page.  There you will find distributor prices very similar to what I've quoted.  Digikey doesn't carry them, so don't ask for that.

This is nothing wrong if GOWIN suits your needs. But it doesn't mean they're going to take over the world as you're trying to describe:

Only 4 or 9 kLUT and a price tag of $3 or $4.  Once people get over their aversion to using a product from a new company these parts will take off like a rocket!

LOL!  Ok, this trolley has reached city center in loony town.  Everybody off! 

I say the company will do well and you interpret that as my claiming Gowin will "take over the world". 

Please read my posts rather than just reacting to them.  Please. 

I said a couple of times that X and A are focused on the high end of the market where the telecomms pay big bucks for the biggest and fastest chips.  I know this because that is what Xilinx representatives have stated publicly in open forums.  That leaves the low prices, small packages end of the market to the innovative companies like Gowin.  Lattice has been a proponent of this segment and has some product lines that are doing well in it.  Gowin is doing an even better job and I expect them to be growing rapidly. 

If you think "growing rapidly" means they will take over the world, then you must have a pretty poor opinion of Xilinx's future. 

BTW, I bought a block of Xilinx stock a few months back and it is doing very well.  So obviously I'm neither forecasting nor hoping for Xilinx's doom.   I'd like to hold onto this for the gains to become long term capital gains, but the market may be heading for a tumble.  Pretty much anything can spook the herd at this point. 

[gnuarm]

If you have an adder, it only needs a 4 input LUT per bit.  Unless you have other logic to combine with that the other 3/4 of the LUT is wasted as an example.  A counter only needs 3 inputs, etc.

Xilinx has built-in carry chains for adders and counters (4 carry cells in every CLB), or DSP blocks if you need long or fast. These things don't even count in the number of LUTs.

Not sure what you are trying to say.  The carry chain only handles the carry... hence the name.  Every adder and counter uses 1 LUT per bit whether they are 4 input or 6 input LUTs.  Are you suggesting they now have dedicated adder logic entirely separate from the LUTs to process the entire adder function?

I don't like BGAs because of the hassle of the ultra fine trace/space and vias required.

You can fan out 1mm pitch BGA with 6-8 mil traces. Doesn't sound like ultra fine to me.

We aren't talking about 1 mm pitch BGAs.  The parts available for the small Gowin devices are 0.5 or 0.4 mm pitch.  The whole point is to have a very small package to support mobile applications which is the high volume market for low end devices just like the 1,000 pin behemoths are for the high dollar/high profit telecomms and server markets which is where X and A are aligned.
Even with 1 mm pitch BGAs, you can't use a reasonable drill/via size like 10 mil/24 mil.  I don't recall how small the vias have to be, but the bottom line is there are no BGA packages that allow the cheapest boards or part costs.  If nothing else the 1 mm pitch BGAs are high pin counts with correspondingly higher prices because of the longer testing time. 

xilinx recommended pcb rules for ft256 1mm pitch is 12/23 mil via hole/size and 5/5 mill trace space, that is well with in JLCPCB dirt cheap capabilities

you can get  XC6SLX16-2FTG256C (14500 logic cells) for ~$5 on LCSC

That's an interesting price.  I wonder why Digikey and Mouser and all the authorized distributors list prices five times that?  I don't know much about LCSC.  Do they buy from Xilinx do you know? 

Do you have a link for the Xilinx layout recommendations on using their BGAs?  I recall years ago I had a document that gave good info on that, but I haven't tried to track it down since then.  Or a document number should let me find it in a search.  At under $5 in quantity that would be a very useful chip and I'd like to investigate that. 

But I can't buy from second tier vendors.  My customers are large corporations that require all manner of certificates, RoHS, Reach, etc.  I don't see a sign that LCSC offers any of this.  Still, for some projects that's a very interesting price.  Thanks for the heads up.

[NorthGuy]

Do you have a link for the Xilinx layout recommendations on using their BGAs?  I recall years ago I had a document that gave good info on that, but I haven't tried to track it down since then.  Or a document number should let me find it in a search.

ug393 for Spartan-6, ug483 for 7-series

At under $5 in quantity that would be a very useful chip and I'd like to investigate that. 

See, when the price is right, the BGA/LUT considerations are suddenly not as important any more

[ejeffrey]

That's an interesting price.  I wonder why Digikey and Mouser and all the authorized distributors list prices five times that?  I don't know much about LCSC.  Do they buy from Xilinx do you know? 

The digikey/mouser prices are not what you pay for anything other than prototypes, especially with FPGAs.  You can see this because you can order 3rd party dev boards or SoMs for less than the digikey price of the bare chip.  They aren't selling those at a loss and the rest of the materials have non-zero cost.  We asked Intel for a quote for some mid-range Altera FPGAs and even in relatively small quantities got them for 1/3 the price.  IIRC, Intel didn't even sell them to us directly, the order was fulfilled by Arrow at 1/3 the list price.  These are much more expensive FPGAs than you are talking about so maybe you would need a larger quantity to get such a discount.  I don't know how LCSC gets their parts but it is not at all unbelievable that a Chinese distributor could have genuine parts at << the digikey price. 

[gnuarm]

Do you have a link for the Xilinx layout recommendations on using their BGAs?  I recall years ago I had a document that gave good info on that, but I haven't tried to track it down since then.  Or a document number should let me find it in a search.

ug393 for Spartan-6, ug483 for 7-series

At under $5 in quantity that would be a very useful chip and I'd like to investigate that. 

See, when the price is right, the BGA/LUT considerations are suddenly not as important any more

Thanks for the document number.  I don't  understand your statement about the package.  Of course the package is important.  The 256 pin package is the only possibly usable BGA in the Xilinx line up on my board because it fits (barely) and does not require the ultra small vias the other packages do. 

Even with that, it will be much harder to route this BGA than a 100 pin QFP because the vias are locked in place, with no option for moving them around to facilitate routing.  Fortunately in an FPGA there are not many I/Os that are fixed and the FPGA itself can be the routing resource to ease problems on the PCB.  So in the end it is still unlikely I will use the Xilinx part, but it is one of the choices I can consider. 

One of the problems I've had with pricing is that the quote is provided to me as the designing company.  I've never had a sales person explain how they can assure I will get that price through a contract manufacturer 10 years from now.  The board I have made millions of dollars on has been in production for over 12 years.  If I redesign it I will be setting up a means to manufacture it for another 12 years and need consistent pricing.

[gnuarm]

That's an interesting price.  I wonder why Digikey and Mouser and all the authorized distributors list prices five times that?  I don't know much about LCSC.  Do they buy from Xilinx do you know? 

The digikey/mouser prices are not what you pay for anything other than prototypes, especially with FPGAs.  You can see this because you can order 3rd party dev boards or SoMs for less than the digikey price of the bare chip.  They aren't selling those at a loss and the rest of the materials have non-zero cost.  We asked Intel for a quote for some mid-range Altera FPGAs and even in relatively small quantities got them for 1/3 the price.  IIRC, Intel didn't even sell them to us directly, the order was fulfilled by Arrow at 1/3 the list price.  These are much more expensive FPGAs than you are talking about so maybe you would need a larger quantity to get such a discount.  I don't know how LCSC gets their parts but it is not at all unbelievable that a Chinese distributor could have genuine parts at << the digikey price.

Of course Digikey 1 off prices are high.  My point is they are much higher for FPGAs than other devices and you have to negotiate with the manufacturer just to get an idea of pricing.  So when I see prices at Digikey or Mouser that are three times what I find for another product at another distributor, I assume they are not competitive in that race.

I don't know that LCSC is a Xilinx distributor.  Xilinx lists distributors on their web site and they don't list LCSC, hence my concern.   I don't want to use parts in my products that are grey market, potentially counterfeit.  So a $15 Xilinx part that is only listed at $5 on one Chinese web site, no, I'm not going to consider that a valid price until I find I can get a similar price through 1st tier distribution.

[langwadt]

One of the problems I've had with pricing is that the quote is provided to me as the designing company.  I've never had a sales person explain how they can assure I will get that price through a contract manufacturer 10 years from now.  The board I have made millions of dollars on has been in production for over 12 years.  If I redesign it I will be setting up a means to manufacture it for another 12 years and need consistent pricing.

they only way I see that you can get consistent pricing over such a long period is to buy all you need now, or someone else to buy all you need and sell it to you as you need them for a greatly increased price.

[gnuarm]

One of the problems I've had with pricing is that the quote is provided to me as the designing company.  I've never had a sales person explain how they can assure I will get that price through a contract manufacturer 10 years from now.  The board I have made millions of dollars on has been in production for over 12 years.  If I redesign it I will be setting up a means to manufacture it for another 12 years and need consistent pricing.

they only way I see that you can get consistent pricing over such a long period is to buy all you need now, or someone else to buy all you need and sell it to you as you need them for a greatly increased price.

That is simply not correct.  I have worked at companies where they get a quote from an FPGA maker and that price is honored for the life of the product, at least until the part is EOL.  Once they hand it off to Richardson all bets are off.   But you can still buy Spartan 3 devices from the 2003 time frame. 

My problem is that when I change contract manufacturers they have to jump through a bunch of hoops to connect my quote with the production run to get that price.  I typically don't have the time to mess with that.  The quote is connected to the product it was quoted for.  They don't want to give you a blanket quote to cover every app.  Sales is VERY motivated to push the newest line, much more so than just getting a design win.  So they don't want you to continue using their old product in your new designs.  They will give great quotes on the new line to get the wins.  Other lines get much less aggressive quotes.

[langwadt]

One of the problems I've had with pricing is that the quote is provided to me as the designing company.  I've never had a sales person explain how they can assure I will get that price through a contract manufacturer 10 years from now.  The board I have made millions of dollars on has been in production for over 12 years.  If I redesign it I will be setting up a means to manufacture it for another 12 years and need consistent pricing.

they only way I see that you can get consistent pricing over such a long period is to buy all you need now, or someone else to buy all you need and sell it to you as you need them for a greatly increased price.

That is simply not correct.  I have worked at companies where they get a quote from an FPGA maker and that price is honored for the life of the product, at least until the part is EOL.  Once they hand it off to Richardson all bets are off.   But you can still buy Spartan 3 devices from the 2003 time frame. 

My problem is that when I change contract manufacturers they have to jump through a bunch of hoops to connect my quote with the production run to get that price.  I typically don't have the time to mess with that.  The quote is connected to the product it was quoted for.  They don't want to give you a blanket quote to cover every app.  Sales is VERY motivated to push the newest line, much more so than just getting a design win.  So they don't want you to continue using their old product in your new designs.  They will give great quotes on the new line to get the wins.  Other lines get much less aggressive quotes.

so is that "aggressive quote" for a number of parts you buy now, or for any number of parts you may or may not buy over the next 12 years?

[gnuarm]

One of the problems I've had with pricing is that the quote is provided to me as the designing company.  I've never had a sales person explain how they can assure I will get that price through a contract manufacturer 10 years from now.  The board I have made millions of dollars on has been in production for over 12 years.  If I redesign it I will be setting up a means to manufacture it for another 12 years and need consistent pricing.

they only way I see that you can get consistent pricing over such a long period is to buy all you need now, or someone else to buy all you need and sell it to you as you need them for a greatly increased price.

That is simply not correct.  I have worked at companies where they get a quote from an FPGA maker and that price is honored for the life of the product, at least until the part is EOL.  Once they hand it off to Richardson all bets are off.   But you can still buy Spartan 3 devices from the 2003 time frame. 

My problem is that when I change contract manufacturers they have to jump through a bunch of hoops to connect my quote with the production run to get that price.  I typically don't have the time to mess with that.  The quote is connected to the product it was quoted for.  They don't want to give you a blanket quote to cover every app.  Sales is VERY motivated to push the newest line, much more so than just getting a design win.  So they don't want you to continue using their old product in your new designs.  They will give great quotes on the new line to get the wins.  Other lines get much less aggressive quotes.

so is that "aggressive quote" for a number of parts you buy now, or for any number of parts you may or may not buy over the next 12 years?

It is for every part bought for the product/program the quote was for.   I said that.  The vendor points you to the distributor with whom they provide the quote with.  I wasn't in purchasing, but I do recall my boss telling me they needed to be honest with them about which parts were being bought for which product line. 

In my business I got quotes for a few things I built, but when I started letting the CMs do the ordering they no longer honored the quotes they gave me.  They said they would have to look into it, but with the CM being in a different sales territory it required coordination with the sales  people in that area and I didn't have the time to mess with it.  I had to get product built.   So I gave up on that.  With the Gowin quotes I will buy the parts myself for the first few runs and get the pricing worked out with the CM after that.   At the prices they are quoting it will be worth it. 

I was looking at the jlcpcb capabilities and they have a lot of disconnects.  It is hard to tell what they really offer on the low cost service.  I used the chat and several times when I asked which set of specs they worked to (when there were conflicts) they said they would "adjust" the features to suit their process.  So at this point I don't know exactly what their capabilities really are. 

For example, on a 6 layer board they say
Min. drill size is 0.20mm
minimum via diameter is 0.45mm
annular ring size will be enlarged to 0.15mm in production
with a 0.2 mm hole and 0.15 mm annular ring that gives 0.5 mm via pad, not 0.45 mm. 

On the price sheet they talk about 0.45 mm via diameter or for more money they can do 0.2 mm holes and 0.4 mm via diameter.  This was when the guy in chat said they would round up the drill to what their process uses. 

Still, that might be ok.  The board I may modify uses 10 mil drill and 24 mil via pads.  As long as they assure the board meet IPC class II specs they can use whatever drill size they want.  I found where they have REACH, RoHS and other certificates, but I don't see any mention of IPC class ratings. 

I dug into the clearance section of their capabilities and I just can't crack the code.  They use the same drawing for three different specs, none off which are clear.  I really can't figure out just what I will get from them.  Too many mentions of XYZ "will be enlarged in production".

Do you use them for anything other than prototypes or one offs?

[NorthGuy]

Too many mentions of XYZ "will be enlarged in production".

If they say they're going to enlarge something, they will.

Here's an example.

In the design these were perfectly round 0.65 mm pads with 0.4 mm holes, which violated their 0.7 mm minimum size for pads. The design also violated their hole-to-hole rule of 0.5 mm (it was 0.4 mm since it's 0.8 mm between holes).

They enlarged the pads to 0.72 mm. This made the pads too close to each other, so they removed their edges leaving less than 0.1 mm between pads. This hugely violates their clearance rule. They also made holes slightly large but within tolerances - from 0.4 mm to 0.45 mm. This further violated the hole-to-hole rule, as it became 0.35 mm (comared to allowed 0.5 mm). But these violations didn't make any difference.

So, I think you should expect that they will enlarge/fix what they can even if this causes violations elsewhere. They will not fix what they cannot fix, and chances are that it'll come out Ok. Of course, if it doesn't come out Ok, the responsibility is yours.

[gnuarm]

Too many mentions of XYZ "will be enlarged in production".

If they say they're going to enlarge something, they will.

Here's an example.

In the design these were perfectly round 0.65 mm pads with 0.4 mm holes, which violated their 0.7 mm minimum size for pads. The design also violated their hole-to-hole rule of 0.5 mm (it was 0.4 mm since it's 0.8 mm between holes).

They enlarged the pads to 0.72 mm. This made the pads too close to each other, so they removed their edges leaving less than 0.1 mm between pads. This hugely violates their clearance rule. They also made holes slightly large but within tolerances - from 0.4 mm to 0.45 mm. This further violated the hole-to-hole rule, as it became 0.35 mm (comared to allowed 0.5 mm). But these violations didn't make any difference.

So, I think you should expect that they will enlarge/fix what they can even if this causes violations elsewhere. They will not fix what they cannot fix, and chances are that it'll come out Ok. Of course, if it doesn't come out Ok, the responsibility is yours.

That's my point.  While their capabilities provide for using 1.0 mm pitch BGAs potentially, their standard capabilities don't look like they will allow the use of 0.8 mm pitch BGAs.  Of course the devil is in the details and I find their rules to be too unclear to know exactly what they will and won't provide in the end.  The via/drill capability is a perfect example.  For the lower cost option they only provide a via size number and not a drill size.  So if I ask for a 10 mil (0.254 mm) drill and a 24 mil via pad (0.6 mm), what will I end up with?  Don't know.  If they take responsibility for giving me usable boards, fine.  If they churn out whatever they feel like after applying their ill defined capability rules, I can get very inexpensive dross that I can't use.  Then even inexpensive boards are expensive.

I expect I will only use JLC for even less demanding boards than I could get built most anywhere 12 years ago and find someone else for the boards I use in production.  Actually, I use a contract manufacturer who has their favorite board house as most do.  So I would only use an outfit like JLC for prototypes.  I'm really happy with this CM.  They not only build the boards, they test them and will drop ship to my customer.  Once they get rolling on a production run, I can just send the bills to my customer and wait for the checks.