5 ms·
It's the future, representing a convergence between Field Programmable Gate Arrays (FPGAs) and the microprocessor. Gate arrays are vast arrays of logic gates,
by femto 15y ago
It's the future, representing a convergence between Field Programmable Gate Arrays (FPGAs) and the microprocessor.
Gate arrays are vast arrays of logic gates, which can be wired together in almost arbitrary patterns by a sea of "fuses", typically controlled by state stored in on-board SRAM. They are real time and blindingly fast due to their massive parallelism, achieving supercomputer type speeds when applied to the right type of problem and programmed well. They are more difficult to program than a microprocessor. One way of looking at an FPGA is as an array of tens of millions of very simple computing engines.
Over the years, the number of transistors on an FPGA has been rocketing up. Generally these transistors have been put to use by providing more and more simple logic blocks. We are now to the point where we have almost more gates than we know what to do with, and the chip is being dominated by interconnects. This has seen a move towards including a limited number of elaborate hard wired blocks, such as CPUs and multipliers, in addition to the array of logic.
The logical evolution is to stop providing more blocks, but make each block more complex as transistor counts go up. Eventually we will see arrays of tens of millions of microprocessors, rather than tens of millions of logic blocks. There will be no distinction between a multicore CPU and FPGA.
It's worth noting that the first Xilinx FPGAs, thirty years ago, provided arrays of around 144 logic blocks, similar to the processor count in this chip. Extrapolate 30 years and we will have an array of 10 million microprocessors.
- femto 15y agoCorrection: I've been lax in my terminology with logic gates and cells. Current big FPGAs contain around 2 million "logic cells", which typically represent between 1 and 10 logic gates each, depending on device programming.
- sliverstorm 15y agoUnfortunately for the FPGA guys, it seems like in general the closer they get to CPUs the less compelling their product becomes.
- femto 15y agoI hesitate to divide the world into "FPGA guys" and "non-FPGA guys". It's a continuum of computing power; CPU<->DSP<->FPGA, and one moves up and down it as the task varies and technology changes. If anything defines an "FPGA guy" is choice of language. Historically FPGAs have been programmed with an HDL, such as VHDL or Verilog, because these languages are concurrent meaning they handle parallel systems. My prediction is that as mainstream multicore CPUs develop we will see the rise of concurrent versions of mainstream languages, which will supplant HDLs. Just as DSP's are now programmed in (almost) vanilla C/C++/..., we will see FPGAs being programmed using the same languages as micros and DSPs. It will then be possible to write code and (almost) seamlessly run it on any platform, depending on how fast it needs to run.
- sliverstorm 15y agoBy "FPGA guys" I meant the guys who make FPGAs, not the guys who use them. There is still a pretty strong dividing line between FPGAs and DSP chips.
- femto 15y agoSorry for the misinterpretation. If I was an FPGA manufacturer, I'd be trying to buy a company like Green Array and beat the CPU manufacturers to the middle ground. Agree about the current divide, though I think it will weaken and eventually disappear.
- bisrig 15y agoAs an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to relatively constrained solution spaces. I guess my feeling is that there's a fundamental difference between the sequential execution inherent in something like C and the ability to describe concurrency that is fundamental to HDLs, and it's going to be a hard bridge to build. Side question: are "SW guys" satisfied with the tools/languages available for multi-core development? I've always thought things like OpenMP and CUDA were steps in the right direction but still hacks. It seems to me like there's still problems to solve there as well.
- VladRussian 15y ago>We are now to the point where we have almost more gates than we know what to do with, limits of von Neumann architecture (and its underlying mathematics of recursive functions) as a mental framework for our thinking about computing.
- calebmpeterson 15y agoYou've piqued my curiosity; could you elaborate please?
- tomjen3 15y agoI shall try, but this stuff gets really hairy, really really fast. Von Neumann architecture is what almost all computers use today: you have (very roughly) an ALU (arithmetic logic unit) hooked up to a memory bank which stores both program data and the instructions the program consist of. Now you can add a couple of cores to that, but you pretty soon start to run into problems -- threads which try to access the same data, race conditions, etc. But the biggest problem is that under the Von Neumann architecture all memory is shared so any thread can access any other threads memory. This puts rather drastic limits on how much benefit you can get from new cores. You also run into issues like the limited speed it is possible to access the main memory banks with, etc, etc. This is possible to compensate to some degree with caches, but they have their own problems. But the fundamental problem with them is that they were from and of an era where the clock speed kept increasing and increasing. Today we have a situation where transistors gets smaller and smaller. But if you are trying to use this to make a traditional CPU with these new transistors, all this gets you is a really small chip. What we need is an architecture inspired by something else. Personally I am kinda hoping it will be some form of message sending -- you run a lot of small (green) threads which each have their own memory as well as the ability to send and receive packages of information to/from the other cores of on the CPU. You can have access to a (comparatively large but slower) shared memory bank too (like RAM today). I like it because it works well with how you would design a cluster of computers (where you cannot afford the illusion of shared memory), how computation is organized under the actor model (which I prefer to threads) and it would be possible to implement with not that much new changes in the CPU.