Need some help with some technical claims...

I need some help with something.  Someone made some technical claims that I
am questioning are correct or not ;-), and would like to see what you guys
think about these claims:

#1> Programming FPGAs doesn't actually change or rewire those logic gates

#1> in the silicon wafer. It changes bits of non-volatile memory that is

#1> used as inputs to these gates. (These are not the gates you see when

#1> you write the FPGA code, those are emulated by a combination of

#1> hardwired gates and your code.)



#2>Software is defined as the part of a digital circuit that can be

#2>changed without mechanical modifications, as opposed to hardware,

#2>which is HARDwired. So FPGA code is software



#3> OTP EPROM data ... has always been regarded as software.



#4> A LUT is not a device soldered onto the circuit board. It's not even

#4> implemented in silicon (at least during the development stages). It's

#4> programmed into an FPGA or suchlike and therefore software because you

#4> can change it without any mechanical changes on the board.



#5> Using a sufficiently parallelized, a LUT done in a DSP can be just as

#5> efficient as using an FPGA or ASIC.



Any input appreciated ;-)

"Austin Franklin" <austin@dark99room.com> wrote in message news:<10k58kelcgkcnfc@corp.supernews.com>...
> I need some help with something.  Someone made some technical claims that I
> am questioning are correct or not ;-), and would like to see what you guys
> think about these claims:
> 
> #1> Programming FPGAs doesn't actually change or rewire those logic gates
> #1> in the silicon wafer. It changes bits of non-volatile memory that is
> #1> used as inputs to these gates. (These are not the gates you see when
> #1> you write the FPGA code, those are emulated by a combination of
> #1> hardwired gates and your code.)

I don't believe this the above exactly correct, but I'll let someone
else comment on it.

The following three claims are releated:

> #2>Software is defined as the part of a digital circuit that can be
> #2>changed without mechanical modifications, as opposed to hardware,
> #2>which is HARDwired. So FPGA code is software

So a memory chip itself is software?  It doesn't require any
mechanical modifications to change.

> #3> OTP EPROM data ... has always been regarded as software.

The _data_ within a memory chip doesn't necessarily have to be
software.  It can be pure data (a serial number, for example). 
Software implies to me that it is executable.

> #4> A LUT is not a device soldered onto the circuit board. It's not even
> #4> implemented in silicon (at least during the development stages). It's
> #4> programmed into an FPGA or suchlike and therefore software because you
> #4> can change it without any mechanical changes on the board.

Again, the same would apply to a memory chip.  In fact, a LUT _is_
memory.  In addition, ever notice that FPGA's are called "SRAM based
devices"?

> #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as
> #5> efficient as using an FPGA or ASIC.

I do not understand what is being claimed here.  Almost any device can
do a single LUT function as efficiently as any other device... but
what about 20k LUTs?

    Marc

"Marc Randolph" <mrand@my-deja.com> wrote in message
news:15881dde.0409110423.20cd5e6e@posting.google.com...
> "Austin Franklin" <austin@dark99room.com> wrote in message
news:<10k58kelcgkcnfc@corp.supernews.com>...
> > I need some help with something.  Someone made some technical claims
that I
> > am questioning are correct or not ;-), and would like to see what you
guys
> > think about these claims:
> >
> > #1> Programming FPGAs doesn't actually change or rewire those logic
gates
> > #1> in the silicon wafer. It changes bits of non-volatile memory that is
> > #1> used as inputs to these gates. (These are not the gates you see when
> > #1> you write the FPGA code, those are emulated by a combination of
> > #1> hardwired gates and your code.)
>
> I don't believe this the above exactly correct, but I'll let someone
> else comment on it.
>
> The following three claims are releated:
>
> > #2>Software is defined as the part of a digital circuit that can be
> > #2>changed without mechanical modifications, as opposed to hardware,
> > #2>which is HARDwired. So FPGA code is software
>
> So a memory chip itself is software?  It doesn't require any
> mechanical modifications to change.
>
> > #3> OTP EPROM data ... has always been regarded as software.
>
> The _data_ within a memory chip doesn't necessarily have to be
> software.  It can be pure data (a serial number, for example).
> Software implies to me that it is executable.
>
> > #4> A LUT is not a device soldered onto the circuit board. It's not even
> > #4> implemented in silicon (at least during the development stages).
It's
> > #4> programmed into an FPGA or suchlike and therefore software because
you
> > #4> can change it without any mechanical changes on the board.
>
> Again, the same would apply to a memory chip.  In fact, a LUT _is_
> memory.  In addition, ever notice that FPGA's are called "SRAM based
> devices"?

