3 ms·

> Even RTL experts probably don’t believe that Verilog is a productive way to do mainstream FPGA development. It won’t propel programmable logic into the mainst

> Even RTL experts probably don’t believe that Verilog is a productive way to do mainstream FPGA development. It won’t propel programmable logic into the mainstream. RTL design may seem friendly and familiar to veteran hardware hackers, but the productivity gap with software languages is immeasurable. The author seems to view "mainstream" as meaning being as easy as CPU or GPGPU programming. I don't think it makes much sense trying to accomplish this on FPGAs; you're better off using CPUs, GPUs, or making something domain-specific like TPUs. The benefit of FPGAs is that they allow you to build your own architecture, and define data movement in a way that is specific to your application, at the cost of increased development effort. The complexity encountered in doing RTL arises from the inherent complexity in using FPGAs effectively. There is a case to be made for something in between a CPU and an FPGA that allows easier development, but gives you some ability to control your data movement to get higher performance. Processor meshes, like what Xilinx is including with their upcoming Versal chips, might be a good solution to this (though in typical FPGA vendor fashion this too is locked behind proprietary tooling).

Retric 7y ago
Compilers can get quite good at optimization problems. The trick is finding an abstraction that hides details in just the right way that compilation can result in something about as good as hand optimized code in 1/10th the developer time.
- dooglius 7y ago
  If you could come up with a better abstraction, it would probably be better to build a new genre of computation device around that abstraction, rather than sticking with FPGAs.
  - ncmncm 7y ago
    Good luck getting anybody to build them. FPGAs suck, but exist. Existence is worth more than a thousand good architectures. Similarly, GPUs. When enough people abused them, they started evolving toward what the abusers actually needed. A decent abstraction would lead to FPGAs more useful for things other than emulating ASICs. But it has to come first.
kuzehanka 7y ago
GPUs have become immensely popular and helpful in many real-world use cases. This happened in a fraction of time that FPGA had to find a useful niche in the market. As a mostly outsider to the FPGA world, I conclude one of two is true: 1: FPGA performance gain is not meaningfully better than GPU 2: FPGA are so difficult to make efficient use of that the performance gain is seldom realized Which ever the case may be, GPGPU has significantly advanced the HPC space and FPGA has not. I don't see that ever changing unless one of the underlying variables changes. 2 years ago I saw a talk at a big-name conference about FPGA-accelerated SQL-like queries, it seemed cool, it was talked up as the next big thing in the data science space. I've never heard of it since that time, meanwhile we now have full SQL compliant GPGPU solutions. I'm not hung up on SQL or HPC, but it looks like FPGA never found anything it's truly great at while GPGPU has - across multiple domains.
- sgregnt 7y ago
  Acceleration is only some part of what FPGA do. But it sounds like you imply it is the only purpose of FPGA, it is far from it. How GPU are used in chip prototyping? Or in safety critical designs? Can GPU implement fast proprietary interface or protocol parsing?
- karmakaze 7y ago
  I think that both GPGPU and FPGA are areas of development and exploration with different types of focus on the hardware and software. Both are important and will lead to other forms (e.g. TPU NNs). I can easily see FPGA SQL queries working well and being further optimized into a more specific QPU since the scale of the problem pays for development of efficiency gains.
