Comment by kmod | Hacker News Reader

Comment by kmod | Hacker News Reader

Parent Full thread

Here's the relevant bit from the overview:

  Programmable logic circuits are presented as hardware libraries called overlays. These overlays are analogous to software libraries. A software engineer can select the overlay that best matches their application. The overlay can be accessed through an application programming interface (API). Creating a new overlay still requires engineers with expertise in designing programmable logic circuits.

In other words, you're not doing direct programming of the FPGA with these new apis. Instead it looks like they are making it easier to select and use existing overlays (aka existing hardware designs) by wrapping it up in some nice Python interfaces. So as more overlays are released (right now it looks like there is only the "base" overlay) it should be easy to switch between them as you want to accelerate different sorts of problems.

You might say "why doesn't this exist already", but the whole ecosystem is currently quite hard to use (think GPU programming but from 5 or 10 years ago) so putting some nice interfaces on it could be a big step. Will be interesting to watch.

To add to this - a lot (maybe all?) of the functionality that is described by the concept of "overlays" maps to the design and implementation of the programmable logic in a coprocessor system. To use Xilinx terms, this would be the block diagram that describes the periphery that connects to either a soft- or dedicated-core processor. The block diagram will control the usage of programmable logic cores and provide hooks for the BSP generator and SDK to wrap these in ways useful for software development - memory maps & base addresses, associated drivers, etc.

The big value add that I see here is that the management of these overlays has traditionally been painful, especially when trying to swap overlays at runtime - this is always sold as one of the big benefits of SoC processor+FPGA, that you can do things like dynamic hardware accelerators based on what software is currently running, but more than some assembly has always been required. This seems like a nice step in the direction of having reasonable mechanisms to reconfigure based on application.

I could be wrong, but I'd imagine the overlay functionality is fairly similar to 'header' files in other programming libraries, in that they're a list of instructions available to program with, that point to a precompiled library (in this case, hardware-accelerated libraries).

Thanks for the summary.

I like the overlay idea as a stepping stone to something more flexible. I personally think in the near future there'll be increased demand for languages like Bluespec, which IIRC allow you to specify hardware and code that runs on that hardware in a single language. I believe Bluespec is similar to Haskell, so it might not be too hard for Haskell programmers to pick up. Could argue that Python has similar capabilities, perhaps PyHDL will move in this direction too.

Is it possible to switch the overlays from within a program while the program is running on the board?

Or do you have to do the overlay switching from an external system?

You can do it live, there is a device node you cat the bitstream to. You will also need coordination with any drivers for that hardware, of course.

Reply on news.ycombinator.com