dominicgs had some good ideas since software defined radio is very powerful. One extreme example of something you could do with a reconfigurable radio signal processor in your machine is install things that the FCC would not let be produced and sold. For example if someone reversed the military high accuracy GPS stuff, and produced a verilog spec anonymously so he was not sent to prison forever, no one would be able to use that to produce chips in consumer devices. But if we found verilog and wanted military GPS on our phones, all we do is install software.
Another example some friends have been excited about is emulation of older hardware, including video games, but much more. I will describe old games since they are closer to people's hearts. All the old cartridge based games had the actual cartridge contain half of the hardware needed to make a full computer. This immediately complicated emulation. But the real issue comes from quirks in the actual hardware. This is an issue because developers had no API except the exact hardware specifications that every console had. No one worried about checking their clock frequency was correct and dividing it to the right point so they got a certain framerate... everything was constant. Developers would find and exploit undocumented glitches in the hardware to make things faster, or sometimes to make them run at all. Hell, some games used the difference in clock frequency between two internal chips as a source for PCM sound to make little bleeps so they could save code. For this last example this means that unless you are emulating to the clock cycle each of these chips and sometimes their exact internal structures, some game will not work or crash randomly. The CPU power to do this is insane: a 3GHz core was the minimum suggested processor for running a highly accurate NES emulator in real time.
FPGAs let us implement the actual system, bugs and all, in hardware and not worry about CPU usage. Give the fpga a blob of shared memory for writing video and PCM data to and the CPU just passes blobs of memory between devices.
Programs like Postgres could implement highly optimized methods of certain algorithms like hashing for looking up in an index.
The kernel could detect it has FPGA space and offload some of its work to the chip.
I hope these have sounded interesting.
Some people will say that there are already pcie cards with fpgas on them and that this is not a new idea. But the issue is that existing cards like Digilent make are there for building pcie card designs. The FPGA (usually one) on the board has to implement the pcie fabric plus whatever it wants to do. Imagine if when you write an OpenGL/CL program you had to deal with all the DMA work and quirks of the underlying setup. Instead the grid of fpgas should have standard ways to access certain mapped regions of memory through a different chip that handles the PCIe transport layer stuff. If this was available then adding FPGA support into POSTGRES would not require bypassing the HAL of your kernel or worrying about timing details of something fundamental to modern computers (and thus software engineers) like PCIe.
Obviously the FPGA is still something that is hardware specific, but who knows what could be done with that. Even if we had to Synthesize from raw HDL every time, at least loading the chips would WORK. We could start using these chips to solve problems instead of thing slike a one off project by an EE major to build a grid of FPGAs that process bitcoin. The bitcoin work was impressive but it bothers me SO MUCH that they used reconfigurable devices to build a solid card with a fixed function.
http://www.dinigroup.com/new/DNK7_F5PCIe.php
Also the main problem that prevents fpga's being used for all kinds of cool stuff is that it's really hard to program. And many companies are trying to solve it - yet without great success.
And to solve this problem(in a decent but not in the most efficient way), one doesn't have to have the internals of the fpga, no?
For example, if 802.11b devices had been built using FPGAs, an upgrade to 802.11g could have been an OTA update. Or a new Bluetooth variant emerges (e.g. BLE) and support could be added to computers and phones overnight.
For these applications it's useful to think of an FPGA as a chip that you can patch, upgrade or reconfigure for new applications. However, looking at it from another angle, we can think of it as software that isn't limited by the CPU architecture.
This second category opens up the possibility of crypto algorithms that don't suffer from the timing attacks that they do on the CPU. Or a video codec that can be designed without having to worry about which extensions the CPU supports.
I'm sure there are much better examples and some of these are bad ideas that would work better on a CPU, but hopefully that gives you some ideas.
You guys are right that FPGAs are not quite ready, or maybe will never be ready to be the primary radio for a phone because of the static power consumption. You could still have one available for certain burst operations that need to be highly accelerated. Good point about the timing attacks on crypto, but hardware crypto can be updated within an FPGA. This can be seen as a pro and a con to security.
FPGA based design for crypto would have the same timing attack as CPU. It can be worked around the same way it would for a CPU.
Interestingly, SDR is being used for the UK's small scale digital radio station trials this year. Off the shelf SDR hardware appears to be performing well enough at a lower cost than bespoke DAB hardware. Again, this fits in with your base station category.
You're right about timing attacks, I have no idea what I was thinking there. Would they be better for power analysis attacks? I guess if we're concerned about that then we'll end up back at ASICs again.
FPGAs are more vulnerable in some ways than ASICs because someone could steal your design and duplicate it much much more easily than an ASIC.
A lot of crypto chips have built in protection against many side-channel attacks.
What are these ideas?