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

121–130 of 161 posts

Re: The History, Status, and Future of FPGAs

#121

Post by exmadscientist »

roastsquirrel wrote: post #80
adwn wrote: post #62

Earlier quoted context omitted.

> VHDL (and its software counterpart Ada) are very well thought and great to use once you get to know them (and understand why they are the way they are). Yeah, they are a bit verbose but I prefer a strong base to syntactic sugar. As a professional FPGA developer: VHDL (and Verilog even moreso) are bad [1] at what they're used for today: implementing and verifying digital hardware designs. In fact, they're at most mo…

Parts of VHDL leave a little to be desired but overall I find it to be a really great language. To the extent I bought Ada 2012 by John Barnes and I kind of like that too after coding in C/C++ etc, but maybe I'm now biased after many years of VHDL coding :) It's not uncommon to see "VHDL is bad" and such like, and I do wonder what the reasons are for those comments.

As someone who just said that exact thing upthread, half of it is general curmudgeonry. VHDL is not a terrible language, though it does have terrible tools. The IDE side of things is a big opportunity to improve the language. Making refactoring easier by not needing to manually touch up three different files to fix one name is a huge help. (And the IDEs have probably improved in recent times; I've done mostly hardware recently.) The compilers/synthesizers... those are vendor crud and so dragons lie there. VHDL-2008 support would go a long way to improving life....

Re: The History, Status, and Future of FPGAs

#122

Post by ncmncm »

exmadscientist wrote: post #44
tyingq wrote: post #34

Earlier quoted context omitted.

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.

The other problem with using an FPGA here is that microcontrollers are cheap and have great cheap dev boards. FPGAs, not so much. I've wanted to just "drop in" a small FPGA in several designs, the way you can drop in a microcontroller, but there's no available FPGA that's not a massive headache in that use case. Trust me, I've looked. The iCE40 series is almost there but not quite. It's a bit pricey (this is sometime…

Crowd Supply has an endless variety of hobbyist-friendly variously FPGA / USB / MCU / PCIE / SDR combination boards.

It's ridiculous for anybody to insist that programming an FPGA isn't writing software. By definition, anything you can put in a text file that ends up controlling what some piece of hardware does is software. Probably almost all of what is wrong with FPGA ecosystems comes from failure to treat it like software.

It's not much like your typical C program, but that's a very parochial viewpoint. The languages available to program FPGAs in are abysmal, a poor match to the hardware: actually too much like ordinary programming languages, to their detriment. A person who makes an FPGA do something is going to be an engineer, and to an engineer any microprocessor and any FPGA are just two different state machines. Somebody who studied "computer science" will be disoriented, but that is just because the field has narrowed, as network effects pared down the field of computing substrates until practically nothing is left.

FPGAs emulating ASICs or von Neumann CPUs is the greatest waste of potential anywhere. If the architecture of (some) FPGAs could be elucidated, it could fuel a renaissance of programming formalisms. We could begin program them in a language actually well-suited to the task, and vary their configuration in real time according to the instantaneous task at hand.

Re: The History, Status, and Future of FPGAs

#123

Post by froh »

exmadscientist wrote: post #121
roastsquirrel wrote: post #80

Earlier quoted context omitted.

Parts of VHDL leave a little to be desired but overall I find it to be a really great language. To the extent I bought Ada 2012 by John Barnes and I kind of like that too after coding in C/C++ etc, but maybe I'm now biased after many years of VHDL coding :) It's not uncommon to see "VHDL is bad" and such like, and I do wonder what the reasons are for those comments.

As someone who just said that exact thing upthread, half of it is general curmudgeonry. VHDL is not a terrible language, though it does have terrible tools. The IDE side of things is a big opportunity to improve the language. Making refactoring easier by not needing to manually touch up three different files to fix one name is a huge help. (And the IDEs have probably improved in recent times; I've done mostly hardwar…

If IDE support for basics is an issue,like consistent renaming, then language server protocol support will help:

https://github.com/ghdl/ghdl-language-server

Edit: typo in url

Re: The History, Status, and Future of FPGAs

#124

Post by mindentropy »

duskwuff wrote: post #54
mindentropy wrote: post #40

Earlier quoted context omitted.

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.

Oh I love their humor. There is always something humorous written for their status LEDS.

"Although no specific testing was performed, sophisticated statistical finite element models and back of the envelope calculations are showing the number of status LEDs to be bright enough to execute dermatological procedures normally done with CO2 lasers. Contact the factory for more information about this sophisticated feature and make sure an adult is present during operation. These LEDs are user controllable from the FPGAs so can be used as visual feedback in addition to burning skin."

"As with all of our FPGA-based products boards, the DNVUPF4A is loaded with LEDs. The LEDs are stuffed in several different colors (red, green, blue, orange et al.). There are enough LEDs here to melt cheese. Please don't melt cheese without adult supervision. These LEDs are user controllable from the FPGAs so can be used as visual feedback in addition to the gratifying task of creating gooey messes."

Re: The History, Status, and Future of FPGAs

#125

Post by mindentropy »

TomVDB wrote: post #50
mindentropy wrote: post #40

Earlier quoted context omitted.

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

No, it was in-house custom made for the purpose. Huge PCBs, ~2ft by 2ft.

Curious, what was the reason for going with custom board instead of COTS boards?

Is board to board connection with high speed connectors feasible? This was what I heard from verification folks.

Re: The History, Status, and Future of FPGAs

#126

Post by mindentropy »

lnsru wrote: post #51
mindentropy wrote: post #42

Earlier quoted context omitted.

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.

It is still in dev but I think it is way more usable than the Xilinx tools I guess.

I am curious to know if you are using Qemu by any chance to prototype your hardware. I am doing some work on Qemu to make prototyping easier of a custom hardware and would love the pain points.

Re: The History, Status, and Future of FPGAs

#127

Post by inaccel »

2 are the main challenges of the FPGA utilization:

- The first one is the FPGA programming. Now using OpenCL and HLS is much easier compared to VHDL/verilog to design your own accelerators.

- The second one is the FPGA deployment and integration. Until now it was very difficult to integrate your design with applications, to scale-out efficiently and to share it among multiple threads/users. The main reason was the lack of an OS_layer (or abstraction layer) that would enable to treat FPGAs as any other computing resource (CPU, GPU).

This is why at inaccel we developed a unique vendor-agnostic orchestrator for FPGAs. The orchestrator allows much easier integration, scaling and resource sharing of FPGAs.

That way we have managed to decouple the FPGA designer from the software developer. The FPGA designer creates the bitstream and the software developer just call the function that wants to accelerate. No need to define the bitstream file, no need to define the interface or the memory buffer allocation.

And the best part: It is vendor and platform agnostic. The FPGA designer creates multiple bitstream for different platform and the software developer couldn't care less. The developer just call the function and the inaccel FPGA orchestrator magically configure the right FPGA for the right function.

Re: The History, Status, and Future of FPGAs

#128

Post by inaccel »

daxfohl wrote: post #100
Stubb wrote: post #58

Earlier quoted context omitted.

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.

I think that's the big advantage of FPGA. If you need acceleration to hit a 10 microsecond latency target, FPGA is what you need. If your latency target is like a millisecond or longer, then GPU can handle a lot more throughput. But GPU can't typically give you a 10-us guarantee. Okay, bit-banging is another advantage of FPGA that GPU doesn't do as well. There are a few things.

Regarding DNN inference FPGA can provide low latency AND higher throughput than GPUS.

If you want to compare apples-to-apples, we have done a comparison with realistic (and not synthetic) data regarding the performance of GPUs and FPGAs.

https://medium.com/@inaccel/faster-inference-real-benchmarks...

Re: The History, Status, and Future of FPGAs

#129

Post by exmadscientist »

ncmncm wrote: post #122
exmadscientist wrote: post #44

Earlier quoted context omitted.

The other problem with using an FPGA here is that microcontrollers are cheap and have great cheap dev boards. FPGAs, not so much. I've wanted to just "drop in" a small FPGA in several designs, the way you can drop in a microcontroller, but there's no available FPGA that's not a massive headache in that use case. Trust me, I've looked. The iCE40 series is almost there but not quite. It's a bit pricey (this is sometime…

Crowd Supply has an endless variety of hobbyist-friendly variously FPGA / USB / MCU / PCIE / SDR combination boards. It's ridiculous for anybody to insist that programming an FPGA isn't writing software. By definition, anything you can put in a text file that ends up controlling what some piece of hardware does is software. Probably almost all of what is wrong with FPGA ecosystems comes from failure to treat it like…

FPGAs aren't state machines or processors. Not inherently, anyway, even if you can build those things out of them or if they sometimes are sold co-packaged.

And their internal architecture is pretty well documented. See, for example, the Spartan-6 slices: https://www.xilinx.com/support/documentation/user_guides/ug3...

What's less well documented, at least publicly, is the routing, but on some level that's less interesting since it's "just" how you get the electrons from point A to point B, not about choosing A or B. But even the routing is decently well described, though you have to look in some fairly obscure places (like the device floorplan viewer).

I'm not sure why you think FPGAs emulating ASICs is a "waste of potential". By definition, ASICs are strictly more capable and more powerful than FPGAs, so you're climbing up the potential ladder, not down!

Re: The History, Status, and Future of FPGAs

#130

Post by mindentropy »

borramakot wrote: post #86
cbzoiav wrote: post #78

Earlier quoted context omitted.

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 t…

There is also glue logic between different interfaces that can be satisfied with FPGAs or CPLDs.
Post reply on HN