The History, Status, and Future of FPGAs • Hacker News Board

Re: The History, Status, and Future of FPGAs

#51

Post by lnsru » Thu, Jul 23, 2020, 5:51 PM UTC

mindentropy wrote: post #42

lnsru wrote: post #23

I am working right now on bare metal websockets implementation on Xilinx Series 7 FPGAs. Currently it’s ZynQ SoC, but final product will probably have Kintex 7 inside, so no Linux. The tools make me cry, no examples, application notes from 2014 with ancient libraries. I hope, vendors will fix tooling. But I see, Xilinx has released Vitis, so their scope is elsewhere, no interest in old crap. Using Git with Vivado is…

Have you looked at open source solutions? Tim Ansell is managing some great projects on open source solutions. Check out Symbiflow, LiteX, Yosys etc.

Are these mature already? It took some time for KiCad to get to current usable state and I don’t want to be early adopter. In fact, I want to have my private hardware MVP next year with current tools. On the other hand I can’t imagine my slacker colleagues using anything else than Vivado. Learning Vivado for them was already mission impossible.

Re: The History, Status, and Future of FPGAs

#52

Post by rogerbinns » Thu, Jul 23, 2020, 5:57 PM UTC

tyingq wrote: post #34

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…

There is another traditional FPGA use case where you need real time data capture or signal generation. That seems to be getting eaten from the bottom now that there are really high speed MCUs that are easier to program. It's less efficient, but easier to develop for.

I good example of this is XMOS. Their chips are divided into "tiles" which can simultaneously run code, together with multiple interfaces such as USB, i2s, i2c, and GPIO. Latency is very deterministic because the tiles are not using caches, interrupts, shared buses etc.

Their development environment is Eclipse based with numerous libraries such as audio processing, interface management, DFU etc. They use a variant of C (xc) that lets you send data between channels/tiles, and easily parallelize processing.

An example use is in voice assistants where multiple microphones need to be analyzed simultaneously, echo and background noise has to be eliminated, and the speaker isolated into a single audio stream. I've used it for an audio processing product that needed match hardware timers exactly, provide USB access, matched input and output etc.

Re: The History, Status, and Future of FPGAs

#53

Post by kyboren » Thu, Jul 23, 2020, 5:59 PM UTC

jcranmer wrote: post #49

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…

Again, a counterpoint: I worked on hardware for something akin to a FPGA on a much coarser granularity (kind of like coarse-grained reconfigurable arrays)--close enough that you have to adapt tools like place-and-route to compile to the hardware. The programming for this was mostly driven in pretty vanilla C++, with some extra intrinsics thrown in. This C++ was close enough to handcoded performance that many people d…

For sure. FPGAs are probably not the answer that most people are looking for. FPGAs are but one point in the trade-off space, and they're not one you jump to "just because".

> [...] there are useful nearby technologies that can leverage the benefits of FPGAs while having programming models that are on par with (say) GPGPU

I think CGRAs are really cool but they're even more niche, and I suspect your original point about GPUs eating everyone's lunch applies particularly strongly to CGRAs. The point is well taken, though, and I don't necessarily disagree.

Re: The History, Status, and Future of FPGAs

#54

Post by duskwuff » Thu, Jul 23, 2020, 6:00 PM UTC

mindentropy wrote: post #40

TomVDB wrote: post #35

Earlier quoted context omitted.

Many years ago, we had a custom made board with 8 huge Xilinx Virtex 5 FPGAs (the largest available at the time) to emulate a large SOC. Those FPGAs were something like $20K a piece. We had 10 such boards, good for millions of dollars in hardware, and a small team to keep it running. These platform were mostly used by the firmware team to develop everything before real silicon came back. It could run the full design…

The multiple FPGA on a board is generally from Dini Group right? Fantastic boards. Ref: https://www.dinigroup.com/web/index.php

Dini's naming schemes are hilarious. They're all named like monsters in B-movies -- their latest system, the DNVUF4A, is called "Godzilla's Butcher on Steroids", for instance.

Also, Dini got acquired by Synopsys a few years ago.

Re: The History, Status, and Future of FPGAs

#55

Post by duskwuff » Thu, Jul 23, 2020, 6:02 PM UTC

geforce wrote: post #17

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 .

IIRC some CPUs of the Intel Atom series already have an embedded FPGA.

Intel has launched a couple of Xeon Gold CPUs (like a variant of the 6138P) with integrated FPGAs for specific markets. Nothing mass-market, though, and they don't seem to have caught on much.

Re: The History, Status, and Future of FPGAs

#56

Post by jacquesm » Thu, Jul 23, 2020, 6:03 PM UTC

TomVDB wrote: post #35

rwmj wrote: post #4

> Intel, AMD, and many other companies use FPGAs to emulate their chips before manufacturing them. Really? I'm assuming if this is true it can only be for tiny parts of the design, or they have some gigantic wafer-scale FPGA that they're not telling anyone about :-) Anyway I thought they mainly used software emulation to verify their designs.

