Soft cores, processors (gpu/cpu/etc) that you put onto an FPGA, are quite an interesting beast. The way it is now is that you can flash whatever physical hardware that can fit - if you had access to Intel Pentium 1 source code, you could theoretically flash on, and it would work.
This is kind of off-topic, but what's more interesting to me, conceptually, is the potential for real-time re-flashing. For example, you've got space for 10 CPU cores and 10 GPU cores. When, say, running a web server, you can erase the GPU cores, and use 20 CPU cores instead. When running a game, you could drop down to 5 CPU cores and 15 GPU cores. Or, when doing single-threaded apps, you could opt for a beefy single or dual core.
Also, you could have CPUs that re-wire themselves as part of their workflow. Or, if, for example, a new CPU design comes out - you could upgrade to it without buying new silicon. Hybrid FPGA approaches even exist today - some high-end FPGAs actually come with a hard-wired CPU inside them.
The FPGA Microbee project is only scratching the surface of "FPGA=cool" factor, I think.
While I await the days that doing that is possible, my understanding is that FPGAs have a limited number of flashings that are possible. Similar to how Flash-ram has a limit on the write cycles.
I personally would love to have one for doing just this kind of thing for dealing with old software. Think of running old MAC OS stuff on one of these, or even like he's doing right now with the microbee. If done correctly it'd be hardware "accelerated" virtualization of some of the really old hardware.
Most FPGAs store their configuration in SRAM so they don't have any limitations in the number of programmings.
There also exists flash based FPGAs which have the normal flash wearout problem. One time programmable FPGAs also exist but I don't think they are interesting in this application :-)
Awesome I wasn't aware that that was the case these days. Really makes me wish I had something to play with to try to design a "standard" communications layer for handling emulated cpus.
Interesting idea! Though as I understand it, the limiting factor atm would be that FPGA cores are considerably slower than real silicon. So even if you had a huge FPGA, loading an identical circuit to a modern processor would not be anywhere near as fast.
This is true, the flexibility you get form being able to reconfigure things does result in less efficiency (speed, size, power) than some dedicated hardware. An FPGA can be more efficient than general processor if it can be tailored to the specific computational task, but it will still be slower than if you made an IC with the specially tailored hardware.
This is true, and as far as I see - this is an inherent limitation. Dedicated, static ASICs will always be faster or more efficient.
However - I think there's some interesting work to be done in hybrid approaches. For example, besides FPGA cells, you can include fast on-board cache, arithmetic units, etc. So, this way, if you're switching between GPU and CPU cores, a subset of that can be reused.
For reference, a typical FPGA cell includes a 1-bit flip-flop and an LUT (look-up table). Flip-flops are memory, LUTs simulate the logic.
The biggest problem with FPGA dynamic reconfiguration of today is that it is slow and not fine grained.
The vendors haven't really seen this as an area which their customers are interested in. Maybe this has been changing in the recent years with the military's interest in software defined radio, but they probably don't need very rapid reconfigurations so maybe not ..
That's actually why I brought that up. I'm quite interested in ideas that have never been done before. (Hardware examples are non-typical FPGA use, modern trinary processors, using PID-like "overdrive" to speed up digital transistor switching)
Comments
Soft cores, processors (gpu/cpu/etc) that you put onto an FPGA, are quite an interesting beast. The way it is now is that you can flash whatever physical hardware that can fit - if you had access to Intel Pentium 1 source code, you could theoretically flash on, and it would work.
This is kind of off-topic, but what's more interesting to me, conceptually, is the potential for real-time re-flashing. For example, you've got space for 10 CPU cores and 10 GPU cores. When, say, running a web server, you can erase the GPU cores, and use 20 CPU cores instead. When running a game, you could drop down to 5 CPU cores and 15 GPU cores. Or, when doing single-threaded apps, you could opt for a beefy single or dual core.
Also, you could have CPUs that re-wire themselves as part of their workflow. Or, if, for example, a new CPU design comes out - you could upgrade to it without buying new silicon. Hybrid FPGA approaches even exist today - some high-end FPGAs actually come with a hard-wired CPU inside them.
The FPGA Microbee project is only scratching the surface of "FPGA=cool" factor, I think.
While I await the days that doing that is possible, my understanding is that FPGAs have a limited number of flashings that are possible. Similar to how Flash-ram has a limit on the write cycles.
I personally would love to have one for doing just this kind of thing for dealing with old software. Think of running old MAC OS stuff on one of these, or even like he's doing right now with the microbee. If done correctly it'd be hardware "accelerated" virtualization of some of the really old hardware.
Most FPGAs store their configuration in SRAM so they don't have any limitations in the number of programmings.
There also exists flash based FPGAs which have the normal flash wearout problem. One time programmable FPGAs also exist but I don't think they are interesting in this application :-)
Awesome I wasn't aware that that was the case these days. Really makes me wish I had something to play with to try to design a "standard" communications layer for handling emulated cpus.
Interesting idea! Though as I understand it, the limiting factor atm would be that FPGA cores are considerably slower than real silicon. So even if you had a huge FPGA, loading an identical circuit to a modern processor would not be anywhere near as fast.
This is true, the flexibility you get form being able to reconfigure things does result in less efficiency (speed, size, power) than some dedicated hardware. An FPGA can be more efficient than general processor if it can be tailored to the specific computational task, but it will still be slower than if you made an IC with the specially tailored hardware.
This is true, and as far as I see - this is an inherent limitation. Dedicated, static ASICs will always be faster or more efficient. However - I think there's some interesting work to be done in hybrid approaches. For example, besides FPGA cells, you can include fast on-board cache, arithmetic units, etc. So, this way, if you're switching between GPU and CPU cores, a subset of that can be reused.
For reference, a typical FPGA cell includes a 1-bit flip-flop and an LUT (look-up table). Flip-flops are memory, LUTs simulate the logic.
The biggest problem with FPGA dynamic reconfiguration of today is that it is slow and not fine grained.
The vendors haven't really seen this as an area which their customers are interested in. Maybe this has been changing in the recent years with the military's interest in software defined radio, but they probably don't need very rapid reconfigurations so maybe not ..
IIRC state-of-the-art reconfiguration times can get below 10ms when using partial reconfiguration.
In the field of sotfware-defined radio, the USRP hardware from the GNU Radio project has an onboard FPGA. It's a great project, lets you deploy most radio stacks with only a few clicks: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio....
That's actually why I brought that up. I'm quite interested in ideas that have never been done before. (Hardware examples are non-typical FPGA use, modern trinary processors, using PID-like "overdrive" to speed up digital transistor switching)