Hacker News Reader

Comment by nikofeyn | Hacker News Reader

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

View on HN

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.

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.

I really disagree with this. HDLs are exactly like other programming languages. What in your mind makes HDLs fundamentally different to software languages? Your point about netlists doesn't convince me at all since you aren't creating netlists with a HDL. A description written in a HDL can be turned into a netlist.

Have you ever worked with HDLs before? The thing you are working on Is a netlist, not abstract code. As the name implies, you are describing hardware rather than abstract software. The layers of abstraction are ones that are built by the programmer (or defined in hardware block libraries) rather than ones from a language. HDLs do not have a single entry point. Every line of code runs concurrently with every other line of code. It simply is not like typical programming.

Yes I have used HDLs. You are working on a creating a hardware configuration. But you are not writing a netlist. That is like saying when you are writing a software program that you are "working on the machine code". The only difference between a HDL and "software" languages is a different set of restrictions. Every software language/framework or whatever also has unique restrictions. The restrictions HDLs have are not in any significant way tangibly different then those that exist in the software land.

You have software languages as well where "every line of code runs concurrently". Any dataflow framework for instance. That's not even to name functional languages where evaluation of statements can be done completely in parallel based on data dependencies.

Software is a lot more then the old c style run a program line by line until it hits the end of main().

I agree with the tooling issue. One of the reason we started Hastlayer was the viewpoint that "I'm a .NET developer with Visual Studio and everything else. Why would I want to use this thing created by Xilinx/Altera (Intel)?"

> 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

I believe Clash has industrial users as well.

There are a few businesses that use Haskell to target FPGAs.

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/

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

Xilinx is all in on high level synthesis. Although they are focusing on C++ and python instead of functional languages.

I'm kind of surprised. I get that Haskell/ML may not be the best-known, but even an original functional language is better than spamming pragmas on for loops

You can target any FPGA. Clash compiles to VHDL or Verilog.

> it's really gonna take xilinx or altera to innovate in this space, but that is unlikely any time soon.

I think people already use Clash/Haskell to write HDL.

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.

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.

When you program in C, the knobs that you’re setting are the bits of a file or flash memory.

When your program in Verilog, the knobs are the bits of a bunch of LUTs.

Insisting to call it configuration is not only pedantic. It is also not used this way by anybody else. And it’s confusing because it overloads a term that is used universally by all FPGA tools.

It’s hard to see how that makes it any different than just wrong.

Imagine the following conversation in isolation:

“Hey John, what are doing today?” - “I’m configuring my FPGA!”

Ask anyone in the field what is being described above. I guarantee you that nobody would answer that John is writing RTL.

Reply on news.ycombinator.com