9 ms·

I think the future of CPU will be FPGAs for one software. Hardware will be so cheap that your desktop or whatever computer you have will have lots of FPGAs or

I think the future of CPU will be FPGAs for one software. Hardware will be so cheap that your desktop or whatever computer you have will have lots of FPGAs or logics to run a certain amount of software. You can also allocate some of it for general computing so you can run legacy software.

jcranmer 7y ago
The problem is that FPGAs just can't drive memory bandwidth. (And FPGA configuration times are obnoxiously long).
- ezconnect 7y ago
  You only configure it once when you buy the software, installing software takes time too right now. FPGAs do come with embedded memory with very low latency. Someone will figure it out how to make it faster if things get implemented that way.
- analognoise 7y ago
  Can't drive memory bandwidth? I can saturate any memory interface with ease. All line rate Ethernet systems (pushing 100+ Gb/s now) are done with FPGAS. What are you talking about?? I can program a kintex ultrascale @ 16 bits transmitted at something like 100Mhz. The system is up fully in less than 5msec from power good. This feature is used in every system where milliseconds count - including military systems. Are you confusing JTAG reconfiguration speeds with production configuration speeds? I'm very confused by what you said, can you elaborate?
  - foobiekr 7y ago
    NPUs like Tomahawk, etc are not FPGAs.
    - analognoise 7y ago
      Not in their final version, no. I see what you meant - I should have said "are developed with". Lemme edit that. https://store.digilentinc.com/netfpga-sume-virtex-7-fpga-development-board/ https://store.digilentinc.com/netfpga-sume-virtex-7-fpga-dev... But for 7k you can get an older design with 4x 10Gbps Ethernet. It's used at Stanford and Cambridge for... High speed network processing research. High speed trading firms almost universally use FPGAs. You can't go faster without custom silicon. But you can sure as shit max out as many DDR and network interfaces as you can physically attach.
      - foobiekr 7y ago
        10G is a very slow speed at this point. But yes, there are very good use cases for FPGAs.
  - alain94040 7y ago
    16 bits transmitted at something like 100Mhz That's 1.6 Gbit/s. Looking up random Intel Xeon, specs, the memory bandwidth from the CPU to memory is 100 Gbytes/s. That's 1000X more than what you are describing.
    - analognoise 7y ago
      You only need to pass a bin file to program an FPGA - it's like 20Mbits (hence a few msec). Memory interfaces are not the same as the reconfiguration programming interface. The memory interfaces (to external memory) are standardized - DDR3/4. Are you talking about to a L1 cache? Because all of the equivalent in an FPGA (BRAM, in Xilinx terminology) is accessible within a single clock cycle on an FPGA (assuming you can meet P&R/timing). Each DDR4 chip can do something like 20Gbit/sec, I can fit 5 of them on a KCU115 1924... And that's external memory. Internally there is BRAM (and it's newer variants, which means you don't even have to go off chip).
deepnotderp 7y ago
1. Have you ever tried programming an fpga? 2. Plenty of workloads don't map that well to an fpga without modification. Deep learning, molecular dynamics and other workloads that are relatively embarrassingly parallel, control flow light and high compute/bandwidth ratios map well to specialized hardware, but most real world code does not fit that bill!
- ezconnect 7y ago
  Yes I have programmed FPGAs. We are reaching the limit of the silicon and the only way to get faster is to run the CPU on something different or each software get implemented on hardware which is getting cheaper.
  - deepnotderp 7y ago
    > Yes I have programmed FPGAs And was it a pleasurable experience? Do you really think people will rewrite all their software for fpgas? And what if you're memory or I/O bottlenecked as so many processors are today?
    - ezconnect 7y ago
      For me it's a pleasurable experience. > Do you really think people will rewrite all their software for fpgas? A compiler will do it for them. If technology moves in that direction they don't have any choice anyways. > And what if you're memory or I/O bottlenecked as so many processors are today? I/O will never run as fast as the CPU.
      - icxa 7y ago
        > I/O will never run as fast as the CPU. In the era of kernal bypass and modern IO accelerators seen in some data centers today, I wonder if this is even true today?
        rcxdude 7y ago
zackmorris 7y ago
I have a computer engineering degree and what you are saying about using FPGAs for general purpose computing was correct when I graduated 20 years ago. It was 10-100 times more correct a decade after that, and is another 10-100 times more correct today. So somewhere between 100 and 10,000 times more correct now than in the 90s. And between 1000 and 1,000,000 times more correct in 2029! But we're still using the same 3 GHz (effectively single threaded) chips today as then. Sure, RAM frequency is higher, but so is latency. Computers today are closer to 10 times faster than computers of the 90s, not 10,000 times faster like they should be. Except for video cards, which really are 100 or 1000 times faster, because they break with the single-threaded model. FPGAs would work great for general purpose computing, but we're still missing a proper language for programming them. VHDL/Verilog is more like assembly language than the functional language we would need to do it effectively. I haven't really kept up on this because it's been too depressing, but here are some promising approaches: https://github.com/dgrnbrg/piplin https://github.com/dgrnbrg/piplin https://catherineh.github.io/programming/2016/12/26/haskell-on-a-xilinx-fpga https://catherineh.github.io/programming/2016/12/26/haskell-... https://www.eetimes.com/document.asp?doc_id=%201329857&page_number=6 https://www.eetimes.com/document.asp?doc_id=%201329857&page_... https://news.ycombinator.com/item?id=14546535 https://news.ycombinator.com/item?id=14546535 So we'd need: * An HDL wrapper that guarantees that any hardware description downloaded to an FPGA won't short it out. [might already exist, but needs proven examples/unit tests of pathological edge cases] * A Lisp to HDL compiler, preferably with optimization. [time-consuming, but not difficult] * A high-level functional or vector or stream language (Clojure/Elixir/MATLAB/Erlang/Go) to Lisp transpiler. [somewhere between trivial and straightforward, might already exist] * An example implementation of a CPU written in a functional/vector/stream language, probably MIPS [not difficult, just time consuming to convert an existing spec to code] It would be good to keep the transistor count under 1 million (say 100,000 gates), and possibly start with an 8, 16 or 32 bit implementation and emulate 64 bit and higher operations in microcode. Most CPU gates are wasted on out-of-order execution and cache, which aren't as important in parallel and stream-based/DSP computing: https://en.wikipedia.org/wiki/Transistor_count https://en.wikipedia.org/wiki/Transistor_count When I graduated, I saw a brand new chip where 75% of the die was for cache, although I can't remember which model number it was. Chips today are probably worse, since their speed to transistor count ratio has mostly gone down. It looks like FPGAs might have stopped reporting gate count since they've doubled down on the proprietary route. A Xilinx Virtex-7 2000T FPGA from 2011 had 6.8 billion transistors which could implement roughly 20 million ASIC gates: https://www.eetimes.com/document.asp?doc_id=1316816 https://www.eetimes.com/document.asp?doc_id=1316816 So 8 years later with Moore's law that should be 5 doublings (32 times), or roughly 200 billion transistors and 640 million ASIC gates on a 2019 FPGA. The article says it takes about 340 transistors to form a gate on an FPGA, which seems high to me. But conservatively, 640 million gates would allow us to put 6,400 of our 100,000 gate cores on one FPGA. Maybe someone ambitious can figure out how much RAM could be allocated per core in a 2D grid, based on the total core count. I'd like at least 1 MB per core, but that might conservatively require something like 10 million gates, which might limit us to 64 cores in RAM alone: https://www.quora.com/How-many-transistors-flip-flops-and-gates-are-required-to-store-one-byte-of-data-in-a-memory-chip-online https://www.quora.com/How-many-transistors-flip-flops-and-ga... It’s unfortunate that there is so much hand waving around transistor, gate and logic cell count. But it looks like we could put something like 64, 640 or 6,400 cores on a single FPGA today depending on how much RAM we allocate per core, and if we had the right software. And this would be a true parallel computer, probably running between 100 MHz and 1 GHz. So we could play around with things like copy-on-write (COW), content-addressable memory and embarrassingly parallel computation in all the areas that today's computers are weak at (things like ray tracing, voxels, genetic programming, neural nets and so on) and at least see how classic (UNIX-style) programming compares with the bare-hands/burdensome languages like CUDA and OpenCL. If an FPGA can do all that, then surely it could devote some of its gates to the kind of reprogrammable logic you mentioned (perhaps for video transcoding, bitcoin mining, emulating video game consoles, things of that nature).
pkaye 7y ago
We are reaching the end of Moore's law. Things will not get dramatically cheaper unless some breakthrough technology comes up.
wyatwerp 7y ago
I don't know if desktops have a future, or if even local computing has one. Maybe a portion of "personal computing" ends up only done on mobile devices, and some of the rest of it moves to public clouds. There might not be a business case for companies to produce chips & other hardware for desktops. So, lets equate buying desktops to buying low-end servers for all practical purposes. As computing gets cloud-ier, is there a business case for low-end servers either, when a high-end server can be virtualized to get the same result? If we are stuck with power-sensitive mobile devices & virtualized cloud instances on high-end servers as the only businesses that sustain, FPGA's only play is on the servers. You'd expect lots of heterogenity in the workloads there, more than on desktops. Reconfiguring many FPGA's very frequently? Not sure it would fly, even with a small selection of applications vetted to not be damaging to the FPGA. You can do personal computing with FPGA's with Adapteva boards. How safely can you reconfigure its FPGA, after you have managed to code for it?
- doublerebel 7y ago
  Security. Buyers will have to be convinced that remote computing is as secure as local. Especially considering the latest CPU-based exploits, I can't see a near future where buyers will give the same trust to remote computing, regardless of the latest technology advancements.

