Turning .NET assemblies into FPGA hardware (opens in new tab)

As to the optimization and the user not being able to and/or not having the tools to do it.

This was one of my favorite uses for ML. However the specific result i remember wasn’t that useable. The short version was they asked a model to program this FPGA to make a 1khz sin wave on a pin hooked to a speaker by listening to the result. It eventually worked, and the FPGA did indeed output a 1KHz wave. But... when the logic gates set in the FPGA were examined it was nonsense. And it wouldn’t work on any other chip. It was using defects in the silicon and was truly a one off success.

Obviously this optimization is only possible for a machine but yes, the tools from high level to bitstream could be a ton better.

The transformation is surely a solvable problem given that various HLS tools, OpenCL for FPGAs and Hastlayer exist :). Whether it makes sense is another question and I don't pretend to have the definitive answer, though I believe it does: abstractions can increase productivity with trade-offs like the runtime efficiency of the implementation.

In this case I think in certain use-cases it has value to use the standard .NET parallel programming model and development workflow to get not an optimal but a good enough hardware implementation. The point is to get a performance and power efficiency increase, and with Hastlayer this is possible for certain algorithms with the fraction of the knowledge and time (i.e. cost) required to even begin being productive with HDL languages. Whether this is the best approach for a given task depends on its context.

We'll see, and in the meantime we keep working on experimental approaches like Hastlayer. Feedback like yours really helps, so thank you!

> So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA?

Because software people have never paid a cost for state in their programming.

Software folks are so poor at managing state that some clever people actually built entire languages around that fact (garbage collection).

I'm optimistic though--Rust is really the first example of "Managing state is pain in the ass--maybe we need to rethink this" that exists in programming languages. I suspect more are to follow.

I don't think the languages are the real problem. It's the tooling that sucks. The fact that simulation generally comes from a different vendor to the synthesis means that the simulation environment will implement the behaviour of the language, not the behaviour of the target device. This means you can never verify your design without a full hardware test - at which point you can't probe signals. That could be fixed if someone simulated devices accurately rather than simulating the specification of the language. This is exacerbated by synthesis warnings that range from "I one hot encoded your state machine as has been common since 1984" to "Yo dawg you forgot to reset this signal, so the set and reset priority are unclear, I'm gunna just fuck the whole of your design for ya". We all enjoy those post-synthesis log parsing scripts! By the way - they can't fix the logging because Cisco/Nokia/DoD have spent decades parsing those logs and if you change them you'll break their workaround.

Secondly, because the people who understand FPGAs are hardware engineers the tool vendors hire hardware engineers (and software engineers who are willing to tolerate hardware engineers) to write their software, the result is tools written using the development practices of the dark ages.

End of rant.

> i think a cross with it and an ML language (like F# or OCaml) would be a wonderful fit for programming FPGAs

Sounds like Clash! It's pseudo-Haskell that compiles to Verilog or VHDL.

Yes, it's converting .NET code to run on FPGAs by creating an equivalent hardware design to the logic contained in the .NET code.

And yes, it's all about parallelization. As the docs also say, this only makes sense if your algorithm is embarrassingly parallel. If you check out the examples are like this too (within the limitations of a small FPGA).

BTW "programming" an FPGA in my understanding is the process of flashing the bitstream onto the board.

Please take a look at clash[1]. You can design digital circuits using Haskell and all the fancy language features Haskell has. It doesn't have a story for interop between the software world though. I love using it!

[1] https://clash-lang.org/

From a correctness point of view you don’t program for FPGAs at all. You configure them.

So, other than a headline I’m not seeing any advantage over Verilog or VHDL to consider this at all. I think there is a much larger issue in people not understanding FPGAs than the code used to configure them.

The approach here is to use FPGAs as compute accelerators, much like GPGPUs, and in somewhat similar use-cases. I.e. if you have an embarrassingly parallel compute-bound algorithm then it might make sense to offload it to FPGAs to gain performance and power efficiency.

Keep in mind that the target audience is not hardware engineers but .NET software developers. If you know what Altera libraries are then you're not the target audience :).

Hardware like fpgas peaked in the 90s as a value proposition. The future is algorithmic and abstract from hardware.

Overpriced defense contracts. Other than that, nothing.

ARTIQ is a framework for real-time control of atomic physics experiments. Probably you were thinking of migen (https://github.com/m-labs/migen) which is used to implement ARTIQ.