SRAM based means the configuration memory is SRAM, most FPGAs have this, but
there's also Flash based configuration memory and EEPROM, and
fuse/anti-fuses.
So SRAM based does not refer to the LUT.

Jeroen

"Marc Randolph" <mrand@my-deja.com> wrote in message
> I do not understand what is being claimed here.  Almost any device can
> do a single LUT function as efficiently as any other device... but
> what about 20k LUTs?

See also "Emulating FPGAs using Processors"
[http://www.fpgacpu.org/usenet/emulating_fpgas.html]

Jan Gray

"Austin Franklin" <austin@dark99room.com> wrote in message news:<10k58kelcgkcnfc@corp.supernews.com>...
> I need some help with something.  Someone made some technical claims that I
> am questioning are correct or not ;-), and would like to see what you guys
> think about these claims:
> 
> #1> Programming FPGAs doesn't actually change or rewire those logic gates
> 
> #1> in the silicon wafer. It changes bits of non-volatile memory that is
> 
> #1> used as inputs to these gates. (These are not the gates you see when
> 
> #1> you write the FPGA code, those are emulated by a combination of
> 
> #1> hardwired gates and your code.)
> 
> 
> 
> #2>Software is defined as the part of a digital circuit that can be
> 
> #2>changed without mechanical modifications, as opposed to hardware,
> 
> #2>which is HARDwired. So FPGA code is software
> 
> 
> 
> #3> OTP EPROM data ... has always been regarded as software.
> 
> 
> 
> #4> A LUT is not a device soldered onto the circuit board. It's not even
> 
> #4> implemented in silicon (at least during the development stages). It's
> 
> #4> programmed into an FPGA or suchlike and therefore software because you
> 
> #4> can change it without any mechanical changes on the board.
> 
> 
> 
> #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as
> 
> #5> efficient as using an FPGA or ASIC.
> 
> 
> 
> Any input appreciated ;-)


Most of the pts don'r read as if written by an EE.

Sounds like you are arguing with a lawyer, waste of time unless you
have a patent dispute or something.

regards

johnjakson_usa_com

On Sat, 11 Sep 2004 03:00:29 -0400, "Austin Franklin"
<austin@dark99room.com> wrote:

>I need some help with something.  Someone made some technical claims that I
>am questioning are correct or not ;-), and would like to see what you guys
>think about these claims:

<claims snipped>
>
>Any input appreciated ;-)
>

The way these claims are written reminds me of a story about physicist
Wolfgang Pauli.  Some guy off the street showed him a paper and asked,
"Is this true?"  Pauli glanced at it, then said, "This isn't even
false."

I know, it's no help :)

Bob Perlman
Cambrian Design Works

"Austin Franklin" <austin@dark99room.com> wrote in message
news:10k58kelcgkcnfc@corp.supernews.com...
> I need some help with something.  Someone made some technical claims that
I
> am questioning are correct or not ;-), and would like to see what you guys
> think about these claims:
>
> #1> Programming FPGAs doesn't actually change or rewire those logic gates
> #1> in the silicon wafer. It changes bits of non-volatile memory that is
> #1> used as inputs to these gates. (These are not the gates you see when
> #1> you write the FPGA code, those are emulated by a combination of
> #1> hardwired gates and your code.)

#1 - lets see what wrong with

1) "changes bits of non-volatile memory" - WRONG an FPGA doesnt have to have
any-nonvolatile memory, in the fact almost all FPGAs do not have
non-volatile memory. Actually as of today NO FPGA has non-volatile memory in
the that sense - FPGAs have non-volatile configuration memory, not user
accessible non-volatile memory. Exceptions:
a) new upcoming to be announced ProAsic FPGA are the first one to have on
chip non-volatile memory (other than configuration).
b) Altera MAX2 has non-volatile "user" memory - it is not marketed as an
FPGA but actually it is a small FPGA with no Block RAMs

2) changes bits of [] memory" - if we leave out the non-volatile (see
comment above) then the sentense is still wrong. And FPGA doesnt have to
have any memory in the sense of an memory-array - a fuse or via-mask
programmable FPGA with no embedded RAMs does not have any memory unless the
memory is made up from fabric logic and flip flops.

