Reinventing the FPGA Programming Wheel
nextplatform.com
nextplatform.com
What I said about the same sentiment a month ago: https://news.ycombinator.com/item?id=15574074
* Complete control over pin assignments.
* Complete control over PLLs and clocks.
* Complete control over transitioning clock domains, and other timing characteristics, skew, etc.
* Convenient SoC features: DSP multipliers, SRAM, on chip flash memory, ADCs, etc. and the ability to run a soft core CPU on chip as a convenience and/or to give it direct access to various clock domains.
* All hardware features including all listed above are in-system programmable.
FPGAs are excellent glue, and the smaller sizes of MAX-10 (or equivalent) are cheap and have a small footprint. If you're doing hardware design that uses CPUs, adding an FPGA can vastly improve the flexibility of your design. They are great for interfacing to other dedicated chips. They also make good DSP chips, but if they strictly only did that they wouldn't be nearly as useful.
If you want to have "hardware-optimization" in your HTTP server, I think you'd probably, rather than implement a Ethernet, TCP, L7 HTTP/1.1 stack from scratch use a combination of hard IP and soft IP. I imagine the places where a webserver is bottlenecked is well known -- you could extend the ISA, or have additional cores to help out with that part of the workload, and then run the rest on hard IP.
I think the biggest problem right now is programmability, and moving bits between x86 processors and FPGAs. I hope Intel's acquisition is fruitful and we see some FPGA on CPUs.
When you're faced with a problem and you catch yourself thinking, "I wish I had an ASIC for this," your problem may be a good candidate for FPGA implementation. If what you're itching for is a faster CPU, or one that costs less or uses less power, then it probably isn't.
FPGAs are vital for interfacing to high-bandwidth custom hardware -- at least for those who don't have ASIC budgets -- and they're also useful for certain types of "embarrassingly parallel" problems that GPUs aren't well-suited for, especially where precision timing requirements and low latency are involved.
So, while you wouldn't typically resort to FPGAs when you're implementing an ordinary HTTP server, you might want to use them to build a dedicated TCP/IP offload engine, packet filter, or even a specialized memory controller. They are never going to be mainstream parts, even to the extent GPUs are. If and when you need an FPGA in your project, you'll know it.
That is the shortest and best description for the difference I've ever read. Kudos. From now on I'll use it to answer questions about FPGAs for accelerating.
I used to tell people that you don't design algorithms but a network of operations and pipelines where you stream your data through.
Also, 'reprogramming' isn't as simple as it sounds. It is a pain staking process to test RTL you want to put into production. Even simple projects I'm working on, simple tests and synthesis take a lot of time.
(Rebracketing in language is the process by which you now may find yourself eating an orange rather than a narange, cutting a notch in something rather than cutting an otch, or feeling a bit more alone than all one. Sometimes it results in language change, but there's that awkward period where it's wrong first.)
But while I'm on this subtopic, if you've never heard of it, "france is bacon" is fun to google.
But that "if" is the problem -- you'll spend more time and CPU shuttling data back and forth than you would gain by specializing the problem in an FPGA.
They can do more work per clock-cycle either using dedicated processing logic for a particular operation (some bit twiddling stuff like crypto can take advantage of this), pipelining multiple requests in serial, or processing multiple different requests at exactly the same time in parallel.
Crucially, whichever method(s) you use, you need to achieve more than 10 times the work-per-clock to make up for the clock being 10 times slower.
FPGAs are harder to program, have fewer and less well-rounded toolchains and are much much much harder to debug than other software. A bug tends to simply freeze the system completely for example.
An HTTP server on an FPGA where the FPGA isn't just emulating a general purpose CPU (a so-called "soft core") at a slow clock speed? Yes it's do-able: https://news.ycombinator.com/item?id=11776190, but it's questionable whether it would ever be faster than something written on an x86 CPU.