Re: A chip too far? Where is your solution Mr Larkin?

On a sunny day (Sat, 23 Aug 2008 12:53:53 -0400) it happened Phil Hobbs
<pcdhSpamMeSenseless@xxxxxxxxxxxxxxxxxx> wrote in
<48B040A1.5060209@xxxxxxxxxxxxxxxxxx>:

Very late to this party, having been incommunicado in rural Alaska for a
week--but the biggest problem with reconfigurable hardware is the
inconceivably vast task-switching overhead. If you can dedicate
reconfigurable cores to tasks, a la JL's model, this is reasonable at
the margins, but it won't ever be a mainstream programming model.

Cheers,

Phil Hobbs

Won't matter, configuring the hardware will be as loading a program into
memory, you configure it ONCE for each program.
So, if I have some sequential code, with some part optimised in gates,
then the OS would load the sequential code in memory, stuff the hardware
config bit stream in the FPGA, and have the program do it's thing.
With some tricks only part of the FPGA would be used.
An other program, loaded at a different time, would use an other part of that FPGA.
Until all hardware resources in that FPGA are used, then
no more programs that use FPGA real estate can be loaded (OS task to verify that).
So the time issue you talk about, is only related to starting up the program.
the HDL would have been synthesised at the same time the code was compiled.

So, as to 'task switching', start thinking _parallel_, the gate configurations
do not change during task-switching, each program has it's own gates (FPGA
real estate) as each program has its own memory (neither do you swap out sequential
code form memory during a task switch, then reload the code).

What is needed to accomplish this is very large FPGAs that can be partially reconfigured,
and compilers that spit out HDL (or bit streams) for those FPGAs for time critical parts
of the code, a loading mechanism, OS support to keep track of resources, and
hardware interface standards,
This is all possible, and in some other postings links have been given.
The main problem I see is an IP one, companies often share patents though..,
and compiler design, new version, or new type of gcc, now that would be cool.


.

Relevant Pages

  • Re: RFC : SOME IDEAS FOR THE APPLE II FPGAers
    ... address in a memory composed of two 16-bit banks... ... Given a certain FPGA, ... Why would you put inside a *reduced* instruction set processor instead? ... A direct implementation in hardware of a 6502 instruction set processor ...
    (comp.sys.apple2)
  • Re: Another transputer-inspired language?
    ... describe permanent ASIC/VLSI hardware devices. ... only support Verilog & VHDL. ... shrinking but the no of FPGA starts is exploding due to lowish NRE ... When I suggest the V++ language be modeled after ...
    (comp.sys.transputer)
  • Re: Interesting problems about high performance computing
    ... Most engineers still don't realize the processing power of the FPGA. ... Almost 25% to 50% your speed is lost to opcode and memory access. ... are left with program efficiency, how well it is translated to hardware. ...
    (comp.arch.fpga)
  • Re: Scientific Computing on FPGA
    ... FPGA solution. ... I suspect that as Flash drives replace hard drives at the 30GByte level ... the case for hardware taking control of data management in Flash only ... This is why the best hardware solution is unlikeley to ever be achieved ...
    (comp.arch.fpga)
  • Re: [OT?] whats a FPGA?
    ... - When you think of yourself as a 'programmer' or 'software person' ... You can churn through a bunch of simple filter algorithms at enormous speed using an FPGA approach. ... An off the shelf programmable DSP usually beat an FPGA into the dust for complex algorithms. ... Despite all the C based hardware design tools around today, you will generally get into some serious architectural design to do anything effective with an FPGA. ...
    (comp.dsp)