Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The History, Status, and Future of FPGAs

queue.acm.org

Post reply on HN
Print view View original

81–90 of 161 posts

Re: The History, Status, and Future of FPGAs

#81

Post by jjoonathan »

cmrdporcupine wrote: post #79
jcranmer wrote: post #16

As a bit of a counterpoint: One of my prior projects involved working with a lot of ex-FPGA developers. This is obviously a rather biased group of people, but I saw a lot of feedback around that was very negative about FPGAs. One comment that's telling is that since the 90s, FPGAs were seen as the obvious "next big technology" for HPC market... and then Nvidia came out and pushed CUDA hard, and now GPGPUs have corner…

See it's funny, I (software guy) have recently started doing a bunch of FPGA stuff on the side for "fun" and I find the programming model to not be the biggest challenge. The tools, yes, because it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs with half the features that us software developers have, and with a crapload of vendor lock-in... but I digress. I find working…

I don't mean to belittle your exploration, but are you sure it's an apples-to-apples comparison? This suggests to me that it isn't:

> it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs

Hardware engineers feel pain just like you do. The reason why they put up with those awful software suites is because they have features they need that aren't available elsewhere. In particular, they interface with IP blocks and hard blocks, including at a debug + simulation level. Those tend to evolve quickly and last time I looked -- which admittedly was a while ago -- the open source FPGA tooling pretty much completely ignored them, even though they're critical to commercial development.

If you are content to live without gigabit transceivers, PCIe controllers, DRAM controllers, embedded ARM cores, and so on, I suspect it would be relatively easy to use the open source tooling, but you would only be able to address a small fraction of FPGA applications.

Re: The History, Status, and Future of FPGAs

#82

Post by sod »

d_silin wrote: post #9

I wonder if it is possible to add a (small) FPGA to a personal computer that could accelerate any specific software tasks (video/audio encoding, ML algorithms, compression, extra FPU capabilities) on user demand .

Isn't that what Apple did with that Afterburner Card for the MacPro? I read in https://www.anandtech.com/show/15646/apple-now-offering-stan... that that card is an fpga.

I could imagine that Apple will include something like this in their Apple Silicon SOC for ARM macs.

The Afterburner Card is not user programmable, but maybe it may in the future and this was just the first try to get the hardware in the field.

Re: The History, Status, and Future of FPGAs

#83

Post by mdiesel »

jcranmer wrote: post #16

As a bit of a counterpoint: One of my prior projects involved working with a lot of ex-FPGA developers. This is obviously a rather biased group of people, but I saw a lot of feedback around that was very negative about FPGAs. One comment that's telling is that since the 90s, FPGAs were seen as the obvious "next big technology" for HPC market... and then Nvidia came out and pushed CUDA hard, and now GPGPUs have corner…

I work with fpgas, but from LabVIEW. NI have put some effort into making the same language work for everything including fpgas, and a graphical language is great for this kind of work.

It's so easy that it's quite common to see people pass off work onto the fpga if it involves some slightly heavier data processing, which is exactly how it should be.

Re: The History, Status, and Future of FPGAs

#84

Post by qppo »

kyboren wrote: post #48
exmadscientist wrote: post #38

Earlier quoted context omitted.

