Good intros to FPGAs?

[nctnico]

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

So very wrong! A good engineer will choose a part that leads to the lowest overall cost of the project! Bonus points for choosing a part that allows for a sensible extension of features for a product. Labour is super expensive and swamps production costs for many of projects even if the number of units runs into thousands. Unfortunately many people overlook this because they don't have a good grasp on how much time they will spend on coding. Penny wise, pound foolish.

[free_electron]

two schools of thought
- write it hardware agnostic, let the compiler figure it out. it should run anywhere...
- write it tightly coupled to the hardware to squeeze every nanosecond out of it. hand place and route.

both are a path to failure.
one path leads to bloated hardware because you don't use the capabilities of the machine , the other leads to bloated codebase and a waste of time doing things the machine can do (synthesizer)

USE THE TOOLS ! don't spend time doing things the machine can do. fail fast and early. work in modules. instantiate modules. draw a schematic if you want to. nobody limits you in what you are allowed to do. the tools all allow for schematic entry and hdl and/or a mixture.
i hate instantiating submodules. i can never remember the syntax and if i change signal orders or add signals it means more typing. So my toplevel is always a schematic. nice drawing showing the relation between blocks and the i/o pins/ click on a block and there is the HDL (in my case verilog2005). Easy to maintain , easy to write, easy to debug. i typically reserve a number of pins as debug channel. if i need to see internal signals just wire them to the debug channel. i sometimes drop in a big multiplexer to sniff more.

[tggzzz]

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

So very wrong! A good engineer will choose a part that leads to the lowest overall cost of the project! Bonus points for choosing a part that allows for a sensible extension of features for a product. Labour is super expensive and swamps production costs for many of projects even if the number of units runs into thousands. Unfortunately many people overlook this because they don't have a good grasp on how much time they will spend on coding. Penny wise, pound foolish.

I presume you agree with all the other points I made. If not then it looks like you at simply finding a way, any way, to appear to win a discussion.

[tggzzz]

two schools of thought
- write it hardware agnostic, let the compiler figure it out. it should run anywhere...
- write it tightly coupled to the hardware to squeeze every nanosecond out of it. hand place and route.

both are a path to failure.
one path leads to bloated hardware because you don't use the capabilities of the machine , the other leads to bloated codebase and a waste of time doing things the machine can do (synthesizer

I don't disagree.

One reason for articulating extremes is to examine where things fail. As Arthur C Clarke put it, the only way to find the limits of the possible is to go beyond them into the impossible.

Another rs to clarify essential points of a discussion that might be more generally applicable. To achieve that, it is often necessary to avoid discussing details that are only applicable in one situation.

Of course real life projects and situations are never black a and white; they are always shades of grey.

USE THE TOOLS ! don't spend time doing things the machine can do. fail fast and early. work in modules. instantiate modules. draw a schematic if you want to. nobody limits you in what you are allowed to do. the tools all allow for schematic entry and hdl and/or a mixture.
i hate instantiating submodules. i can never remember the syntax and if i change signal orders or add signals it means more typing. So my toplevel is always a schematic. nice drawing showing the relation between blocks and the i/o pins/ click on a block and there is the HDL (in my case verilog2005). Easy to maintain , easy to write, easy to debug. i typically reserve a number of pins as debug channel. if i need to see internal signals just wire them to the debug channel. i sometimes drop in a big multiplexer to sniff more.

Yes, that tends to aid a key objective: simple clarity.

[hamster_nz]

Unless you are writing purely structural HDL and are using only the vendor's primitives then all your HDL code is inferred. It's just that in some cases what will be inferred is more obvious (such as an counter) than in others (an array used as a dual-port memory).

And that's before the tools optimize the design by extracting common logic, removing inaccessible/unused registers, constant propagation, duplicating registers or logic to reduce fan-out, inserting clock buffers and so on.

[nctnico]

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

So very wrong! A good engineer will choose a part that leads to the lowest overall cost of the project! Bonus points for choosing a part that allows for a sensible extension of features for a product. Labour is super expensive and swamps production costs for many of projects even if the number of units runs into thousands. Unfortunately many people overlook this because they don't have a good grasp on how much time they will spend on coding. Penny wise, pound foolish.

