I think that with architecture design becoming increasingly important in processor performance, and on the heels of Intel-Altera, CPUs or GPUs may gradually add "FPGA-like" aspects, where the configuration of the silicon can be dynamically shifted in order to achieve different tasks.
Personally, I would love to see a day when FPGA coprocessors are a thing, and FPGA companies are big enough to make it happen.
If we look at it from today, some things have changed, but the end result holds true - at least for general purpose computing.
The FPGA vendors (esp Xilinx and Altera) have released devices where the intergration between a hard CPU core and the FPGA is much tighter than using a standardised bus like PCI. This gives a much lower latency. In these devices the CPUs are normally ARM based.
The prevalence of GPUs as PCIe connected coporocessors and OpenCL has also made FPGA based computing connected via PCIe much easier.
One thing that has not improved, but rather worsened is the difference in clock frequency between CPU and FPGA. In Grays posting he talket about PPro running at 200 MHz. Today we have cores running at 2-3 GHz while FPGAs are hard to push beyond 200 MHz.
For applications that are highly parallel, takes a lot of cycles and not suitable for GPU processing, FPGAs might be useful as base for custom coprocessors even for x86, Power, SPARC based servers. But otherwise probably not.
For embedded systems FPGAs makes more sense, but cost of the device and power consumption might make it less so. The integrated SoC devices from Xilinx and Altera can do cool things like media processing, SDR competitively.
The Novena is an example of a modern system where the CPU has access to a FPGA over a low latency interface which makes it useful as a coprocessor. But the Novena is really not built to be cost efficient.
Good write-up as well. I remember there were two things in the past that excited the heck out of me wrt FPGA's. The first were papers in the late 90's or so showing semi-automatic partitioning of an application between a CPU and a FPGA w/ HLS for the FPGA. Their results were pretty cool. I envisioned something like that would be great for the day the FPGA was practically sitting right on the CPU.
The other thing came from my old, favorite, supercomputing vendor: SGI. They used to blow my mind repeatedly with how they did hardware. On the Altix NUMA systems, they had an option called RASC nodes that basically added 2 FPGA's plus QDR RAM to the system. Like everything else, the FPGA's attached to the shared memory bus to operate on whole memory directly with microseconds latency and several GB/s bandwidth. Not sure if modern FPGA's are sitting on the memory bus inexpensively but RASC's performance/integration showed it's a great idea.
So, those were my two fun points on the subject. The next will probably be if I land a Pico Computing desktop w/ some high-end FPGA's or if Archipelago gets closer to mature FPGA architecture. Either have much potential. :)
Zynq from Xilinx uses an AXI bus between the CPU and logic. The first gen ones are not cache coherent between the logic and CPU but I believe UltraScale will be. I don't know much about PCIe, but how is AXI much lower latency?
The real limiting factor of contemporary and future computing systems (from desktop to high performance ones) is power.
The FPGA can give GPU and (especially!!) CPU a run for their money in the area of performance per watt.
The clock frequency gap is not relevant at all. It exists here as a side effect of some old wars between vendors. Some of recent CPU projects for exascale computing specifically reduce CPU frequency, trading it for predictability and reduced latency of operations. Both amount in less wasted cycles and in greater efficiency in the end.
Witness Xeon Phi, for example.
As for embedded devices... I don't know. My friends from embedded world used small FPGAs as a replacement for a lot of standalone logic chips (FPGA reduces set of 74xx chips to one). That's about it.
There have been a few projects to generate VHDL/Verilog using an LLVM backend, a quick google brings up some interesting presentations. I imagine constraints similar to those that the links OP brings up are why these aren't more mainstream.
How come? I guess it would be quite fun if you could write your algorithm with well-defined input/output in a high level language and generate HDL out of it. Let's say you just want to crunch numbers. Today you can use CUDA for that task, but what if you just use a subset of the CUDA features, maybe the compiler might use the gates in the FPGA more efficiently compared with the already defined GPU.
Computational model. C/CUDA have an imperative view of the world which is really hard to boil into hardware. Functional approaches are a much better idea.
The compilation from the imperative world to digital logic is typically pretty opaque. What ends up happening is that the compiler ends up generating shitty hardware, and either you do or don't have a mental model of the hardware you actually want. If you have the mental model, you end up jiggling the C/CUDA compiler into generating the logic you want in lieu of just being able to tell it up front. If you don't have a mental model, making decent hardware is going to suck, and you're probably better off learning an HDL anyway.
A high level functional approach that still recognizes that you're writing hardware is a nice abstraction.
In a high level language? Absolutely. In C? No, thanks. There is a huge semantic mismatch with the highly parallel nature of FPGAs.
A high level language suitable for HDL generation must expose much better abstractions for parallelism. CUDA is just the same thing as C, too bound to the underlying architecture.
I think a high level HDL would be great. C really isn't a good starting point because as you said it doesn't really fit the parallel hardware paradigm. The existing tools that do this feel like they're trying to shoehorn C into this application and it doesn't work too well, because of all the extra information you need to synthesize hardware, e.g. should every iteration of this loop happen simultaneously, or are you making a shift register?
Something that started with a Verilog/VHDL paradigm but provided higher level abstrations would be nice, a good analogy would be something like how Python is to C.
This is actually something I am currently working on. An extensible HDL which allows to gradually add abstraction layers (and operate solely on any chosen level), while keeping an ability to express anything down to gates.
I have not published the language yet, have to produce some nice looking examples first. But you can take a look at my approach to extensibility in general (the HDL language is using exactly the same thing) and some of the earlier mixing Verilog with C experiments here: https://github.com/combinatorylogic
I've been a really big fan of chisel so far. I was very skeptical initially. But the more I got into it, the more I realized that the code=data benefits you get from some functional languages like the Lisps (where Lisp code is also s-expressions and can be parsed and manipulated like any other data) really works well for manipulating your RTL graph.
I've only done a little bit with Xilinx's HLS which allows you to write "C/C++" which gets synthesized to hardware. I put C/C++ in quotes because it relies on lots of pragma directives to tell the complier enough that it can synthesize the hardware that you want, to the point of it almost being its own language entirely, There may be a few applications where this is particularly well suited, but at least for what I was doing, it was easier (and fit my mental model better... ymmv) to do it in HDL.
The easiest way to put it is probably to say that C is just not the right language for a system in which everything happens at once. You use a programming language to tell a CPU what to do, and you use an HDL to tell an FPGA what to be. An ensemble of explicit state machines is a better way to picture it.
If anything, a pure functional or declarative model might be a better starting point for high-level synthesis than a C-like imperative language. But most of the R&D seems to be going in the opposite direction.
To me the biggest viewpoint shift was moving the CPU onto the FPGA instead of the other way around (which was the way we thought it would go for quite a while).
Putting one or more ARM cores on an FPGA is mostly matter of including some lines in a specification file. Putting an FPGA onto a CPU requires a lot of capital and minimum orders that are simply scary.
That was a surprise. I thought they'd put FPGA's onto the CPU's, too, given they were always trying to max interconnect speed and minimize latency. However, we might still get our dream: Intel & Altera merger w/ Intel needing a boost in datacenter performance. They'll do it eventually if they haven't already.
It is a good idea as long as
a. An openly standardized direct-to-PC bus is used
b. An openly standardized interface to co-processor is used (not utilizing blobs).
c. Possibly a transparent to user mixing of CPU and special instructions.
I can think of two apps that can leverage this kind of FPGA+CPU setup.
Heavy duty image processing: Giga pixel images processing - probably mainly for defence related app like this:
https://youtu.be/MVFeMH3ahtw?t=34m45s
Video processing: I used to work on one - 10 years ago. We have 1U system that process feed ip videos in and provide video/decoding/transcoding service. It has 37 Virtex Pro FPGA each with 450Mhz PPC processor inside. It was a very fun project, make some good $ for the startup too. Deploy a lot of them at comcast and other major cable company til some stupid VC impose their own CEO and piss off of the three MIT founders. I think transcoding system probably still be useful for all the internet video datacenter app. FPGA transcoding app can provide real time transcoding service for youtube to a lot resolutions to various phone screen site.
FaceBox, Youtube, Amazon, Netflix can probably use those device/services.
Anyone else can think of any good/interesting applications for FPGA+CPU setup?
Another obvious example that can benefit from the setup is a crypto coprocessor, whereby private keys are side-loaded onto the coprocessor by means of a separate hardware bus, such that the key is never exposed to the CPU or main memory, and the coprocessor can handle all encryption/decryption with said keys.
FPGA+CPU type setup is not cheap to develop or deploy.
Crypto with modern CPU such as pentium works wells. Also almost all the ARM Soc comes with crypto co-processor already with private memory that's not share with main CPU.
The value is not about performance, but security. Crypto done by modern CPUs is susceptible to many side-channel attacks. Having a separate SoC is nice, but the SoC is not upgradable with new algorithms or patches if there are any problems found in its implementation.
Also, just having a separate memory space for the purpose of computation is not sufficient. I'm arguing for an entirely separate hardware bus to load keys onto the chip, such that they never exist in CPU, memory, or the storage for the machine being used for general purpose computation, because keys there can be obtained via side-channels if other software (such as the kernel) is exploited.
A company called Xtremedata Inc used to make an FPGA coprocessor module that plugged into an x86 socket using AMD hyper transport bus. I thought it was cool enough to do my MASc thesis on some potential applications for it:
32 comments
[ 3.3 ms ] story [ 75.9 ms ] threadPersonally, I would love to see a day when FPGA coprocessors are a thing, and FPGA companies are big enough to make it happen.
[1] http://www.extremetech.com/extreme/184828-intel-unveils-new-...
If we look at it from today, some things have changed, but the end result holds true - at least for general purpose computing.
The FPGA vendors (esp Xilinx and Altera) have released devices where the intergration between a hard CPU core and the FPGA is much tighter than using a standardised bus like PCI. This gives a much lower latency. In these devices the CPUs are normally ARM based.
The prevalence of GPUs as PCIe connected coporocessors and OpenCL has also made FPGA based computing connected via PCIe much easier.
One thing that has not improved, but rather worsened is the difference in clock frequency between CPU and FPGA. In Grays posting he talket about PPro running at 200 MHz. Today we have cores running at 2-3 GHz while FPGAs are hard to push beyond 200 MHz.
For applications that are highly parallel, takes a lot of cycles and not suitable for GPU processing, FPGAs might be useful as base for custom coprocessors even for x86, Power, SPARC based servers. But otherwise probably not.
For embedded systems FPGAs makes more sense, but cost of the device and power consumption might make it less so. The integrated SoC devices from Xilinx and Altera can do cool things like media processing, SDR competitively.
The Novena is an example of a modern system where the CPU has access to a FPGA over a low latency interface which makes it useful as a coprocessor. But the Novena is really not built to be cost efficient.
The other thing came from my old, favorite, supercomputing vendor: SGI. They used to blow my mind repeatedly with how they did hardware. On the Altix NUMA systems, they had an option called RASC nodes that basically added 2 FPGA's plus QDR RAM to the system. Like everything else, the FPGA's attached to the shared memory bus to operate on whole memory directly with microseconds latency and several GB/s bandwidth. Not sure if modern FPGA's are sitting on the memory bus inexpensively but RASC's performance/integration showed it's a great idea.
So, those were my two fun points on the subject. The next will probably be if I land a Pico Computing desktop w/ some high-end FPGA's or if Archipelago gets closer to mature FPGA architecture. Either have much potential. :)
Much like CPUs you can't just compare Mhz X to Mhz Y, even moreso considering how parallel FPGAs can get.
There's also been some neat low-power parts lately(from lattice and others).
The FPGA can give GPU and (especially!!) CPU a run for their money in the area of performance per watt.
The clock frequency gap is not relevant at all. It exists here as a side effect of some old wars between vendors. Some of recent CPU projects for exascale computing specifically reduce CPU frequency, trading it for predictability and reduced latency of operations. Both amount in less wasted cycles and in greater efficiency in the end.
Witness Xeon Phi, for example.
As for embedded devices... I don't know. My friends from embedded world used small FPGAs as a replacement for a lot of standalone logic chips (FPGA reduces set of 74xx chips to one). That's about it.
The compilation from the imperative world to digital logic is typically pretty opaque. What ends up happening is that the compiler ends up generating shitty hardware, and either you do or don't have a mental model of the hardware you actually want. If you have the mental model, you end up jiggling the C/CUDA compiler into generating the logic you want in lieu of just being able to tell it up front. If you don't have a mental model, making decent hardware is going to suck, and you're probably better off learning an HDL anyway.
A high level functional approach that still recognizes that you're writing hardware is a nice abstraction.
A high level language suitable for HDL generation must expose much better abstractions for parallelism. CUDA is just the same thing as C, too bound to the underlying architecture.
Something that started with a Verilog/VHDL paradigm but provided higher level abstrations would be nice, a good analogy would be something like how Python is to C.
Edit: System Generator is pretty awesome though!
If anything, a pure functional or declarative model might be a better starting point for high-level synthesis than a C-like imperative language. But most of the R&D seems to be going in the opposite direction.
Putting one or more ARM cores on an FPGA is mostly matter of including some lines in a specification file. Putting an FPGA onto a CPU requires a lot of capital and minimum orders that are simply scary.
See also: soft-core vs hard-core FPGA CPUs.
Heavy duty image processing: Giga pixel images processing - probably mainly for defence related app like this: https://youtu.be/MVFeMH3ahtw?t=34m45s
Video processing: I used to work on one - 10 years ago. We have 1U system that process feed ip videos in and provide video/decoding/transcoding service. It has 37 Virtex Pro FPGA each with 450Mhz PPC processor inside. It was a very fun project, make some good $ for the startup too. Deploy a lot of them at comcast and other major cable company til some stupid VC impose their own CEO and piss off of the three MIT founders. I think transcoding system probably still be useful for all the internet video datacenter app. FPGA transcoding app can provide real time transcoding service for youtube to a lot resolutions to various phone screen site.
FaceBox, Youtube, Amazon, Netflix can probably use those device/services.
Anyone else can think of any good/interesting applications for FPGA+CPU setup?
Crypto with modern CPU such as pentium works wells. Also almost all the ARM Soc comes with crypto co-processor already with private memory that's not share with main CPU.
Not too sure about the value add there.
Also, just having a separate memory space for the purpose of computation is not sufficient. I'm arguing for an entirely separate hardware bus to load keys onto the chip, such that they never exist in CPU, memory, or the storage for the machine being used for general purpose computation, because keys there can be obtained via side-channels if other software (such as the kernel) is exploited.
http://www.hypertransport.org/docs/wp/FPGA_Acceleration_in_H...
How far are we from a gigabyte of on-die cache, anyway?