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

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