jcranmer 7y ago

The problem is that FPGAs just can't drive memory bandwidth. (And FPGA configuration times are obnoxiously long).

ezconnect 7y ago
You only configure it once when you buy the software, installing software takes time too right now. FPGAs do come with embedded memory with very low latency. Someone will figure it out how to make it faster if things get implemented that way.
analognoise 7y ago
Can't drive memory bandwidth? I can saturate any memory interface with ease. All line rate Ethernet systems (pushing 100+ Gb/s now) are done with FPGAS. What are you talking about?? I can program a kintex ultrascale @ 16 bits transmitted at something like 100Mhz. The system is up fully in less than 5msec from power good. This feature is used in every system where milliseconds count - including military systems. Are you confusing JTAG reconfiguration speeds with production configuration speeds? I'm very confused by what you said, can you elaborate?
- foobiekr 7y ago
  NPUs like Tomahawk, etc are not FPGAs.
  - analognoise 7y ago
    Not in their final version, no. I see what you meant - I should have said "are developed with". Lemme edit that. https://store.digilentinc.com/netfpga-sume-virtex-7-fpga-development-board/ https://store.digilentinc.com/netfpga-sume-virtex-7-fpga-dev... But for 7k you can get an older design with 4x 10Gbps Ethernet. It's used at Stanford and Cambridge for... High speed network processing research. High speed trading firms almost universally use FPGAs. You can't go faster without custom silicon. But you can sure as shit max out as many DDR and network interfaces as you can physically attach.
    - foobiekr 7y ago
      10G is a very slow speed at this point. But yes, there are very good use cases for FPGAs.
- alain94040 7y ago
  16 bits transmitted at something like 100Mhz That's 1.6 Gbit/s. Looking up random Intel Xeon, specs, the memory bandwidth from the CPU to memory is 100 Gbytes/s. That's 1000X more than what you are describing.
  - analognoise 7y ago
    You only need to pass a bin file to program an FPGA - it's like 20Mbits (hence a few msec). Memory interfaces are not the same as the reconfiguration programming interface. The memory interfaces (to external memory) are standardized - DDR3/4. Are you talking about to a L1 cache? Because all of the equivalent in an FPGA (BRAM, in Xilinx terminology) is accessible within a single clock cycle on an FPGA (assuming you can meet P&R/timing). Each DDR4 chip can do something like 20Gbit/sec, I can fit 5 of them on a KCU115 1924... And that's external memory. Internally there is BRAM (and it's newer variants, which means you don't even have to go off chip).

deepnotderp 7y ago

1. Have you ever tried programming an fpga? 2. Plenty of workloads don't map that well to an fpga without modification. Deep learning, molecular dynamics and other workloads that are relatively embarrassingly parallel, control flow light and high compute/bandwidth ratios map well to specialized hardware, but most real world code does not fit that bill!

ezconnect 7y ago
Yes I have programmed FPGAs. We are reaching the limit of the silicon and the only way to get faster is to run the CPU on something different or each software get implemented on hardware which is getting cheaper.
- deepnotderp 7y ago
  > Yes I have programmed FPGAs And was it a pleasurable experience? Do you really think people will rewrite all their software for fpgas? And what if you're memory or I/O bottlenecked as so many processors are today?
  - ezconnect 7y ago
    For me it's a pleasurable experience. > Do you really think people will rewrite all their software for fpgas? A compiler will do it for them. If technology moves in that direction they don't have any choice anyways. > And what if you're memory or I/O bottlenecked as so many processors are today? I/O will never run as fast as the CPU.
    - icxa 7y ago
      > I/O will never run as fast as the CPU. In the era of kernal bypass and modern IO accelerators seen in some data centers today, I wonder if this is even true today?
      - rcxdude 7y ago

zackmorris 7y ago

