Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turning .NET assemblies into FPGA hardware

github.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Turning .NET assemblies into FPGA hardware

#21

Post by dhash »

vmchale wrote: post #10
nikofeyn wrote: post #2

i wouldn't really call this programming FPGAs with .NET languages. it's more just converting .NET code to run on FPGAs. those are two different things. 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 b…

> 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.

Or Chisel (Scala), which has real, industrial users and a thriving commmunity. RISC-V is in Chisel.

If you want to go really bonkers, there’s spatial-lang which allows easy interop with the Java memory model and heap

Re: Turning .NET assemblies into FPGA hardware

#22

Post by SlowRobotAhead »

tverbeure wrote: post #8
SlowRobotAhead wrote: post #5

Earlier quoted context omitted.

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.

"From a correctness point of view you don’t program for FPGAs at all. You 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…

I disagree.

Programming is setting the knobs on the machine, working with an existing structure to get a job done.

Configuring an FPGA is laying out the machine. You are designing the hardware gates and building the structure.

You could argue it’s pedantic, sure. But I think that’s 90% of the reason people struggle with FPGA is they look at it like programming and not hardware design. I was explained this difference by people in the FPGA reverse engineering industry.

So, no to the topic, I still see zero reason to use a .NET programming language to shoehorn how you want mostly non-procedural hardware logic to function. Other than to say you did it and write an article about it.

Re: Turning .NET assemblies into FPGA hardware

#23

Post by SlowRobotAhead »

Traster wrote: post #12

FPGAs are fundamentally a dataflow system. You have geographically distributed compute units, with reconfigurable routing. CPUs (obviously) work by bringing the data to a single fixed central processing unit. So the key question for all these software->FPGA tools, is how they handle this transformation. The problem is that often the way you layout your program is introducing implicit constraints that prevent optimiza…

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.

Re: Turning .NET assemblies into FPGA hardware

#24

Post by pjmlp »

bsder wrote: post #20
The_rationalist wrote: post #15

Earlier quoted context omitted.

Rust is really the first example of "Managing state is pain in the ass--maybe we need to rethink this" There was Ada decades ago. I could also say react... The word that you use: state is too vague to my taste.

> There was Ada decades ago. Which then morphed into VHDL on hardware. So, fair point. I really don't understand why Ada never caught on and I don't understand why it isn't getting a renaissance. > The word that you use: state is too vague to my taste. I chose "state" explicitly because it encompasses volatile memory, data persistence (file systems and the like), connections between things, etc. All of these things h…

Ada never caught on for several reasons:

The compilers were priced in values totally out of reach for most mortals, which ended up buying Modula-2 or Pascal compilers instead.

On UNIX systems, it meant buying an additional compiler beyond the C one that was already on the box. When UNIX SDKs became commercial, you had to buy two (UNIX SDK + Ada), which was even less appealing.

C++ was still coming into the world, and most compiler vendors though that Ada was impossible to be fully implementable and thus never bothered. Ironically, Ada compilers are much simpler than C++ ones.

Finally nowadays from around 6 surviving compiler vendors, only GNAT is community friendly (in spite of the usual license discussions), the remaining ones keep selling their compilers at enterprise prices (talk first with the sales team way).

So it is hard to get mass adoption this way.

Re: Turning .NET assemblies into FPGA hardware

#25

Post by msla »

bsder wrote: post #19
jacobush wrote: post #16

Earlier quoted context omitted.

Ehm, functional languages do too by avoiding state as much as possible. See https://clash-lang.org

Functional languages somewhat avoid shared or implicit state by making you pass everything in and then create something new on the way out. That's a LOT of state even if it isn't shared. At some point, what went in and what went out needed to get stored by somebody . Thus leading to the old Perlis adage "LISP programmers know the value of everything and the cost of nothing."

> Functional languages somewhat avoid shared or implicit state by making you pass everything in and then create something new on the way out.

Dataflow, in other words. You pass data through functions, and you know the whole thing works because the functions are composable because they aren't doing anything off to the side. No side-effects means you can think in a pipeline data flows through.

Spreadsheets achieve this quite nicely, and are the only successful visual programming language (pacem Microsoft's use of "Visual" as a marketing term for their decidedly text-based Visual Basic and Visual C++) in addition to being the forgotten programming paradigm, or at least the one most likely to be pointedly ignored.

Some of this might even have relevance for creating FPGAs based on dataflow models.

Re: Turning .NET assemblies into FPGA hardware

#26

Post by fsh »

mehrdadn wrote: post #11

There's also something called ARTIQ which I'm told allows high-level programming of FPGAs as well. I'm not familiar with it but it may be interesting for others: https://m-labs.hk/artiq/manual/introduction.html

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.

Re: Turning .NET assemblies into FPGA hardware

#27

Post by willis936 »

Traster wrote: post #9
nikofeyn wrote: post #2

i wouldn't really call this programming FPGAs with .NET languages. it's more just converting .NET code to run on FPGAs. those are two different things. 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 b…

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…

In defense of the poor hardware engineer: HDLs are not like other programming languages. You are literally writing a netlist of a circuit. Hardware engineers are hired to write FPGA code because it is a hardware design problem, not a software one.

Re: Turning .NET assemblies into FPGA hardware

#28

Post by zoltanlehoczky »

nikofeyn wrote: post #2

i wouldn't really call this programming FPGAs with .NET languages. it's more just converting .NET code to run on FPGAs. those are two different things. 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 b…

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.

Re: Turning .NET assemblies into FPGA hardware

#29

Post by zoltanlehoczky »

eyegor wrote: post #13

I love playing with fpgas, but the compile time and size limitations are always horrendous or simply not tenable for most applications. This library narrows that down to be even worse [0]. On most of alteras chips you'd be hard pressed to fit a few of their own filter libraries, let alone your own code. Honestly I'm not sure what you would use a tool like this for. If you want asic development, you will likely need t…

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 :).

Re: Turning .NET assemblies into FPGA hardware

#30

Post by caspper69 »

bsder wrote: post #20
The_rationalist wrote: post #15

Earlier quoted context omitted.

Rust is really the first example of "Managing state is pain in the ass--maybe we need to rethink this" There was Ada decades ago. I could also say react... The word that you use: state is too vague to my taste.

> There was Ada decades ago. Which then morphed into VHDL on hardware. So, fair point. I really don't understand why Ada never caught on and I don't understand why it isn't getting a renaissance. > The word that you use: state is too vague to my taste. I chose "state" explicitly because it encompasses volatile memory, data persistence (file systems and the like), connections between things, etc. All of these things h…

Ada would do better if they adopted a cleaner and more c-like syntax. It's just ugly, and people don't want to write it. But it is awesome!
Post reply on HN