
Turning .NET assemblies into FPGA hardware - victor82
https://github.com/Lombiq/Hastlayer-SDK
======
Traster
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 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.

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

~~~
The_rationalist
_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.

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

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

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

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

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

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

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

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

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

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

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

Also concurrency! GPU is SIMD; FPGA need not be.

~~~
zoltanlehoczky
Yes, FPGA "threads" much like CPU threads can contain complex logic, and
different from each other.

------
mehrdadn
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](https://m-labs.hk/artiq/manual/introduction.html)

~~~
fsh
ARTIQ is a framework for real-time control of atomic physics experiments.
Probably you were thinking of migen
([https://github.com/m-labs/migen](https://github.com/m-labs/migen)) which is
used to implement ARTIQ.

------
phendrenad2
Note that this github project is only the PC host code for your FPGA. The
actual .NET-to-FPGA translation code isn't open-sourced.

