Turning .NET assemblies into FPGA hardware
1–10 of 44 posts
Re: Turning .NET assemblies into FPGA hardware
#2i 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 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.
Re: Turning .NET assemblies into FPGA hardware
#3i 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…
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!
Re: Turning .NET assemblies into FPGA hardware
#4i 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…
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/
i've heard of it before. i'll be honest: i don't much like haskell. for example, this makes me crazy (haha):
mmult mA mB = result
where
mBT = transpose mB
dot a b = sum $ zipWith (*) a b
result = map (\ar -> dot ar mBT) mA
it's really gonna take xilinx or altera to innovate in this space, but that is unlikely any time soon.
Re: Turning .NET assemblies into FPGA hardware
#5i 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…
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.
Re: Turning .NET assemblies into FPGA hardware
#6Earlier quoted context omitted.
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/
i've heard of it before. i'll be honest: i don't much like haskell. for example, this makes me crazy (haha): 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 soo…
Xilinx is all in on high level synthesis. Although they are focusing on C++ and python instead of functional languages.
Re: Turning .NET assemblies into FPGA hardware
#7Earlier quoted context omitted.
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/
i've heard of it before. i'll be honest: i don't much like haskell. for example, this makes me crazy (haha): 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 soo…
You can target any FPGA. Clash compiles to VHDL or Verilog.
Re: Turning .NET assemblies into FPGA hardware
#8i 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…
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" in a way that nobody in the FPGA industry ever does.
Re: Turning .NET assemblies into FPGA hardware
#9i 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 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.
Re: Turning .NET assemblies into FPGA hardware
#10i 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.