
Reinventing the FPGA Programming Wheel - jonbaer
https://www.nextplatform.com/2017/11/30/reinventing-fpga-programming-wheel/
======
exikyut
> _“The FPGA community has to figure out a way to be able to build on legacy,
> on work that has come before rather than having to throw everything away and
> start fresh with a new generation.”_

What I said about the same sentiment a month ago:
[https://news.ycombinator.com/item?id=15574074](https://news.ycombinator.com/item?id=15574074)

------
wgj
FPGAs are usually a better situational substitute for an ASIC than a CPU.
Relative strengths of FPGAs:

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

------
Callmenorm
Would it ever be possible to program an fpga to run your HTTP server? So you'd
have hardware that was specially designed for your program. Deploying code
would just be about reprogramming the FPGA.

~~~
CamperBob2
It's not a good idea to think of "programming" an FPGA to do anything. You're
creating dedicated hardware. You tell a CPU what to do, while you tell an FPGA
what to _be_.

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.

~~~
jeffreygoesto
> You tell a CPU what to do, while you tell an FPGA what to be.

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.

~~~
banachtarski
It's a very common trope by FPGA enthusiasts.

------
capitalsigma
If you're writing totally generic "hardware as a service" RTL, it's hard to
imagine that you're saving $ relative to regular old fashioned CPUs.

------
workthrowaway27
FPGAs just aren't that useful for most applications. (I like FPGAs, they're
cool and they're fun, but they're niche for a reason.)