wwwigham 7y ago
> I don't think it makes much sense trying to accomplish this on FPGAs; you're better off using CPUs, GPUs, or making something domain-specific like TPUs. I dunno, we have a lot of libraries and frameworks who make it their purpose to efficiently run code on either a CPU or GPU (or TPU, if we're talking about things like tensorflow); a FPGA is conceptually just an extension of that except, ofc, that on-the-fly FPGA recompilation usually outweighs any performance benefits you'd get from using the FPGA based hardware accelerator, so the only reasonable uses are one and done layouts with occasional patches/updates. If we could get an FPGA gate pipeline that was as efficient as the modern shader pipeline, I think what we could use them for could expand greatly - imagine a tracing JIT that could dynamically load hot sequential code into an FPGA to speed it up, the same way we can load matrix ops into a GPU today. With where FPGA toolchains are today, it just doesn't work _because_ the compilation process is so bad and slow, and nobody except the engineers within Xilinx and Altera even have a reasonable shot at making it better since both the compiler and the compilation target are closed. Part of it is simply that these compilation passes aren't really configurable (beyond expressing layout and pipelining preference) - if I could get near instant bitstream generation in exchange for 30% extra space used, I'd use that setting for all but my final builds, and strongly consider invoking it at runtime.
- TBF-RnD 7y ago
  I've been thinking about this for so long! I believe Intel did research on it with possible results. Are you interested in pursuing it?
- LargoLasskhyfv 7y ago
  Hm. Are you aware of [1] https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/ & [2] https://blog.netbsd.org/tnf/entry/support_for_microsoft_emips_extensible https://blog.netbsd.org/tnf/entry/support_for_microsoft_emip... ? Especially the two papers which come up when you search like this? [3] https://duckduckgo.com/?q=microsoft+extensible+mips https://duckduckgo.com/?q=microsoft+extensible+mips MIPS-to-Verilog, Hardware Compilation for the eMIPS Processor Karl Meier, Alessandro Forin Microsoft Research September 2007 Technical Report MSR-TR-2007-128 Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2007-128.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and EXTENSIBLE MICROPROCESSOR WITHOUT INTERLOCKED PIPELINE STAGES (eMIPS), THE RECONFIGURABLE MICROPROCESSOR A Thesis by RICHARD NEIL PITTMAN Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE May 2007 Major Subject: Computer Engineering [5] https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/5976/etd-tamu-2007A-CECN-Pittman.pdf https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/59...

Retric 7y ago

Compilers can get quite good at optimization problems. The trick is finding an abstraction that hides details in just the right way that compilation can result in something about as good as hand optimized code in 1/10th the developer time.

dooglius 7y ago
If you could come up with a better abstraction, it would probably be better to build a new genre of computation device around that abstraction, rather than sticking with FPGAs.
- ncmncm 7y ago
  Good luck getting anybody to build them. FPGAs suck, but exist. Existence is worth more than a thousand good architectures. Similarly, GPUs. When enough people abused them, they started evolving toward what the abusers actually needed. A decent abstraction would lead to FPGAs more useful for things other than emulating ASICs. But it has to come first.

kuzehanka 7y ago

GPUs have become immensely popular and helpful in many real-world use cases. This happened in a fraction of time that FPGA had to find a useful niche in the market. As a mostly outsider to the FPGA world, I conclude one of two is true: 1: FPGA performance gain is not meaningfully better than GPU 2: FPGA are so difficult to make efficient use of that the performance gain is seldom realized Which ever the case may be, GPGPU has significantly advanced the HPC space and FPGA has not. I don't see that ever changing unless one of the underlying variables changes. 2 years ago I saw a talk at a big-name conference about FPGA-accelerated SQL-like queries, it seemed cool, it was talked up as the next big thing in the data science space. I've never heard of it since that time, meanwhile we now have full SQL compliant GPGPU solutions. I'm not hung up on SQL or HPC, but it looks like FPGA never found anything it's truly great at while GPGPU has - across multiple domains.

sgregnt 7y ago
Acceleration is only some part of what FPGA do. But it sounds like you imply it is the only purpose of FPGA, it is far from it. How GPU are used in chip prototyping? Or in safety critical designs? Can GPU implement fast proprietary interface or protocol parsing?
karmakaze 7y ago
I think that both GPGPU and FPGA are areas of development and exploration with different types of focus on the hardware and software. Both are important and will lead to other forms (e.g. TPU NNs). I can easily see FPGA SQL queries working well and being further optimized into a more specific QPU since the scale of the problem pays for development of efficiency gains.

wwwigham 7y ago

> I don't think it makes much sense trying to accomplish this on FPGAs; you're better off using CPUs, GPUs, or making something domain-specific like TPUs. I dunno, we have a lot of libraries and frameworks who make it their purpose to efficiently run code on either a CPU or GPU (or TPU, if we're talking about things like tensorflow); a FPGA is conceptually just an extension of that except, ofc, that on-the-fly FPGA recompilation usually outweighs any performance benefits you'd get from using the FPGA based hardware accelerator, so the only reasonable uses are one and done layouts with occasional patches/updates. If we could get an FPGA gate pipeline that was as efficient as the modern shader pipeline, I think what we could use them for could expand greatly - imagine a tracing JIT that could dynamically load hot sequential code into an FPGA to speed it up, the same way we can load matrix ops into a GPU today. With where FPGA toolchains are today, it just doesn't work _because_ the compilation process is so bad and slow, and nobody except the engineers within Xilinx and Altera even have a reasonable shot at making it better since both the compiler and the compilation target are closed. Part of it is simply that these compilation passes aren't really configurable (beyond expressing layout and pipelining preference) - if I could get near instant bitstream generation in exchange for 30% extra space used, I'd use that setting for all but my final builds, and strongly consider invoking it at runtime.

TBF-RnD 7y ago
I've been thinking about this for so long! I believe Intel did research on it with possible results. Are you interested in pursuing it?
LargoLasskhyfv 7y ago
Hm. Are you aware of [1] https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/ & [2] https://blog.netbsd.org/tnf/entry/support_for_microsoft_emips_extensible https://blog.netbsd.org/tnf/entry/support_for_microsoft_emip... ? Especially the two papers which come up when you search like this? [3] https://duckduckgo.com/?q=microsoft+extensible+mips https://duckduckgo.com/?q=microsoft+extensible+mips MIPS-to-Verilog, Hardware Compilation for the eMIPS Processor Karl Meier, Alessandro Forin Microsoft Research September 2007 Technical Report MSR-TR-2007-128 Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2007-128.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and EXTENSIBLE MICROPROCESSOR WITHOUT INTERLOCKED PIPELINE STAGES (eMIPS), THE RECONFIGURABLE MICROPROCESSOR A Thesis by RICHARD NEIL PITTMAN Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE May 2007 Major Subject: Computer Engineering [5] https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/5976/etd-tamu-2007A-CECN-Pittman.pdf https://oaktrust.library.tamu.edu/bitstream/handle/1969.1/59...