I presume you agree with all the other points I made. If not then it looks like you at simply finding a way, any way, to appear to win a discussion.

No, I just picked this particular piece because it is something that people tend to trip over and end up wasting lots of time and money.

And why would discussions need to be won somehow? What benefit would that bring?

[rstofer]

FWIW, there is no schematic entry capability in Xilinx Vivado.  It was a feature of the now obsolete ISE tools.

Another feature of ISE is the ability to generate a template for instantiating components.  No guessing, no signals to forget, etc.  There is an add-on for Vivado that provides a similar way of doing the same thing.  In my view, the ISE approach is better but ISE is history.

[gnuarm]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design.  I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

[tggzzz]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

[Neomys Sapiens]

FPGA-Based Embedded System Developer's Guide   A. Arockia Bazil Raj   CRC Press      2018

EEDigital            Applications of Field-Programmable Gate Arrays in Scientific Research   Hartmut F.-W. Sadrozinski and Jinyuan Wu   CRC Press      2011

Principles and Structures of FPGAs   Hideharu Amano (Ed.)   Springer      2018

Engineering Applications of FPGAs - Chaotic Systems, Artificial Neural Networks, Random Number Generators, and Secure Communication Systems   Esteban Tlelo-Cuautle, J. de Jesus Rangel-Magdaleno, L.G. de la Fraga   Springer      2016

Fault-Tolerance Techniques for SRAM-based FPGAs   F.L.Kastensmidt, L.Carro, R.Reis   Springer      2006

Design Recipes for FPGAs   Peter R. Wilson   Newnes      2006

The Design Warrior's Guide to FPGAs   C. Maxfield   Newnes      2004

[SiliconWizard]

As an intro, unless you are already familiar with the concepts, I'd suggest starting with more fundamental concepts before even touching any FPGA.
Start with logic and basic digital electronics. Someone having a hard time with logic equations and sequential logic will really struggle to do anything useful and understand what's going on with FPGAs.

[gnuarm]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

Yes, but a properly constructed design will easily meet timing.  The situation you described is clearly a poorly constructed design that the place and route had trouble with.  Most likely, the code had some extraneous logic that was not intended, which was slowing down the timing.  I've seen that, where I expected a simple adder to be inferred, but I screwed up the carry and it had to toss a whole other adder in to do what my code asked it to do.  Once I identified the culprit, it was an easy fix and no layout tools required.

[free_electron]

Verilog for synthesis by Bhasker.

lots of books blabber about Verilog (or vhdl) but 70% of it isn't even synthesizable, it's simulation only.
i never write verilog testbenches. i draw a waveform exactly of what i expect to go in, corner cases and all and verify that it reacts correctly at module level.

The problem with verilog testbenches is that it is very hard to describe the corners and you have the tendency to write an "ideal" testbench. It's faster to just draw the input stimuli and look at the output. Plus you can cross correlate with the logic analyser if it fails on bench. you can do a testbench at top level but at module level i prefer waveform.

There is another book , letter size ( A4 ), light blue in color  HDL chip design By Douglas Smith. This was handed out by synopsys when you did their tool training. Out of print. It handles both verilog and vhdl. The specialty of this one is that it shows both Verilog and VHDL  and a flow diagram and the actual schematic of what the stuff synthesizes to. It's over 500 pages.
Finding it new is like ridiculously expensive... you can find used on amazon or ebay

[tggzzz]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

Yes, but a properly constructed design will easily meet timing. 

Rubbish.

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

The situation you described is clearly a poorly constructed design that the place and route had trouble with.  Most likely, the code had some extraneous logic that was not intended, which was slowing down the timing.  I've seen that, where I expected a simple adder to be inferred, but I screwed up the carry and it had to toss a whole other adder in to do what my code asked it to do.  Once I identified the culprit, it was an easy fix and no layout tools required.

Not in that case.

[free_electron]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

[tggzzz]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

[free_electron]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.
and yes , i'm familiar with that 1680. I have a 1682ad and a 1690A and a 16801A and a 16902A with several 167xx and 169xx series boards that use large xilinx chips. But again ,low volume. Open up a larger volume HPAK oscilloscope and it's asic. Those fpga's are memory mappers, basically fancy dram controllers. The real guts is under the heatsinks. That's where triggering happens.
The previous generation asics are in the LogicWave (which has a USB port but they never got it working... so you are stuck with a EPP printerport interface) and the older 1660 series.

