.NET To FPGA With Hastlayer

There are lots of ways to use FPGAs. One way is to convert compute-bound software into hardware. This can increase speed and — in some cases — reduce power consumption. Typically, you’ll do this by writing in a subset of C, but Hastlayer can convert .NET assemblies into FPGA configurations with some limitations.

The Hungarian company behind Hastlayer claims they’ll eventually have to charge money for something but for now, the tool is free and they are promising to always have some free option. The interesting thing is that the .NET assemblies are essentially object code so you aren’t compiling source but rather an intermediate language that you can generate with many different language tools.

The actual compilation occurs on remote servers, so some people aren’t going to like that. However, at least you aren’t loading your source code, just the DLLs. The tool targets the Nexys 4 DDR board which is apparently now the Nexys A7 board. This board is only $265, but it is frankly a little anemic for the kinds of things you’d typically want to do with FPGA acceleration. In the getting started guide they even say:

Note that this is a relatively low-end development board that can’t fit huge algorithms and it only supports slow communication channels. So with this board Hastlayer is only suitable for simpler algorithms that only need to exchange small amount of data.

Presumably, they will eventually support bigger hardware.

There are, of course, limitations. Only public virtual methods or methods that implement a method defined in an interface will have hardware entry points. Not all data types are available. Some methods like Array.Copy have limited function. There are no exceptions and recursion has some limitations, too.

Still, if you are adept at .NET and want to get into FPGA coprocessing this could be just the thing.  If you prefer C, there’s a tool for that. Or maybe you prefer Python.

18 thoughts on “.NET To FPGA With Hastlayer

          1. Yes, apart from C# the rest of .NET is a theory for now. In principle since Hastlayer processes .NET assemblies every .NET language should work, in practice due to the difference in compilers we need to support the quirks of each of them; this, however, is relatively straightforward is the code otherwise just uses what Hastlayer supports. We actually have an F# sample here: https://github.com/Lombiq/Hastlayer-SDK/blob/dev/Samples/Hast.Samples.FSharpSampleAssembly/FSharpParallelAlgorithmContainer.fs

          2. Yes, while in theory all .NET languages can be used in practice all their compilers have quirks that we need to individually support. Apart from these most of the common processes will just understand the decompiled code and thus supporting a new language is relatively straightforward if there is a desire for it. We have done it for F#, here’s a simple sample: https://github.com/Lombiq/Hastlayer-SDK/blob/dev/Samples/Hast.Samples.FSharpSampleAssembly/FSharpParallelAlgorithmContainer.fs

    1. I used HandelC donkeys years ago. It always seemed a bad idea – it promoted linear thinking when coding, rather than the parallel paradigm hardware demands. Has this been worked around some way in the newer approaches?

      1. You cannot replace HDLs with any HLS approach. What you can do though is using HLS as a part of compute acceleration pipeline, for getting a maximum possible performance from naturally linear, unparalleliseable algorithms – that’s exacly my goal here. I’d never suggest, say, implementing a CPU core with anything higher level than a proper HDL.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.