4 ms·
Interesting. Seems like it would be a big performance gain for e.g. Facebook to convert all their networking/server code to silicon. Obviously has drawbacks lik
by lwb 7y ago
Interesting. Seems like it would be a big performance gain for e.g. Facebook to convert all their networking/server code to silicon. Obviously has drawbacks like decreased speed of deployment and whatnot but it sounds like something that could be huge one day.
- sansnomme 7y agoIf you do not understand FPGAs, then C++ to VHDL/Verilog is lipstick on a pig at best. Here's the thing: Knowing VHDL/Verilog will not: - Get you a job with compensation on the same level as ML/Web Dev. - Magically make your tech/startup work better - Fulfill buzzword requirements for investors These sort of low level tooling is tremendously difficult to make profitable unless you already have some sort of vendor lock-in i.e. silicon, or an application that is extremely demanding in terms of efficiency or speed e.g. High Frequency Trading, network switches, dot-product-machines (commonly known as ML) and crypto hardware. Unfortunately any other applications for FPGAs tend to closely related to the embedded space (robotics, aerospace) and again it's significantly more annoying to monetize compared to e.g. a SaaS oriented around ML. Especially so it you are not a massive corporation with deep pockets. The closest we have come to a high level tool for FPGA synthesis is reconfigure.io but they got acquired and is now effectively dead. CPUs and ASICs have become too powerful and too cheap. Even with Moore's law tapering off, the gains provided by FPGAs are still too narrows. Electrical engineers are cheap. Physics have not changed much in recent decades. A couple computer architecture courses is more than enough to bring an EE graduate up to speed (referring to FPGAs here, ASICs are another story)
- mereel 7y agoSadly you can't synthesize any old piece of C++, there are a ridiculous amount of constraints and you need to write the code in a very specific way. Also there's not necessarily much of a performance gain, some tasks are not good candidates for being implemented in hardware (as a general rule you need a lot of parallelism to make it worth it). As an overly simple example, implementing hardware RSA and hoping for a significant speedup doesn't make sense because there isn't really much parallelism and it's usually only used to encrypt keys, but something like AES or SHA might benefit from a good hardware implementation because there is much more parallelism to be had and they are used to encrypt much larger amounts of data. To add even more complexity, the compilers can be obscenely finicky with optimizations.
- derefr 7y agoSo, it's less that you're writing C++ and synthesizing it, and more like you're maintaining a VHDL codebase that happens to be presented/edited "through" C++.
- jlokier 7y agoThat's a fair description. Even so, with VHDL being rather verbose you might prefer the "C++ skin on VHDL" version for some things, especially algorithmic things.
- mereel 7y agoDefinitely, some code is much more readable/clean in C++, while still compiling to reasonable VHDL. Also templates let you create fairly complex blocks programmatically at compile-time, Verilog doesn't have the same metaprogramming facilities that C++ offers.
- WilliamEdward 7y agoThat sounds awful, what about bugs?
- xvilka 7y agoC++ is a poor fit for this. Proper high-level HDLs are better to understand and work with. Mentioned in the neighbor commment Clash[1], Chisel[2]/FIRRTL[3], Hardcaml[4], Spatial[5], various Python-based languages, there many[6]. [1] https://clash-lang.org/ https://clash-lang.org/ [2] https://www.chisel-lang.org/ https://www.chisel-lang.org/ [3] https://www.chisel-lang.org/firrtl/ https://www.chisel-lang.org/firrtl/ [4] https://github.com/janestreet/hardcaml https://github.com/janestreet/hardcaml [5] https://spatial-lang.org/ https://spatial-lang.org/ [6] https://github.com/drom/awesome-hdl https://github.com/drom/awesome-hdl
- pjmlp 7y agoWhile I agree, CodePlay, Khronos, Intel, and LLVM think otherwise with their SYSCL, oneAPI and LLVM bitcode to FPGA ongoing projects.