There is a point where the overhead of a FPGA becomes too much. Speed is impaired because of lack in routing channels and die area. memory is impaired and the chip becomes too expensive.

the FPGA code is a static file. they just alter registers. they don't alter the bitstream.  there is ways to hack those cards and make the machine loader believe it has a different board and load a bitstream with more options. many of the 169xx series boards are identical apart from the id code flashed in them. they are actually 16755 or 16754 with different bitstream

[SiliconWizard]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.

Except if you expect regular changes/improvements. FPGAs are a no-brainer for this, while you can forget about it with ASICs.

[free_electron]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.

Except if you expect regular changes/improvements. FPGAs are a no-brainer for this, while you can forget about it with ASICs.

that's why fpga are used to prototype stuff !.

[tggzzz]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications.

Your points, position, and arguments mutate every time counterexamples show them to be lacking. That's not unreasonable, but beware the "no true Scotsman fallacy".

Nobody in his right mind will use fpga for large volume. asic is cheaper.

Nobody in their right mind would even consider that an FPGA is suitable in all cases.

and yes , i'm familiar with that 1680. I have a 1682ad and a 1690A and a 16801A and a 16902A with several 167xx and 169xx series boards that use large xilinx chips. But again ,low volume. Open up a larger volume HPAK oscilloscope and it's asic. Those fpga's are memory mappers, basically fancy dram controllers. The real guts is under the heatsinks. That's where triggering happens.
The previous generation asics are in the LogicWave (which has a USB port but they never got it working... so you are stuck with a EPP printerport interface) and the older 1660 series.

There is a point where the overhead of a FPGA becomes too much. Speed is impaired because of lack in routing channels and die area. memory is impaired and the chip becomes too expensive.

So FPGAs aren't the fastest devices and have their own limitations? I encourage you to submit that remarkable revelation to the IEEE so it can be published in a learned journal.

Incidentally, such internal limitations are why it can be beneficial to nail down specific functions in specific LUTs.

the FPGA code is a static file. they just alter registers. they don't alter the bitstream.  there is ways to hack those cards and make the machine loader believe it has a different board and load a bitstream with more options. many of the 169xx series boards are identical apart from the id code flashed in them. they are actually 16755 or 16754 with different bitstream

Maybe; I haven't examined the design in that much detail.

But Xilinx devices can have some parts reloaded with different bitstreams while the other parts continue to operate. That's very powerful, and could have very interesting uses.

[gnuarm]

Verilog for synthesis by Bhasker.

lots of books blabber about Verilog (or vhdl) but 70% of it isn't even synthesizable, it's simulation only.
i never write verilog testbenches. i draw a waveform exactly of what i expect to go in, corner cases and all and verify that it reacts correctly at module level.

Not as a put down or anything, but if you are "drawing" waveforms, you must have some simple testbenches.  I often simulate stuff that has thousands of timing points, often with dozens of inputs.  It is so much easier to program that up than it would be to define timing points, especially when there is feedback, interaction.

One of the things I do when testing the completed design, is when it's part of a communications link, for example, two instances connect through a "mock" network.  The only issue with that is getting the various blocks "tuned" or "aligned" so it doesn't take half a million clocks to synchronize.

The problem with verilog testbenches is that it is very hard to describe the corners and you have the tendency to write an "ideal" testbench. It's faster to just draw the input stimuli and look at the output. Plus you can cross correlate with the logic analyser if it fails on bench. you can do a testbench at top level but at module level i prefer waveform.

What sorts of designs do you do that the digital interface has corners to test?  I'm testing functionality, which is either it works, or it doesn't work.  Maybe I'm not understanding what's going on.

There is another book , letter size ( A4 ), light blue in color  HDL chip design By Douglas Smith. This was handed out by synopsys when you did their tool training. Out of print. It handles both verilog and vhdl. The specialty of this one is that it shows both Verilog and VHDL  and a flow diagram and the actual schematic of what the stuff synthesizes to. It's over 500 pages.
Finding it new is like ridiculously expensive... you can find used on amazon or ebay

