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

31–40 of 44 posts

Re: Turning .NET assemblies into FPGA hardware

#31

Post by zoltanlehoczky »

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…

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!

Re: Turning .NET assemblies into FPGA hardware

#32

Post by zoltanlehoczky »

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…

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)?"

Re: Turning .NET assemblies into FPGA hardware

#33

Post by [deleted] »

zoltanlehoczky wrote: post #32
Traster wrote: post #9

Earlier quoted context omitted.

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…

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)?"

[deleted]

Re: Turning .NET assemblies into FPGA hardware

#34

Post by rowanG077 »

willis936 wrote: post #27
Traster wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Turning .NET assemblies into FPGA hardware

#35

Post by willis936 »

rowanG077 wrote: post #34
willis936 wrote: post #27

Earlier quoted context omitted.

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.

Re: Turning .NET assemblies into FPGA hardware

#36

Post by rowanG077 »

willis936 wrote: post #35
rowanG077 wrote: post #34

Earlier quoted context omitted.

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 lin…

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

Re: Turning .NET assemblies into FPGA hardware

#37

Post by zoltanlehoczky »

zoltanlehoczky wrote: post #29
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 th…

And regarding Nexys: now we actually support Microsoft Catapult FPGAs as well and working on others too. It's quite challenging to add support for each of them, since as I'm sure you're aware, HLD is nowhere near as portable, especially between manufacturers, than software. Also, while if you know an HDL like VHDL then you can write code for all FPGAs, but keep in mind that you also have to write code compatible with each FPGA specifically (with major differences being at least between product families). With a high-level approach like Hastlayer, you get multi-FPGA support for free, i.e. your code won't change. It narrows your options hardware-wise but it's much simpler. It's a question of trade-offs and depends on what is most suitable for you.

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.

Re: Turning .NET assemblies into FPGA hardware

#39

Post by tverbeure »

SlowRobotAhead wrote: post #22
tverbeure wrote: post #8

Earlier quoted context omitted.

"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…

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.

Re: Turning .NET assemblies into FPGA hardware

#40

Post by vmchale »

dhash wrote: post #21
vmchale wrote: post #10

Earlier quoted context omitted.

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

Post reply on HN