3) Programming FPGA's - well the "Programming" is actually very bad word to
use with FPGAs - there do exist some tools that allow and unprogrammerd FPGA
silicon (like Actel fuse programmable FPGA's) to be actually programmed, its
and metal box called Activator. Using that tool you can actually program an
FPGA you blow some fuses and convert and blank silicon to programmed
silicon. Any other means of putting an design into an FPGA are not direct
"FPGA programming". There are of different "programming" steps involved with
the FPGAs but very rearly the programming is actually changing the silicon
at all. A configuration memory can be programmed but that is usually
external to FPGA except for Atmel A94KxxS series (those are multichip
packages). Also a programming can be understood as writing an program for
some processor that is implemented in the FPGA fabric, then we write
programs in some programming language what is later "executed" by the FPGA.

4) "write FPGA code" - there is no such thing as FPGA code, you can write
code for some processor (that can be implemented in FPGA of course), but for
FPGA you write some code that describes something - this is translated to
FPGA technology primitives. you can use the low level primitives in your
code too, but its not really writing FPGA code - FPGAs dont have code - they
have configuration that makes them to be the hardware you have described.

5) ... more claims I cant even understand, emulated by gates and your code?
the source code is converted into something that emulates the required
functionality, yes but the original author did not mean that?

> #2>Software is defined as the part of a digital circuit that can be
> #2>changed without mechanical modifications, as opposed to hardware,
> #2>which is HARDwired. So FPGA code is software

#2 - is total bullshit

* software doesnt have to be part of anything!
* a punched paper tape is software even if it never used.
* not always can software be altered without mechanical modification, so
that makes software a hardware or what?
* a programmed FPGA doesnt have any "code" it can be just some blown fuses
(what I woudl not consider as code)
* an FPGA can contain processors that execute code internal or external to
FPGA, that code is software sure, but this code can be fused into silicon
what makes the software hardware?

== # bullshit

> #3> OTP EPROM data ... has always been regarded as software.

* OTP doesnt have to be EPROM
* some specif location of data (being in EPROM, OTP or not) doent make it
software

OTP means one time programmable, be it using electrica means or laser or
mask

> #4> A LUT is not a device soldered onto the circuit board. It's not even
> #4> implemented in silicon (at least during the development stages). It's
> #4> programmed into an FPGA or suchlike and therefore software because you
> #4> can change it without any mechanical changes on the board.

#4 more bullshit comes..
* "It's not even implemented in silicon" - cant be more wrong - LUT's are
what actually *is* implemented in silicon
* "It's programmed  into an FPGA" wrong LUT is not programmed (programming
means altered by user) into silicon it exists there, it will beconfigured
todo some function, yes but not programmed "into FPGA" its there already.
* "therefore software because you can change it without any mechanical
changes on the board" - on board? or on silicon? if you program an LUT based
(non SRAM) FPGA using an laser or masl its mechanical so it would make the
LUT hardware? and when the FPGA is configured by electrical means its
software ?

!?

> #5> Using a sufficiently parallelized, a LUT done in a DSP can be just as
> #5> efficient as using an FPGA or ASIC.

LUT done in a DSP as efficient !?

cant be more wrong than that!!!

first there is never a need todo an LUT with DSP, and even fastest DSP
utilizing 100% of the foreground time can not do the same work of one single
LUT (at the same speed!), but FPGA's have 10,000+ LUTs !!!

second the fastest DSP still cant compete with FPGA doing digital signal
processing (and DSP are designed for it), FPGAs will always outperform DSPs
when doing DSP algorithms.

the reason why DSPs are used is cost not performance. when doing somewhat
fixed DSP algorithms FPGAs are better also costwise. just the DSP algorithms
in FPGA are not so "soft" as in DSPs that makes the difference.

> Any input appreciated ;-)

here you go with smile :)

overall comment: 200% incompetence!

Antti -
[a FPGA guru with 25+ years Electrical engineering backround

Hi John,

> Most of the pts don'r read as if written by an EE.

You are correct.  He is a physicist who has done one or possibly a couple of
FPGA designs.

> Sounds like you are arguing with a lawyer, waste of time unless you
> have a patent dispute or something.

Just trying to get input from others in this field as to what they think of
his "claims" of knowledge on this subject.

Regards,

Austin

One more claim from our "candidate":

"And none of the professionals I've talked to referred to ASICs being
hardware. You can't buy an ASIC, you have to design it, which makes

its function software."

And being a professional EE for over 25 years, having designed a few dozen
ASICs, and worked with hundreds of ASIC designers, I've never heard anyone
refere to ASICs as anything but hardware.  So, I can't imagine what
professionals he is referring to that would think an ASIC was software!

>And being a professional EE for over 25 years, having designed a few dozen
>ASICs, and worked with hundreds of ASIC designers, I've never heard anyone
>refere to ASICs as anything but hardware.  So, I can't imagine what
>professionals he is referring to that would think an ASIC was software!

How about software that gets burned into a ROM?

What fraction of the design manpower for a typical modern ASIC is
like designing software in the sense of simulation and chasing
logic bugs as compared to analog and chasing timing bugs?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.