I have that book.  It's a bit odd, in that it doesn't flow like most, going through the aspects of the languages as other books do.  It is an excellent way to compare the two languages and the examples are very thorough. 

[gnuarm]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

Yes, but a properly constructed design will easily meet timing. 

Rubbish.

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

If that's the case, then you don't have a design that meets timing and the compiler is mucking up because of a small change.  You have a design that, from the start, you expect to floorplan and small changes are expected to mess with the optimization.  If that's the case, then it's nothing like what we've been discussing and that's why optimizations are typically done last, after the logic is working. 

The situation you described is clearly a poorly constructed design that the place and route had trouble with.  Most likely, the code had some extraneous logic that was not intended, which was slowing down the timing.  I've seen that, where I expected a simple adder to be inferred, but I screwed up the carry and it had to toss a whole other adder in to do what my code asked it to do.  Once I identified the culprit, it was an easy fix and no layout tools required.

Not in that case.

Ok, then nothing you've said about the compiler mucking up your design is really relevant.

[free_electron]

Your points, position, and arguments mutate every time counterexamples show them to be lacking. That's not unreasonable, but beware the "no true Scotsman fallacy".

of course they do. there is only one constant : it all depends. nothing is clear cut. it all depends on circumstances.

i state that asic is cheaper if you are going for full performance and want to push the technology hard especially as a selling point. Real logic will always outperform fpga. FPGA has too much internal delays, delays that can be easier eliminated i hard logic as opposed to the routing fabric in an fpga.

you counterstate: look at the agilent logic analyser cards.

i counterstate : yes they used fpga but because it is low volume and they can afford to plonk down oodles of money for devices that co do the work ( those devices were not cheap back in the day those boards were deigned !) they got the performance they needed at the price they could afford ( ever seen the new price of one of those boards ? some were over 30.000 $ ). and even at that price it was cheaper than designing an asic simply because of the volume. ASIC has a large NRE.
look at the megazoom asic : there they did go full custom. simply because the number of oscilloscopes is 100 x or more larger than the number of those logic analysers. it woudl not make sense to use an FPGA.

i hear you coming with another counterpoint : but but the own/siglent/rigol are all using the xilinx zync.  yes, but that thing didn't exist 10 years ago ! that's why the 4000 series et al are using megazoom asics. and once  go to the faster scopes that zync thing can't cope either. wanna push the limit real hard in the 20+Gs/s you'll need to resort to something other than silicon.... your fpga cannot cope . that's why the real speed demons are indium phosphide semiconductors. There's two waferfabs in the world that can process those. ( the actual transsitors are Indium - gallium arsenide. the indium phosphide is the substrate). they only exist as 3 or 4 inch wafers as they are brittle.

and i hear another counterpoint coming : "but that's low volume ! you said asic  is for high volume.."  ,yes, except if the costs are irrelevant. they can afford to make those weirdo parts for the few hundred scopes they will ever sell. there simply is no other way to get the performance. and the people needing those scopes will pay.

Nobody in their right mind would even consider that an FPGA is suitable in all cases.

just like nobody in their right mind would consider an asic is suitable in all cases. why would fpga's exist ?

So FPGAs aren't the fastest devices and have their own limitations? I encourage you to submit that remarkable revelation to the IEEE so it can be published in a learned journal.

Been there, done that : published in IEEE ETW99 (and gave the speech) as well as "journal of computer standards and interfaces" and IMEKO TC congress. Detailed a FPGA based data generation/acquisition system to test fast A/D-D/A. back in the day (1997) there was nothing that could do what we needed,  so i rolled my own. Designed it using schematic capture and Verilog in the xilinx tools on Sun workstation. used a 3000 series coupled with lots of fast SRAM.

https://www.ieee-ets.org/past_events/etw99/pre_program.html  look for "pulsar"
https://www.sciencedirect.com/science/article/abs/pii/S0920548999000173

[laugensalm]

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.

I'd be happy to list plenty of high volume applications for FPGAs on another page, rendering the above statement void, but you might also just do some market analysis on the keywords 'huawei, ice40'. The times, they are a changin'.
Still, this discussion is getting childish and completely out of focus.

[ale500]

those tiny ice40 chips are used in some other phones too, look at the tear downs at I fix it.