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 ;-)

Reply to
Austin Franklin
Loading thread data ...

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

The following three claims are releated:

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

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.

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"?

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

Reply to
Marc Randolph

that I

guys

gates

It's

you

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

Reply to
Jeroen

See also "Emulating FPGAs using Processors"

formatting link

Jan Gray

Reply to
Jan Gray

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

Reply to
john jakson

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

Reply to
Bob Perlman

I

#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 - 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

  • 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 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 ?

!?

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.

here you go with smile :)

overall comment: 200% incompetence!

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

Reply to
Antti Lukats

Hi John,

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

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

Reply to
Austin Franklin

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!

Reply to
Austin Franklin

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
 Click to see the full signature
Reply to
Hal Murray

Homework?

Reply to
Mark McDougall

Until it is sitting there, gleaming at you on the wafer, it is 100% software. Once it is designed, and you want your second million, then it is very much hardware. So it is one of those semantics arguments, that depends on where you are in the design life cycle.

-jg

Reply to
Jim Granville

dozen

anyone

By your understanding, any design, what so ever, is software? Even a schematic? So, a board level schematic is software as well? VHDL and Verilog code is software?

I very much disagree that it is a semantics argument. It is an argument of understanding or not understanding concepts IMO.

Regards,

Austin

Reply to
Austin Franklin

Not really.

Reply to
Austin Franklin

Well, the LUT's do emulate logic gates. The interconnect, though, is programmable rewiring, at least traditionally done with pass transistors, though now maybe more often with multiplexers. Close enough to rewiring for me.

So? Where is the question?

Is verilog code for an ASIC software or hardware?

Well, OTP EPROM is already a contradiction. Most people call it firmware, though.

An SRAM chip can be soldered into a board, and is usually implemented in Silicon, though SiGe, or GaAs could also be used, does that matter?

Is this supposed to change the argument that FPGA code is or isn't software?

Look up tables have been part of software design for as far back as I know it. Sometimes an address will be loaded from a table as a branch targer, which makes the table darn close to executable code. In others, a table of branch instructions is used as a target of an indexed branch, which definitely makes the table executable.

Much software is table driven, where the code in the table is interpreted in some way by directly executable code.

Many machines are microprogrammed, so that what you think of as hardware is really software.

Trying to make fine distinctions between hardware and software is a losing proposition. Don't do it.

-- glen

Reply to
glen herrmannsfeldt

Until it is constructed, and thus gets the 'Hard' in hardware, yes.

Yes.

As Hardware Description language, yes. Software has two portions, the Data or your idea itself, and the programs you buy, that Compile/Change that data.

If one argues that Software is only commercial compilers, then one must introduce a third category - Dataware/Ideaware ?

Consider where the 'Hard' in hardware comes from ? If you can hit it with a hammer, it is hardware, if it is an idea, in whatever form, and does not need power, it is software. ( ie can you save it onto a CD ROM ? - then it is not hardware )

This can get even more semantic content, if one argues that a Printed Schematic is tangible, can be burnt, uses ink, and is thus hardware. Or that the physical storage on a CD Rom uses physical phase change, so that too is physical/hard in nature.... :)

-jg

Reply to
Jim Granville

(snip)

It is that you can save "it" on the CDROM. Being able to save an image of something, say a picture of a computer, doesn't count.

A printed source listing or hex dump?

Anyway, the word firmware has been used, usually for microcode that is changable but normally doesn't change in everyday use.

It is then often used for ROMs in microprocessor controlled devices, again it is not changed in ordinary use, even though it might be EPROM, EEPROM, or Flash RAM, or even battery backed SRAM.

Now, how about the wiring plugboards that used to control many IBM machines in the pre-computer days? The wire itself is hardware, but the positioning of the wires is software. (It could be stored in netlist form, for example.)

-- glen

Reply to
glen herrmannsfeldt

Isn't that why they coined the term 'firmware'? ;)

--
|              Mark McDougall                | "Electrical Engineers do it
|                    |   with less resistance!"
Reply to
Mark McDougall

Hi Austin, As I shake my head in wonderment reading your post, I think to myself (and not for the first time :-)

"Self, isn't it great that all the really crazy clients end up in Austin's bucket"

Depending on vendor, the memory that is changed may be volatile or non-volatile. By far, the volatile memory devices are the dominant products in use. A & X.

Since the devices are volatile, and infinitely re-programmable, just like a CPU, no physical modification of the internal wires occurs.

But, for the non-volatile devices that use anti-fuse, the interconnect intersections are physically changed, and I think you might describe it as "wiring" , not "rewiring" since the initial state is nothing conected to nothing.

Absolute B.S.

Hardware: Case, PSU, PCB, ALL components on the PCB, disk drives, terminals resistors, caps, diodes, transistors, wires, connectors, switches, CPU chips, modems, FPGAs, CPLDs, etc, etc, etc.

Software: Fortran, COBOL, Assembler, BASIC (All forms), C, C++, Python, Perl, TCL/TK, ...... The compiled or interpreted version of the above list when loaded into memory (typically volatile) on a processor.

Firmware: Software that is loaded into non-volatile memory.

Specifications: (in your head, in a file on disk, printed on paper, punched on punch cards, punched on paper tape, On magnetic tape........) Any description of the hardware, including: Schematics, VHDL, Verilog, PAL eqn, AHDL, CUPL, ..... Any description of the software that is not the actual software

B.S.

i.e. character map for a CRT.

Last time I designed an FPGA (and I do mean "designed", not "designed with") it sure had a lot of real LUTS being implemented in silicon.

Total B.S.

What if the FPGA config stream is in a ROM. If I need to make a change, out comes the soldering iron.

What if I am insane and chose to use an anti fuse part. Need a soldering iron to make changes here too.

B.S.

Todays FPGA LUTs are sub 1.0 ns. A DSP needs to fetch an instruction, decode it, figure out it is indexing memory, go fetch, etc, etc, etc.

He couldn't have looked very far, since he hasn't talked to me about reality. Please do not give him my name. You should handle this.

Enjoy your argument :-)

Philip

Philip Freidin

For the US news media, there is nothing so important or relevant, that it can't be ignored in favor of some new, bright and shiny irrelevancy.

Reply to
Philip Freidin

A while back I was deposed for a patent infringement law suit. The oppositions lawyer were trying to prove that my "hardware search engine" built in an FPGA was really a "software search engine" because anything in an FPGA was really software. Don't know how that one turned out as I'm no longer with that company, but: Lawyers - ya gotta love em!

Reply to
Dan K

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.