Very much this. (Also, in general, FPGA tools are just some of the lowest quality garbage out there... and that is saying something. They're that bad . This is a completely unnecessary speedbump.) The rebuttal to your objection is always tools like "HLS" (High-Level Synthesis), or in English it's "C to HDL" (FPGAs are 'programmed' in the two Hardware Definition Languages VHDL (bad) or Verilog (worse, but manageable i…

> The rebuttal to your objection is always tools like "HLS" Yup. I know HLS has gotten a lot better recently but my impression is that, somewhat like fusion, HLS as a first-class design paradigm is always a decade away. > FPGA tools are just some of the lowest quality garbage out there Absolutely. I think the problem is vendors see FPGA tooling as a cost center and a necessary evil in order to use their real products…

> HLS as a first-class design paradigm is always a decade away.

What about Chisel?

Re: The History, Status, and Future of FPGAs

#85

Post by ianhowson »

s_gourichon wrote: post #67
kyboren wrote: post #48

Earlier quoted context omitted.

> The rebuttal to your objection is always tools like "HLS" Yup. I know HLS has gotten a lot better recently but my impression is that, somewhat like fusion, HLS as a first-class design paradigm is always a decade away. > FPGA tools are just some of the lowest quality garbage out there Absolutely. I think the problem is vendors see FPGA tooling as a cost center and a necessary evil in order to use their real products…

> cannot take a bitstream compiled for one FPGA and program it to any other FPGA. Like considering dumping memory content on a PC and reinject it on another with different RAM layout and devices and complaining the OS and programs can't continue running? Is that a sane expectation? There are upstream formats targeting FPGAs that can be shared, although yes redoing place and route is slow. Should manufacturers provide…

> bitstream ... Is that a sane expectation?

No. Bitstream formats are not in any way compatible across devices. Because timing is a factor, even if you had the same physical layout of LUTs and routing, it's unlikely that your design would work.

(From parent)

> use that bitstream for any other device in the same device family

Not at the bitstream level. However, you can take a place&routed chunk of logic and treat it as a unit. You can replicate it (without repeating P&R), move it around, copy it onto other devices in the same family. This is super useful as most FPGA applications have large repeating structures, but P&R doesn't know that it's a factorable unit. It'll repeat P&R for each instance and you'll get unpredictable timing characteristics.

> Should manufacturers provide new formats closer to final form yet would allow binaries that can be adjusted, kind of like .a .so or even llvm?

> would building whole images for many families of FPGA make sense

You can license libraries that are a P&R'd blob and drop them into your design. There's no easy way to make this generalizable across devices without shipping the original RTL, and conversion from RTL->bitstream is where most of the pain lies.

Re: The History, Status, and Future of FPGAs

#86

Post by borramakot »

cbzoiav wrote: post #78
borramakot wrote: post #75

Earlier quoted context omitted.

Just to throw in one more complication, I'll assert that the only benefits of FPGAs over ASICs are one time costs and time to market. Those are big benefits, but almost by definition, they aren't as important for workloads that are large scale and stable. So, if you do have a workload that's an excellent match for FPGAs, and if that workload will have lots of long term volume, you should make an ASIC for it. So, for…

Thats not entirely true - the flexibility can have its own value. Unlike an ASIC you can handle multiple workloads or update flows. For example timing protocols on backbone equipment handling 100-400Gbps. Depending on how its configured you may need to do different things. Additionally you probably don't want to replace 6 figure hardware every generation. Another example is test equipment where you can't run the test…

I may not have said it well, but I broadly agree with you. If a workload needs high performance but not consistently (e.g. because you're doing serial tests by swapping bitstreams), predictably (e.g. because you need flexibility for network stuff you can't predict at design time), or with enough volume (e.g. costs in the low millions are prohibitive), an ASIC isn't the right solution.

But my point is that for FPGAs to come to prominence as a major computation paradigm, it probably won't be because it outperforms GPU on one really big workload like bitcoin or genetic analysis or something. It'll have to be a moderately large number of medium scale workloads.

Re: The History, Status, and Future of FPGAs

#87

Post by henrikeh »

qppo wrote: post #84
kyboren wrote: post #48

Earlier quoted context omitted.

> The rebuttal to your objection is always tools like "HLS" Yup. I know HLS has gotten a lot better recently but my impression is that, somewhat like fusion, HLS as a first-class design paradigm is always a decade away. > FPGA tools are just some of the lowest quality garbage out there Absolutely. I think the problem is vendors see FPGA tooling as a cost center and a necessary evil in order to use their real products…

> HLS as a first-class design paradigm is always a decade away. What about Chisel?

Chisel is not a HSL. Chisel is much closer to VHDL and Verilog, since the hardware is directly described.

Re: The History, Status, and Future of FPGAs

#88

Post by kyboren »

s_gourichon wrote: post #67
kyboren wrote: post #48

Earlier quoted context omitted.

> The rebuttal to your objection is always tools like "HLS" Yup. I know HLS has gotten a lot better recently but my impression is that, somewhat like fusion, HLS as a first-class design paradigm is always a decade away. > FPGA tools are just some of the lowest quality garbage out there Absolutely. I think the problem is vendors see FPGA tooling as a cost center and a necessary evil in order to use their real products…

> cannot take a bitstream compiled for one FPGA and program it to any other FPGA. Like considering dumping memory content on a PC and reinject it on another with different RAM layout and devices and complaining the OS and programs can't continue running? Is that a sane expectation? There are upstream formats targeting FPGAs that can be shared, although yes redoing place and route is slow. Should manufacturers provide…

> Like considering dumping memory content on a PC and reinject it on another with different RAM layout and devices and complaining the OS and programs can't continue running? Is that a sane expectation?

Even worse; it's more like that plus extracting the raw microarchitectural state of a CPU, serializing it in a somewhat arbitrary way, trying to shove that blob into a different CPU and still expecting everything to continue running.

I'm not necessarily complaining, just pointing out this significant difference WRT software programs running on CPUs.

> There are upstream formats targeting FPGAs that can be shared, although yes redoing place and route is slow.

Can you show me an example? I'd like to see this. You do not mean FPGA overlays, correct?

> Should manufacturers provide new formats closer to final form yet would allow binaries that can be adjusted, kind of like .a .so or even llvm?

Like you say, at the very least you will need to re-do place and route. But actually the problem is much worse than this. Different FPGAs have different physical resources. Not just differing amounts of logic area, but different amounts of block RAM, different DSP blocks and in varying numbers, high-speed transceivers, etc. This necessitates making different design trade-offs. Simply shoehorning the same design into different FPGAs, even if it were kind of possible, will not work well.

> Alternatively, would building whole images for many families of FPGA make sense?

Currently I think that's the only real option. But the extreme overhead, duplication of effort and maintenance burden make it very unattractive.

My napkin sketch is some sort of generalized array of partial reconfiguration regions with standardized resources in each region. Accelerator applications can distribute versions targeting different numbers of regions (e.g. one version for FPGAs supporting up to 8 regions, one for FPGAs supporting up to 16 regions, etc.). The FPGA gets loaded with a bitstream supporting a PCIe endpoint and management engine, and some sort of crossbar between regions. At accelerator load time, previously mapped, placed, and routed logical regions used in the application are placed onto actual partial reconfiguration regions and connections between regions are routed appropriately. The idea is to pre-compute as much of the work as possible, leaving a lower dimension problem to solve for final implementation. Timing closure and clock management are left as exercises for the reader :P.

Re: The History, Status, and Future of FPGAs

#89

Post by jlokier »

alfalfasprout wrote: post #73
formerly_proven wrote: post #69

Earlier quoted context omitted.

> You ever work with an FPGA? The programming model and the tooling are a huge part of the problem. I'd argue FPGAs aren't programmed and don't have a programming model. Complaints that the programming model of FPGAs holds their adoption back are thus conceptually ill-founded. (The tooling still sucks).

I mean, the problem is that in the FPGA world the tooling and synthesis languages are inextricably linked. HLS is an approach that, IMO, is also the completely wrong direction since a general purpose programming language like C/C++ won't map nicely to the constructs you need in FPGA design. What we really need is a lightweight, open source toolchain for FPGAs and one or more "higher level" synthesis languages. I've a…

> I've always wondered if a DSL using a higher language like Python isn't a better way to do this

Like this? http://www.myhdl.org/

Re: The History, Status, and Future of FPGAs

#90

Post by kyboren »

vzidex wrote: post #66
kyboren wrote: post #48

Earlier quoted context omitted.

> The rebuttal to your objection is always tools like "HLS" Yup. I know HLS has gotten a lot better recently but my impression is that, somewhat like fusion, HLS as a first-class design paradigm is always a decade away. > FPGA tools are just some of the lowest quality garbage out there Absolutely. I think the problem is vendors see FPGA tooling as a cost center and a necessary evil in order to use their real products…

>I think the problem is vendors see FPGA tooling as a cost center and a necessary evil Yes to a degree, but another part of the problem is the "physical constraints" you mention. FPGA tooling has to solve multiple hard problems, on the fly, at large scale (some of the latest chips are edging up to 10M logic elements). Unfortunately for the FPGA industry, I think that this is unavoidable - though a lot of interesting…

Well, that's an explanation for why FPGA compilation flows take so much time, but it's not a good explanation for why the software is so crap.

I think partial reconfiguration is really sexy, but it's been around for a long time. What's new and exciting there? Genuinely curious.

Post reply on HN