The thing is, I don't believe that transformation is a solvable problem (not least because really clever people keep trying and keep releasing terrible attempts). In real life, people program GPUs using special constructs and instructions. Hell, they use special instructions for the vector operations on CPUs. So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA? What you end up with a tiny subset of the language that maps to already existing hardware languages with a little bit of syntactic sugar and a boat load of misunderstanding of the limitations.
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.
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!
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.
also, i don't really understand how moving something that is compute bound down to an FPGA is what you do. FPGAs are slow compared to CPUs. where they help is if you have something that can be parallelized and/or you want it to happen in a real-time manner.
it would be a big win if there was a more modern HDL language. VHDL actually has a lot of nice features. however, i think a cross with it and an ML language (like F# or OCaml) would be a wonderful fit for programming FPGAs, that is designing (or at least dictating) hardware with software.
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.
Sounds like Clash! It's pseudo-Haskell that compiles to Verilog or VHDL.
If you want to go really bonkers, there’s spatial-lang which allows easy interop with the Java memory model and heap
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.
mmult mA mB = result
where
mBT = transpose mB
dot a b = sum $ zipWith (*) a b
result = map (\ar -> dot ar <$> mBT) mA
either way, this is along the right lines. however, what FPGAs can you target? any xilinx chips?it's really gonna take xilinx or altera to innovate in this space, but that is unlikely any time soon.
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.
You program what needs to go into the FPGA by writing RTL, then you synthesizes the RTL, then you configure them at powerup time.
This subject of this topic is about using .NET as an alternative to traditional RTL languages. That's programming. If you're going to call that configuration, you're overloading a term "configuration" in a way that nobody in the FPGA industry ever does.
Can someone tell me what this would actually be used for? I'm sitting here scratching my head.
[0] > Currently only the Nexys 4 DDR board (which is NOT the same as the non-DDR Nexys 4, be sure to purchase the linked board!) is supported, so you'll need to purchase one. 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.
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 :).
Regarding size limitations: check out the samples on what you can fit on a low-end FPGA with Hastlayer, it's not that small. FPGAs that are more suitable as actual compute accelerators have 5-10x the logic resources (and much more) than the Nexys in question.
Also concurrency! GPU is SIMD; FPGA need not be.