Many years ago, we had a custom made board with 8 huge Xilinx Virtex 5 FPGAs (the largest available at the time) to emulate a large SOC. Those FPGAs were something like $20K a piece. We had 10 such boards, good for millions of dollars in hardware, and a small team to keep it running. These platform were mostly used by the firmware team to develop everything before real silicon came back. It could run the full design…

Design verification is big business and your VP was exactly right, a factor of 100 to 1000 speed increase would allow for much more thorough testing and broader testing as well, for instance hooked up to other hardware with reasonable fidelity compared to the real thing. Still coarse but a lot better than nothing. Good call. It isn't rare at all to have a respin if you don't do design verification.

One of the nicer stories about the first ARM chip is that they built a software simulator to verify the design and as a result they found plenty of bugs in the hardware before committing to silicon. The first delivered chips worked right away.

Re: The History, Status, and Future of FPGAs

#57

Post by duskwuff » Thu, Jul 23, 2020, 6:04 PM UTC

rwmj wrote: post #5

wwarner wrote: post #2

This is really interesting. If a cpu hardware vulnerability like spectre could be repaired by patching an fpga on the SOC that would be incredible. That type of functionality would overtake the entire cloud market in about 3 days.

I'm afraid it doesn't work like this. That would only be possible if the chip was using an FPGA fabric for the relevant parts of the design. For example if the L1 cache was implemented as an FPGA you could in theory patch around L1TF. But they wouldn't do that because it would be far slower/larger than implementing it directly as an ASIC. Or you might imagine a chip that has an FPGA on the side (I expected Intel woul…

> Or you might imagine a chip that has an FPGA on the side (I expected Intel would ship this after acquiring Altera, but it never happened).

They did: https://www.anandtech.com/show/12773/intel-shows-xeon-scalab...

But I get the sense this part was aimed at a few very specific customers. It required some PCB-level power delivery changes, so you couldn't even drop it into a standard server motherboard.

Re: The History, Status, and Future of FPGAs

#58

Post by Stubb » Thu, Jul 23, 2020, 6:05 PM UTC

kyboren wrote: post #30

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…

GPUs work great for accelerating many applications, and it's true that that reduces interest in FPGAs. For applications that map well to GPUs, you're absolutely correct that the higher clock speeds (and greater effective logic area) make GPUs superior as accelerators. However, some applications do not map well to GPUs. Particularly those applications with a great deal of bit-level parallelism can achieve enormous spe…

Another big advantage of FPGAs is low latency and the ability to hit precise timing deadlines. When working with radio hardware, you still need an FPGA for automatic gain control calculations and recording/playing out samples. Similarly, you need to do your CRC and other calculations in an FPGA if you need to immediately respond to incoming signals, such as the CTS->RTS->DATA->ACK exchange in 802.11.

Re: The History, Status, and Future of FPGAs

#59

Post by jacquesm » Thu, Jul 23, 2020, 6:15 PM UTC

dbcurtis wrote: post #18

Koshkin wrote: post #11

I wonder what would be the advantages of using an FPGA to test a CPU design - compared to relying on a (presumably more accurate) computer-based simulation. (I understand the reasons one might want to implement a CPU in an FPGA.)

This idea is more than 30 years old. It has been done, and one upon a time companies were built around this idea. First off, mapping an entire CPU to an FPGA cluster is a design challenge itself. Assuming you can build an FPGA cluster large enough to hold your CPU, and reliable enough to get work done on it, you have the problem of partitioning your design across the FPGA's. Second problem: observability. In a simula…

> Reset bugs suck.

Indeed they do. And even if you have working chips you get the next stage: board level reset bugs. A MC68K board I helped develop didn't want to boot, some nasty side effect of a reset line that didn't stay at the same level long enough stopped the CPU from resetting reliably when everything else did just fine. That took a while to debug.

Re: The History, Status, and Future of FPGAs

#60

Post by sfgnilnio » Thu, Jul 23, 2020, 6:15 PM UTC

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…

You ever work with an FPGA? The programming model and the tooling are a huge part of the problem.

Verilog and VHDL have basically nothing in common with any language you've ever used.

Compilation can take multiple days. This means that debugging happens in simulation, at maybe 1/10000th of the desired speed of the circuit.

If you try to make something too big, it just plain won't fit. There is no graceful degradation in performance; an inefficient design will just not function, come Hell or high water.

The existing compilers will happily build you the wrong thing if you write something ill-defined. There are a ton of things expressible in a hardware description language that don't actually map onto a real circuit (at least not one that can be automatically derived). In any normal language anything you can express is well-defined and can be compiled and executed. Not so in hardware.

Timing problems are a nightmare. Every single logic element acts like its own processor, writing directly into the registers of its neighbours, with no primitives for coordination. Imagine if you had to worry about race conditions inside of a single instruction!

Maybe if all these problems are solved FPGAs still wouldn't catch on, but let's not pretend the programming model isn't a problem. Hardware is fundamentally hard to design and the tooling is all 50 years out of date.