XDC 2019 | Everything Wrong With FPGAs - Ben Widawsky

FPGAs and their less generic cousin, specialized accelerators have come onto the scene in a way that GPUs did 20 or so years ago. Indeed new interfaces have cropped up to support them in a fashion resembling early GPUs, and some vendors have even opted to try to use DRM/GEM APIs for their devices.
This talk will start with a background of what FPGAs are, how they work, and where they're currently used. Because the audience is primarily people with graphics/display background, I will make sure to cover this well. It will then discuss the existing software ecosystem around the various usage models with some comparison of the existing tools. If time permits, I will provide a demo comparing open tools vs. closed ones.
The goal of the talk is to find people who have lived through DRI1 days and are able to help contribute their experience (and coding) toward improving the stack for the future accelerators.
Currently, my focus is on helping to improve a fully open source toolchain, and so I will spend more time on that then API utilization.

[@jeffg4686]

FPGAAAAA - that must be some kind of acronym world record (most contiguous A's in an acronym)

[@peter_godman]

I would love to hear the speaker's thoughts on what ended up happening on the GPU side and what a similar resolution would look like in FPGAs.

[@szaszm_]

There are full screen red flashes throughout the video.

[@tombouie]

Thks again

[@ruiwang5582]

FPGA, in fact, is a low-cost practice of mapping algorithms to hardware, which is another perspective on algorithms. I am a developer of xilinx Vitis Library image Codec. Four years ago, I was not familiar with WebP algorithm when I used HLS. It took me four months to achieve the price efficiency and power consumption efficiency of CPU 3X, which is still surprising. In fact, RTL can be further improved by 3 to 10 times. The problem with FPGA is that the mapping of top-level branches to the area will inevitably lead to a decline in efficiency. You must let the branches sink, which is a great test for understanding the algorithm. Sometimes you even need to understand the essence of the algorithm more than the algorithm developers, because more and more algorithms tend to explore the problem space extensively and then select the best. What you can do is to find the one with higher probability among the branches, and give it the most resources, while the other branches use the least area. When you can discover this probability, you actually discover a new knowledge. Isn't that a gain?

[@kayakMike1000]

I like soup.

[@kayakMike1000]

This isn't twitter.

[@binaryblade2]

vendors: we introducing high level synthesis
us: so we can use a higher level language and abstractions to build our systems
vendors: yes, you can accelerate your design process
us: so which kind of high level language. python, scala, ocaml...
vendors: we're giving you the highest of high level languages....C
us: ....srsly

[@peter_godman]

So true.

[@binaryblade2]

@OLDSKOOL978 Except it's designed for a turning machine. It really is a failure to think of c as a "good" choice in any sense of the word for HDL.

[@binaryblade2]

@OLDSKOOL978 There is a large space of languages and features that allow for effectively writing composable HDL that doesn't involve hacking up some imperative language and calling it an improvement. The current HDL languages leave much to be desired, but C is not the answer.

[@rishz1]

@OLDSKOOL978 I completely agree. Exactly my thoughts.

[@ianzhang862]

It's not really "C" either, with all the crazy directives. The person who works on it pretty much has to know the nuts and bolts of RTL level of representation well. This implies a smaller user base that leads to harder to find support for anyone who works outside of professional design houses.