I have a computer engineering degree and what you are saying about using FPGAs for general purpose computing was correct when I graduated 20 years ago. It was 10-100 times more correct a decade after that, and is another 10-100 times more correct today. So somewhere between 100 and 10,000 times more correct now than in the 90s. And between 1000 and 1,000,000 times more correct in 2029! But we're still using the same 3 GHz (effectively single threaded) chips today as then. Sure, RAM frequency is higher, but so is latency. Computers today are closer to 10 times faster than computers of the 90s, not 10,000 times faster like they should be. Except for video cards, which really are 100 or 1000 times faster, because they break with the single-threaded model. FPGAs would work great for general purpose computing, but we're still missing a proper language for programming them. VHDL/Verilog is more like assembly language than the functional language we would need to do it effectively. I haven't really kept up on this because it's been too depressing, but here are some promising approaches: https://github.com/dgrnbrg/piplin https://github.com/dgrnbrg/piplin https://catherineh.github.io/programming/2016/12/26/haskell-on-a-xilinx-fpga https://catherineh.github.io/programming/2016/12/26/haskell-... https://www.eetimes.com/document.asp?doc_id=%201329857&page_number=6 https://www.eetimes.com/document.asp?doc_id=%201329857&page_... https://news.ycombinator.com/item?id=14546535 https://news.ycombinator.com/item?id=14546535 So we'd need: * An HDL wrapper that guarantees that any hardware description downloaded to an FPGA won't short it out. [might already exist, but needs proven examples/unit tests of pathological edge cases] * A Lisp to HDL compiler, preferably with optimization. [time-consuming, but not difficult] * A high-level functional or vector or stream language (Clojure/Elixir/MATLAB/Erlang/Go) to Lisp transpiler. [somewhere between trivial and straightforward, might already exist] * An example implementation of a CPU written in a functional/vector/stream language, probably MIPS [not difficult, just time consuming to convert an existing spec to code] It would be good to keep the transistor count under 1 million (say 100,000 gates), and possibly start with an 8, 16 or 32 bit implementation and emulate 64 bit and higher operations in microcode. Most CPU gates are wasted on out-of-order execution and cache, which aren't as important in parallel and stream-based/DSP computing: https://en.wikipedia.org/wiki/Transistor_count https://en.wikipedia.org/wiki/Transistor_count When I graduated, I saw a brand new chip where 75% of the die was for cache, although I can't remember which model number it was. Chips today are probably worse, since their speed to transistor count ratio has mostly gone down. It looks like FPGAs might have stopped reporting gate count since they've doubled down on the proprietary route. A Xilinx Virtex-7 2000T FPGA from 2011 had 6.8 billion transistors which could implement roughly 20 million ASIC gates: https://www.eetimes.com/document.asp?doc_id=1316816 https://www.eetimes.com/document.asp?doc_id=1316816 So 8 years later with Moore's law that should be 5 doublings (32 times), or roughly 200 billion transistors and 640 million ASIC gates on a 2019 FPGA. The article says it takes about 340 transistors to form a gate on an FPGA, which seems high to me. But conservatively, 640 million gates would allow us to put 6,400 of our 100,000 gate cores on one FPGA. Maybe someone ambitious can figure out how much RAM could be allocated per core in a 2D grid, based on the total core count. I'd like at least 1 MB per core, but that might conservatively require something like 10 million gates, which might limit us to 64 cores in RAM alone: https://www.quora.com/How-many-transistors-flip-flops-and-gates-are-required-to-store-one-byte-of-data-in-a-memory-chip-online https://www.quora.com/How-many-transistors-flip-flops-and-ga... It’s unfortunate that there is so much hand waving around transistor, gate and logic cell count. But it looks like we could put something like 64, 640 or 6,400 cores on a single FPGA today depending on how much RAM we allocate per core, and if we had the right software. And this would be a true parallel computer, probably running between 100 MHz and 1 GHz. So we could play around with things like copy-on-write (COW), content-addressable memory and embarrassingly parallel computation in all the areas that today's computers are weak at (things like ray tracing, voxels, genetic programming, neural nets and so on) and at least see how classic (UNIX-style) programming compares with the bare-hands/burdensome languages like CUDA and OpenCL. If an FPGA can do all that, then surely it could devote some of its gates to the kind of reprogrammable logic you mentioned (perhaps for video transcoding, bitcoin mining, emulating video game consoles, things of that nature).

pkaye 7y ago

We are reaching the end of Moore's law. Things will not get dramatically cheaper unless some breakthrough technology comes up.

wyatwerp 7y ago

I don't know if desktops have a future, or if even local computing has one. Maybe a portion of "personal computing" ends up only done on mobile devices, and some of the rest of it moves to public clouds. There might not be a business case for companies to produce chips & other hardware for desktops. So, lets equate buying desktops to buying low-end servers for all practical purposes. As computing gets cloud-ier, is there a business case for low-end servers either, when a high-end server can be virtualized to get the same result? If we are stuck with power-sensitive mobile devices & virtualized cloud instances on high-end servers as the only businesses that sustain, FPGA's only play is on the servers. You'd expect lots of heterogenity in the workloads there, more than on desktops. Reconfiguring many FPGA's very frequently? Not sure it would fly, even with a small selection of applications vetted to not be damaging to the FPGA. You can do personal computing with FPGA's with Adapteva boards. How safely can you reconfigure its FPGA, after you have managed to code for it?

doublerebel 7y ago
Security. Buyers will have to be convinced that remote computing is as secure as local. Especially considering the latest CPU-based exploits, I can't see a near future where buyers will give the same trust to remote computing, regardless of the latest technology advancements.