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.
Theres a python in the .NET as well, so even if you prefer that you can use this.
Unlikely, it is a very limited subset of .NET that is supported, IronPython is relying on a much wider subset to run.
I got that from the hastlayer webpage though. Anything that compiles to the intermediate language should work. Again according to the hastlayer webpage.
In theory, potentially, this might be the case. In practice, virtual calls and recursion are not supported (and for a good reason), and even to access RAM you need to use special methods.
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
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
Sorry for double-posting, my initial comment didn’t appear even after refreshing and waiting a lot so I figured it got lost.
This is a cool project, pity it seems abandoned now.
I’m working on an open source HLS toolchain too, primarily targeting high performance computing. There is a C-like intermediate language, but the toolchain itself is very tightly integrated with .NET. Feel free to check it out:
https://github.com/combinatorylogic/soc
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?
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.
It’s not abandoned :). But indeed not much have been done in the default branch, but work is ongoing here: https://github.com/Lombiq/Hastlayer-SDK/tree/dev
Great! I wish github had a better way of highlighting active branches…
Yeah… Thanks for staring Hastlayer BTW! Your CLike project seems interesting too.
I’m not entirely sure who is rolling over in their graves. But I’m predicting seismometers around the world are pegging out.
Would you like to elaborate, Alan? :)
I literally did this in college 14 years ago, first with Java, then we moved to .NET
http://www.cse.secs.oakland.edu/hanna/research.asp
That’s pretty cool! Do you have a link to a more recent publication or project page?
Lead dev of Hastlayer here. Thanks for the article Al! I’d add that we now also have support for the much higher performance FPGAs of Microsoft’s Project Catapult (https://www.microsoft.com/en-us/research/project/project-catapult/). Not yet released though, but we expect it within days!