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
Turning .NET assemblies into FPGA hardware
11–20 of 44 posts
Re: Turning .NET assemblies into FPGA hardware
#12FPGAs 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 optimization that aren't real but simply an artefact of how you write software.
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.
Re: Turning .NET assemblies into FPGA hardware
#13I 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 to use an hdl for better synthesis. If you want dot net languages, you are going to want a regular cpu.
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.
Re: Turning .NET assemblies into FPGA hardware
#14FPGAs 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…
> So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA?
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.
Re: Turning .NET assemblies into FPGA hardware
#15FPGAs 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…
> So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA? 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 i…
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.
Re: Turning .NET assemblies into FPGA hardware
#16FPGAs 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…
> So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA? 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 i…
Ehm, functional languages do too by avoiding state as much as possible. See https://clash-lang.org
Re: Turning .NET assemblies into FPGA hardware
#17I 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…
Hardware like fpgas peaked in the 90s as a value proposition. The future is algorithmic and abstract from hardware.
Re: Turning .NET assemblies into FPGA hardware
#18I 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…
Overpriced defense contracts. Other than that, nothing.
Re: Turning .NET assemblies into FPGA hardware
#19Earlier quoted context omitted.
> So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA? 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 i…
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."
Re: Turning .NET assemblies into FPGA hardware
#20Earlier quoted context omitted.
> So why are we pretending you can write generic code in languages designed for CPUs and have them run performantly on FPGA? 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 i…
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 have a significant cost when you are designing hardware, memory is often flip flops and highly constrained, data persistence requires a LOT of abstraction to use, connections between things cost time, possibly pins (a limited resource) and possibly an interface specification.
Hardware designers suffer real, genuine pain when a new feature needs to appear--can that fit on the chip, will that affect maximum frequency, did the cost just go up, and only then how long will that take to design and debug.