We looked at what it would take to switch configurations quickly in an FPGA. There are some nice things you can do with it, other than multiple processes. For example, you can build larger “circuits” than you have silicon for, and multiplex the wiring (the most costly part). Wires typically don’t change state all that often, so you can often time-multiplex signals on costly wires to improve performance. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCcQFjAB... On Jun 23, 2014, at 1:10 PM, Henry Baker <hbaker1@pipeline.com> wrote:
I'm not 100% up to speed on the most modern versions, but it was my impression that you don't reprogram FPGA's every time you switch tasks. Besides taking a very long time, some of these devices have an upper limit on how many times you can reprogram them.
The size of the state may be the least of your problems if you're trying to share such a unit among different tasks.
At 09:47 AM 6/23/2014, rcs@xmission.com wrote:
One difficulty with a large-state gadget inside a modern operating system is: How to handle sharing of the resource among different processes. The FPGA might have 100K bits of state to preserve. Do you let one process own it? Do you save the gadget state when doing a process switch? This problem occurred in miniature back when there were separate floating-point units with a modest stack of data. I think the solution then was that processes declared when they used the FPU, and state swapping was done whenever two FPU-using processes shared it.
Rich
---- Quoting Tom Knight <tk@ginkgobioworks.com>:
Hard wired processors do a lot of things more efficiently with special purpose logic. A simple example is the carry-chain of adders, which are special-cased for long carry propagates that happen very rapidly. Another, probably more important optimization, is the availability of many-port register files, with 1-2 write ports and 3-6 read ports being common on modern processors.
Also, the achievable clock speed of a modern micro is 3-10x faster than a similar architecture done in FPGAs. I do think one could design FPGAs that competed with processor speeds, but they would include higher level blocks with greater functionality than simple gate level logic.
One approach that is worth knowing about is this one, which defines a matrix of ALU/Register file units which can be pipelined or operated in parallel. Reconfiguration at a high level, special high performance logic at the low level: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=564808&url=http%3A%2F%...
On Jun 23, 2014, at 10:39 AM, Mike Speciner <ms@alum.mit.edu> wrote:
Maybe you'd like to run preexisting software rather than build everything from scratch.
--ms
On 2014-06-23 10:33, Whitfield Diffie wrote:
We are integrating our industry leading Xeon processor with a coherent FPGA in a single package, socket compatible to our standard Xeon E5 processor offerings. In the late sixties there was an announcement by DEC of a PDP-6 with programmable firmware. At least, I think that is what it must have been because what I recall is Gosper's response: if you had that, why would you want it to be a PDP-6. My response to this is the same.
If you have a CPU with an FPGA, why do you need anything more than a primitive processor to manage the programming of the FPGA. Could you not get rid of much of the legacy processor which, I assume, is most of the Xeon.
Whit
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun