FPGA's - the future

On Apr 12, 4:29&#4294967295;pm, HardySpicer <gyansor...@gmail.com> wrote:
> On Apr 13, 1:28&#4294967295;am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>
>
> > HardySpicer <gyansor...@gmail.com> wrote:
> > > I am wondering if any ofyou share my vision of an FPGA (or equivalent)
> > > type future. By this I mean programmable hardware. Your PC will be
> > > nothing but a massive array of gates on which you download your own
> > > custom processor.
>
> > Is sounds nice, but doesn't seem likely.
>
> > Maybe 40 years ago, we had microprogammed processors with writable
> > control store, to allow adding new instructions. A nice feature,
> > but rarely used.
>
> > > You use high level languages which compiles direct
> > > to silicon and runs 100 times faster than ordinary software.
>
> > I might believe a small FPGA such that one could load logic optimal
> > to the problem at hand. Presumably it would have to be part of
> > the context, saved and restored, though maybe with enough to
> > avoid too much swapping. (That is, more than one program could be
> > running, each with its own custom logic block.)
>
> > > A silicon compiler, full floating point. Suppose we need a modem -
> > > just download it. A dual processor - no problem, just download it.
>
> > Floating point is especially inefficient in most FPGAs.
>
> > I do believe that FPGAs are nice for legacy processors. You could
> > build a nice box that could emulate popular machines from the 1970's,
> > 1980's, and even 1990's. I have thought about a board with a medium
> > to large FPGA, with an ISA, PCI, Sbus, Apple II bus, S-100, NuBus,
> > and maybe more, slot. (One of each.) Also, parallel, two serial,
> > VGA, PS/2 keyboard and mouse, IDE, and floppy port.
>
> > That would allow one machine to emulate a large number of older
> > systems. (The whole system, not just processor.)
>
> > -- glen
>
> That's a great idea which to me tells me we are around 20 years behind
> where we could be.
> We need faster FPGA programming and devices etc. surely new
> technologies will emerge in time.
>
> Hardy- Hide quoted text -
>
> - Show quoted text -

And surely new technologies will emerge which will allow solar power
to replace gasoline....or not.

HardySpicer <gyansorova@gmail.com> wrote:

(snip, someone wrote)
>> > I am wondering if any ofyou share my vision of an FPGA (or equivalent)
>> > type future. By this I mean programmable hardware. Your PC will be
>> > nothing but a massive array of gates on which you download your own
>> > custom processor.

(snip, then I wrote)
>> I do believe that FPGAs are nice for legacy processors. You could
>> build a nice box that could emulate popular machines from the 1970's,
>> 1980's, and even 1990's. I have thought about a board with a medium
>> to large FPGA, with an ISA, PCI, Sbus, Apple II bus, S-100, NuBus,
>> and maybe more, slot. (One of each.) Also, parallel, two serial,
>> VGA, PS/2 keyboard and mouse, IDE, and floppy port.

>> That would allow one machine to emulate a large number of older
>> systems. (The whole system, not just processor.)

> That's a great idea which to me tells me we are around 20 years 
> behind where we could be.
> We need faster FPGA programming and devices etc. surely new
> technologies will emerge in time.

But as I say, it could have been done 40 years ago with writable
control store. A system could have allowed a task to load custom,
task specific, microcode that would speed up that task. It never
caught on.

High-end FPGAs are now getting to the point where tunneling through
the gate is significant. That is, the quiescent current is getting
high enough to matter. 

FPGA processors can be much faster than traditional ones when you
need to do a very large number of simple operations in parallel.

Traditional vector processors are pretty good at doing more
complicated parallel processing. (Such as including multiply
and divide.) FPGAs don't help so much with those.

-- glen

An FPGA is essentially a large distributed processing unit that can be
customized around a problem.  You get to use the LUTS, registers,
multipliers, and any other building block to build up a customized parallel
computing engine.  The architecture of say a i7 processor is so different
that it's hard to compare the two technologies, at least in my mind.  If
you have a very specific problem to solve, an FPGA makes sense.  If you
want a generic computing platform, an FPGA doesn't make a whole lot of
sense.  However, an FPGA is generic in the sense that the built in logic
elements can be connected to fit the task at hand.  The "Field
Programmable" part of FPGAs, in my mind, is appealing because it's much
easier and cheaper to spin an FPGA design than an ASIC.  

Enough rambling, I guess my point is that the traditional PC CPU is as
general/programmable as it gets.  FPGAs are targetted to solve a different
problem and I do not forsee FPGAs infiltrating the PC market.

On 4/13/12 9:53 PM, Impoliticus wrote:
> An FPGA is essentially a large distributed processing unit that can be
> customized around a problem.  You get to use the LUTS, registers,
> multipliers, and any other building block to build up a customized parallel
> computing engine.  The architecture of say a i7 processor is so different
> that it's hard to compare the two technologies, at least in my mind.  If
> you have a very specific problem to solve, an FPGA makes sense.  If you
> want a generic computing platform, an FPGA doesn't make a whole lot of
> sense.  However, an FPGA is generic in the sense that the built in logic
> elements can be connected to fit the task at hand.  The "Field
> Programmable" part of FPGAs, in my mind, is appealing because it's much
> easier and cheaper to spin an FPGA design than an ASIC.
>
> Enough rambling, I guess my point is that the traditional PC CPU is as
> general/programmable as it gets.  FPGAs are targetted to solve a different
> problem and I do not forsee FPGAs infiltrating the PC market.

not being any sort of expert with FPGA, i will say that there was a 
company i had worked for in the past (name not divulged) that had audio 
processing products that had a sorta general purpose CPU that did not 
process audio samples itself (but it did a little more work than just 
manage the front panel buttons and display) and it was connected to an 
FPGA that was loaded with its program at power up and never changed 
while the unit was on.  i understood this to be the normal way FPGAs are 
used.

there was one engineer (and he was one of the FPGA engineers) that had 
been advocating reloading the FPGA with different code (configuring it 
differently) whenever there was a program change (and they didn't take 
this guy's advice).  this is sorta how we do it with boxes that have a 
CPU and a few DSPs in it.  the DSPs are reloaded with new code each time 
there is a program change.  but i never seen anyone do that with an 
FPGA, but there seems to be no reason conceptually that it cannot be 
done.  but i'm no FPGA expert, so i dunno what all is involved.

i could imagine that a simpler way to do this would be to have a finite 
set of algorithms to load into the FPGA and, whatever the program with 
whatever presets it is, it would be one of those countable algorithms or 
FPGA configurations.  it's not a totally general way to do it, but a lot 
of boxes are like that.  they do, like, 1 of 12 things and nothing else. 
  every preset would have, as one parameter, a spec that selects one of 
the 12 available configurations and the other parameters in the preset 
are just the values of specific knobs that whatever selected alg or 
configuration uses.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

robert bristow-johnson <rbj@audioimagination.com> wrote:

> On 4/13/12 9:53 PM, Impoliticus wrote:
>> An FPGA is essentially a large distributed processing unit that can 
>> be customized around a problem.  You get to use the LUTS, registers,
>> multipliers, and any other building block to build up a customized 
>> parallel computing engine.  

(snip)
>> Enough rambling, I guess my point is that the traditional PC CPU 
>> is as general/programmable as it gets.  FPGAs are targetted to 
>> solve a different problem and I do not forsee FPGAs 
>> infiltrating the PC market.

> not being any sort of expert with FPGA, i will say that there was a 
> company i had worked for in the past (name not divulged) that had audio 
> processing products that had a sorta general purpose CPU that did not 
> process audio samples itself (but it did a little more work than just 
> manage the front panel buttons and display) and it was connected to an 
> FPGA that was loaded with its program at power up and never changed 
> while the unit was on.  i understood this to be the normal way FPGAs are 
> used.

Many FPGAs now are used for what previously would have been done
with ASICs. They are fast enough, and without the big NRE cost
of ASICs, more affordable. 

> there was one engineer (and he was one of the FPGA engineers) that had 
> been advocating reloading the FPGA with different code (configuring it 
> differently) whenever there was a program change (and they didn't take 
> this guy's advice).  this is sorta how we do it with boxes that have a 
> CPU and a few DSPs in it.  the DSPs are reloaded with new code each time 
> there is a program change.  but i never seen anyone do that with an 
> FPGA, but there seems to be no reason conceptually that it cannot be 
> done.  but i'm no FPGA expert, so i dunno what all is involved.

It is done, but not quite as often as with a fixed configuration.

Now, in the not so distant past the ROM code for embedded processors
would be expected to be constant, but now people expect updated
firmware to be released fairly often. Internet connected blu-ray
players will check for new firmware and ask if you want to install it.

> i could imagine that a simpler way to do this would be to have a finite 
> set of algorithms to load into the FPGA and, whatever the program with 
> whatever presets it is, it would be one of those countable algorithms or 
> FPGA configurations.  

Yes, I believe that is the more usual case when there isn't a single
configuration. There are people interested in partial reconfiguration,
though. In that case, some parts stay constant while other parts of
the same FPGA are reloaded with new configuration. 

I have been interested in designs where most of the logic is fixed,
but a small part would be custom configured. For example, look-up
tables (ROMs) would be configured with specific values, but the rest
of the logic would stay the same.

Some years ago, I heard a talk from someone who had Linux running
on a PowerPC processor built into an FPGA (that is, as a logic block,
not built from programmable logic) which then reconfigured other parts
of the same FPGA while it was running. 

> it's not a totally general way to do it, but a lot 
> of boxes are like that.  they do, like, 1 of 12 things and nothing else. 
>  every preset would have, as one parameter, a spec that selects one of 
> the 12 available configurations and the other parameters in the preset 
> are just the values of specific knobs that whatever selected alg or 
> configuration uses.

Yes, to me that makes more sense than some other things that people
like to talk about. Some things that make for interesting research
projects, but aren't so practical in real problems.

I do like the idea of a programmable accelerator attached to a more
usual CPU, though. One could, for example, load logic to speed
up an FFT when one was doing that, and some other logic for other
problems. There are problems where much work can go into profitably
optimizing the logic for a specific problem. But not so many
such problems.

-- glen

On Sat, 14 Apr 2012 00:45:33 -0400, robert bristow-johnson wrote:

> On 4/13/12 9:53 PM, Impoliticus wrote:
>> An FPGA is essentially a large distributed processing unit that can be
>> customized around a problem.  You get to use the LUTS, registers,
>> multipliers, and any other building block to build up a customized
>> parallel computing engine.  The architecture of say a i7 processor is
>> so different that it's hard to compare the two technologies, at least
>> in my mind.  If you have a very specific problem to solve, an FPGA
>> makes sense.  If you want a generic computing platform, an FPGA doesn't
>> make a whole lot of sense.  However, an FPGA is generic in the sense
>> that the built in logic elements can be connected to fit the task at
>> hand.  The "Field Programmable" part of FPGAs, in my mind, is appealing
>> because it's much easier and cheaper to spin an FPGA design than an
>> ASIC.
>>
>> Enough rambling, I guess my point is that the traditional PC CPU is as
>> general/programmable as it gets.  FPGAs are targetted to solve a
>> different problem and I do not forsee FPGAs infiltrating the PC market.
> 
> not being any sort of expert with FPGA, i will say that there was a
> company i had worked for in the past (name not divulged) that had audio
> processing products that had a sorta general purpose CPU that did not
> process audio samples itself (but it did a little more work than just
> manage the front panel buttons and display) and it was connected to an
> FPGA that was loaded with its program at power up and never changed
> while the unit was on.  i understood this to be the normal way FPGAs are
> used.
> 
> there was one engineer (and he was one of the FPGA engineers) that had
> been advocating reloading the FPGA with different code (configuring it
> differently) whenever there was a program change (and they didn't take
> this guy's advice).  this is sorta how we do it with boxes that have a
> CPU and a few DSPs in it.  the DSPs are reloaded with new code each time
> there is a program change.  but i never seen anyone do that with an
> FPGA, but there seems to be no reason conceptually that it cannot be
> done.  but i'm no FPGA expert, so i dunno what all is involved.
> 
> i could imagine that a simpler way to do this would be to have a finite
> set of algorithms to load into the FPGA and, whatever the program with
> whatever presets it is, it would be one of those countable algorithms or
> FPGA configurations.  it's not a totally general way to do it, but a lot
> of boxes are like that.  they do, like, 1 of 12 things and nothing else.
>   every preset would have, as one parameter, a spec that selects one of
> the 12 available configurations and the other parameters in the preset
> are just the values of specific knobs that whatever selected alg or
> configuration uses.


My favourite way of doing just that involves PCIe hot plug.

The FPGA implements a PCI express interface and looks like just other 
PCIe peripheral to a host processor and operating system.

The processor (via a sidechannel - JTAG over USB in my case although it 
is also possible to do it via PCIe) reconfigures the FPGA to have a 
different function.  The reprogramming causes the FPGA to "unplug" from 
the PCIe and this in turn causes the OS to unload the FPGA drivers.

After the FPGA reconfiguration is complete (this will take a few seconds 
for a large part), it reappears on the PCIe and the hot plug event causes 
the OS to load drivers for the FPGA.  The drivers will be different 
because the PCI configuration registers that are read by the OS reflect 
the different functionality of the FPGA.

N.B. this only works if your PCIe infrastructure supports hot plug 
properly.  Not all PCIe switches will have the full set of control 
signals.

Regards,
Allan

robert bristow-johnson wrote:
> On 4/13/12 9:53 PM, Impoliticus wrote:
>> An FPGA is essentially a large distributed processing unit that can be
>> customized around a problem. You get to use the LUTS, registers,
>> multipliers, and any other building block to build up a customized
>> parallel
>> computing engine. The architecture of say a i7 processor is so different
>> that it's hard to compare the two technologies, at least in my mind. If
>> you have a very specific problem to solve, an FPGA makes sense. If you
>> want a generic computing platform, an FPGA doesn't make a whole lot of
>> sense. However, an FPGA is generic in the sense that the built in logic
>> elements can be connected to fit the task at hand. The "Field
>> Programmable" part of FPGAs, in my mind, is appealing because it's much
>> easier and cheaper to spin an FPGA design than an ASIC.
>>
>> Enough rambling, I guess my point is that the traditional PC CPU is as
>> general/programmable as it gets. FPGAs are targetted to solve a different
>> problem and I do not forsee FPGAs infiltrating the PC market.
>
> not being any sort of expert with FPGA, i will say that there was a
> company i had worked for in the past (name not divulged) that had audio
> processing products that had a sorta general purpose CPU that did not
> process audio samples itself (but it did a little more work than just
> manage the front panel buttons and display) and it was connected to an
> FPGA that was loaded with its program at power up and never changed
> while the unit was on. i understood this to be the normal way FPGAs are
> used.
>
> there was one engineer (and he was one of the FPGA engineers) that had
> been advocating reloading the FPGA with different code (configuring it
> differently) whenever there was a program change (and they didn't take
> this guy's advice). this is sorta how we do it with boxes that have a
> CPU and a few DSPs in it. the DSPs are reloaded with new code each time
> there is a program change. but i never seen anyone do that with an FPGA,
> but there seems to be no reason conceptually that it cannot be done. but
> i'm no FPGA expert, so i dunno what all is involved.
>

It can be done and is done. Depending on the size of the bitmask going
into the FPGA and the speed of the interface over which the FPGA is 
reprogrammed,  it can be rather slow...

> i could imagine that a simpler way to do this would be to have a finite
> set of algorithms to load into the FPGA and, whatever the program with
> whatever presets it is, it would be one of those countable algorithms or
> FPGA configurations. it's not a totally general way to do it, but a lot
> of boxes are like that. they do, like, 1 of 12 things and nothing else.
> every preset would have, as one parameter, a spec that selects one of
> the 12 available configurations and the other parameters in the preset
> are just the values of specific knobs that whatever selected alg or
> configuration uses.
>


For basic variable parameters, it's better* to use registers between
the General Purpose Processor and FPGA, and have the GPP vary them.

* in terms of reducing "Please wait" time...

--
Les Cargill

On 4/13/2012 6:53 PM, Impoliticus wrote:
> An FPGA is essentially a large distributed processing unit that can be
> customized around a problem.  You get to use the LUTS, registers,
> multipliers, and any other building block to build up a customized parallel
> computing engine.  The architecture of say a i7 processor is so different
> that it's hard to compare the two technologies, at least in my mind.

FPGA's -- and all similar/predecessor "logic devices" -- try to be
general purpose solutions to general LOGIC problems -- from PAL's/PLA's
(I can never remember which term appeared first :< ) with simple
and-or arrays through CPLD's, ASIC's, FPGA's, etc.

> If
> you have a very specific problem to solve, an FPGA makes sense.  If you

Exactly.

> want a generic computing platform, an FPGA doesn't make a whole lot of
> sense.

Exactly.

> However, an FPGA is generic in the sense that the built in logic
> elements can be connected to fit the task at hand.  The "Field
> Programmable" part of FPGAs, in my mind, is appealing because it's much
> easier and cheaper to spin an FPGA design than an ASIC.

FPGA's are great for prototyping -- you don't have to spend lots of
money each time you "turn the crank".  Nor, wait many weeks for
the fab to produce new samples for evaluation.

*All* programmable logic devices are a win when it comes to
implementing "junk logic" -- random bits of logic that you can't
buy COTS for your particular application in the same cost/form
factor, etc.

You can get comparable gate/transistor counts between CPUs and
PLD's -- though production quantities will tend to favor the
CPU in terms of cost/availability.  And, I think the effective
gate *utilization* of CPUs is higher (per unit area) than FPGA's
since so much of an FPGA is lost to routing costs, etc.

> Enough rambling, I guess my point is that the traditional PC CPU is as
> general/programmable as it gets.  FPGAs are targetted to solve a different
> problem and I do not forsee FPGAs infiltrating the PC market.

FPGA's let *you* decide on the degree of resource allocation (Si),
parallelism, etc. that you want to throw at a problem.  A CPU
hard-codes that into an "architecture"/programmer model.

With CPUs getting *so* much faster and so much more integrated,
it's often easier to buy a COTS CPU/SoC and write some code
for it than trying to design some VHDL to do the same thing
in a PLD.  (Also, the skillsets of the developers vary... you
can find someone to write a piece of code a lot easier than
someone to write the equivalent VHDL!)

And, logic designs tend to be a lot less "portable" than "software".

If it made sense (OP's comment), the market would already have
embraced it.

On 4/14/12 11:57 AM, Don Y wrote:
>
> FPGA's -- and all similar/predecessor "logic devices" -- try to be
> general purpose solutions to general LOGIC problems -- from PAL's/PLA's
> (I can never remember which term appeared first :< )

it was PLA for me, and i don't even remember the part numbers.  but the 
*last* sorta thing i ever learned to do with digital electronics was 
programming a PLA (or PALs, if you're Barney the purple dinosaur) and 
hook it up to a microprocessor (usually to deal with DRAM refresh and 
address decoding to chip-select).

when FPGAs came out, i was sorta already past getting my feet wet. 
never did hardware again since, i dunno, 1989.

>
>> If
>> you have a very specific problem to solve, an FPGA makes sense. If you
>
> Exactly.
>
>> want a generic computing platform, an FPGA doesn't make a whole lot of
>> sense.
>
> Exactly.
>
>> However, an FPGA is generic in the sense that the built in logic
>> elements can be connected to fit the task at hand. The "Field
>> Programmable" part of FPGAs, in my mind, is appealing because it's much
>> easier and cheaper to spin an FPGA design than an ASIC.

i think, if you're an FPGA jock, you could reprogram it in a similar way 
that we reprogram DSPs or GPUs or whatever accelerator we hang offa a "GPP".

>
> FPGA's are great for prototyping -- you don't have to spend lots of
> money each time you "turn the crank". Nor, wait many weeks for
> the fab to produce new samples for evaluation.
...
>> Enough rambling, I guess my point is that the traditional PC CPU is as
>> general/programmable as it gets. FPGAs are targetted to solve a different
>> problem and I do not forsee FPGAs infiltrating the PC market.

how about the DSP market?  does it make sense to hang an FPGA offa a CPU 
to be your hard-core fire-breathing sample processing machine. 
especially for high sample rate (like for video or, maybe astronomical 
signal processing... Clay or glen, what kind of sample rates do these 
telescope guys have for processing whatever comes offa their radio or 
infrared or optical telescopes?)

>
> FPGA's let *you* decide on the degree of resource allocation (Si),
> parallelism, etc. that you want to throw at a problem. A CPU
> hard-codes that into an "architecture"/programmer model.

hard-codes?  CPU?  i thought that's where things got soft and flabby.

(remember, at least in the olden daze, computers were sorta like sex, 
except what you do is take the software and stick it into the hardware. 
  now it's different, you get both your sex and your software offa the 
internet.  but the difference is usually after downloading software, 
you're still typing with both hands.)



> With CPUs getting *so* much faster and so much more integrated,
> it's often easier to buy a COTS CPU/SoC and write some code
> for it than trying to design some VHDL to do the same thing
> in a PLD. (Also, the skillsets of the developers vary... you
> can find someone to write a piece of code a lot easier than
> someone to write the equivalent VHDL!)

i'm sure that's true.

> And, logic designs tend to be a lot less "portable" than "software".

well, i dunno.  with VHDL or Verilog or whatever it is, can't you 
reasonably port a block of logic function from one thing to another 
(assuming both things had sufficient capability)?

> If it made sense (OP's comment), the market would already have
> embraced it.

well, this is what i was wondering about (as an FPGA ignoramous).

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

robert bristow-johnson <rbj@audioimagination.com> writes:

> there was one engineer (and he was one of the FPGA engineers) that had
> been advocating reloading the FPGA with different code (configuring it
> differently) whenever there was a program change (and they didn't take

This is a little cumbersome, as you will typically reset all your
registers etc. to the reset state when re-loading the FPGA. 

The FPGA vendors are now making this task easier with partial
reconfiguration over PCIe etc:

http://www.altera.com/devices/fpga/stratix-fpgas/stratix-v/overview/partial-reconfiguration/stxv-part-reconfig.html

Then there is Tabula where the FPGA configuration is changed several
thousand times per second:

http://www.tabula.com/technology/technology.php

//Petter

-- 
.sig removed by request.