Is FPGA code called firmware?

mk schrieb:

>>VHDL may "produce" hardware when doing ASIC design.
> 
> So what do you call a gate array or structured asic ? What does VHDL

This is an ASIC too, just with a reduced number of user defined 
parameters (since most geometries are already fixed).

> do when it generates files for one of these processes ? (for the
> uninitiated gate-arrays or structured asics in general have all their
> base layers produced already and several metals are used configure the
> manufactured general purpose gates to what you want and provide the
> connectivity). 

Yep.

> By the same token when you take a bit file generated for an FPGA and
> use it to produce a hard-copy device (a structured asic specifically
> generated for a certain FPGA family) does the VHDL suddenly realize
> that it has produced hardware ? What does this say for laser trim or

There is always an exeption to every rule ;-)

> metal only ECO ?
> Also is an Intel or AMD processor really hardware as they have
> micro-code which can be downloaded by BIOS which can be used to fix
> quite a bit of "issues" with the processor.

SoC ;-)

>>In an FPGA not a single bit is "produced", all is fixed. 
> 
> 
> So the function of each LUT and how they are all connected are fixed
> and the VHDL doesn't produce anything ? What does it do then ? If in

Neither did I not write this nor did I say this. Nevertheless, 
incomplete quotes are quite popular.

> my standard cell design, I have memory based FSMs the function of
> which can be changed by updating the contents of such, does my asic
> become software ? What about external pins which can change the

The chip will stay an ASIC. But you can (and will) download firmware.

> behaviour of combinational FSMs ?

;-) C'mon.

> I think the issue is a lot less clean-cut then is suggested here.

Maybe. Thats why we are here to discuss. Or to argue. Or to get into 
philosopy. The last works a lot better with a nice bottle of red wine ;-)

Regards
Falk, taking this "issue" not too serious, since it is quite academic

On Mon, 2006-02-20 at 10:18 -0800, Marko wrote:
> Traditionally, firmware was defined as software that resided in ROM.
> So, my question is, what do you call FPGA code?  Is "firmware"
> appropriate? 

In a former position I pondered this very question.

What is firmer than firmware (the term they used to describe code
designs for micro-controllers) but softer than hardware (designs using
wires to connect together various components)?

The answer I came up with was "stiffware".

The problem is that there are elements of both in FPGA code, or at least
there can be.  And depending on how you write your VHDL it may resemble
one more than the other.

James.

Julian Kain wrote:
> The difference is execution versus synthesis. Firmware is indeed
> embedded and dedicated code, but the code is executed. FPGA code is
> written in a _description_ language, is then interpreted, synthesized,
> and ultimately produces hardware.

So, for Reconfigurable Computing, where we compile C directly to
netlists to execute certain algorithms with high degrees of
parallelism, use a sea of logic resources as a universal computer
architecture, .... it's hard to consider the resulting fpga "design"
(AKA program) either hardware or firmware.

There is a reason I call FpgaC an HDL, and move it's syntax and use to
mainstream computing (rather than leave it in it's original HLL focus
when it was TMCC). But that really is true of other C compilers that
target some C subset/superset HLL/HDL's such as Handel-C (Celoxica) or
Streams-C (Impluse-C) as well.  Some people use
FpgaC/Handel-C/Streams-C to design "hardware" some just use it to run
"software" on FPGA's.

For that mater, the same is true of VHDL, Verilog, JHDL, and some dozen
other FPGA centric HDL/HLL tools.

Falk Brunner wrote:

> What code? The source code (VHDL/Verilog/whatever) or the final
> bitstream? The same distinction applies to microprocessor "Firmware",
> where you have the source code and the compiled binary.
> Hmm, the more I write and think about it (where it should be better the
> other way around ;-) FPGA and microprocessor bitstreams are becomming
> more and more similar "Firmware".

Enter dynamic reconfigurability, and it's not even "firmware" any more
... not hard locked in even a rom for many designs.  More like a solid
state disk, IE compact flash card, used has the primary storage in many
portable computer devices, and a growing number of not so portable
devices, to avoid hard drives. Sometimes, with even network driving
dynamic loading, where all that is "rom'd" is a "boot loader", and the
rest of the design is fetched off the net at powerup.

soar2morrow@yahoo.com wrote:
>  FPGA code is logic, not programmable
> instructions (spare me comments on the Micro-Blaze and its ilk).
> Personally, I would like to see a different term beause non-FPGA people
> will think that you are talking about a general purpose programmable
> computer. How about "coreware"?. Don't like it? Then invent your own.

FPGA code USED TO BE (some ten or more years back) only a hardware
designer accessable logic resource, that you *MIGHT* class as "not
programmable instructions".

The reality is (for the last 10 years) C compilers have compiled to
netlists to execute HDL algorithms and programs directly on FPGA's.
When Reconfigurable Computing was proposed, and researched over a
decade ago, we also saw various HLL compilers targeting FPGA netlists
as execution resources.  TMCC is just one of many, and reciently it
rebirthed at FpgaC. Handel-C, Streams-C, and nearly a dozen others,
have also since appeared. Several are here to stay, some are lost
research projects.

C language code, is a combination of "logic" and "data path"
representations. Actually, just about all programs are. Each LUT/FF
pair is a minimal one bit state machine building block which with
programable routing resources form wider and more complex state
machines and data paths, which are highly configurable  **AND**
PARALLEL!!!  An FPGA is the ultimate UNIVERSAL computing engine. Most
HLL's are simply description languages for data path and state machine
engines ... a perfect mariage with FPGAs that provide exactly those
resources in the most configurable way.

Marko wrote:
> Traditionally, firmware was defined as software that resided in ROM.
> So, my question is, what do you call FPGA code?  Is "firmware"
> appropriate? 
At my previous employer, a proposal was submitted and the Xilinx 
configuration files were called firmware. Someone forgot to read the RFP 
carefully, because we were specifically prohibited from developing 
firmware. The proposal was changed, I believe to 'configuration file'.


---
Joe Samson
Pixel Velocity

fpga_toys@yahoo.com schrieb:

> Enter dynamic reconfigurability, and it's not even "firmware" any more
> .... not hard locked in even a rom for many designs.  More like a solid

I would'nt connect the term "Firmware" to ROMs. For my understandig so 
far, Firmware is data in any storage medium (ROM/RAM/FLASH/Network) that 
is loaded into a "Execution memory", for a processor it will be RAM, for 
a FPGA it will be Config-RAM, or if yo like RAM for FSMs.
How about this "definition"?

Regards
Falk

Firmware is instruction-stream-based - more precisely:
micro-instructions for programming the inner machine in a nested
machine, where an instruction of the outer machine is executed by a
sequence of micro-instruations by the inner machine.

Programming FPGAs etc., however is NOT instruction-stream-based (i. e.
NOT a procedural issue), and it should not be called "software" how
some people do, because a software compiler generates an instruction
schedule. Configuration code, however, is NOT an instruction schedule.
It is a structural issue (but NOT procedural).

The sources for compilation into configuration code should be called
CONFIGWARE, and not software, nor firmware. A typical configware
compilation process uses placement and routing, however, NOT
instruction scheduling.

FPGA code I call configware code - the output of configware compilation
of design flow

Best regards,
Reiner
http://fpl.org/RCeducation/

reiner@hartenstein.de schrieb:
> Firmware is instruction-stream-based - more precisely:
> micro-instructions for programming the inner machine in a nested
> machine, where an instruction of the outer machine is executed by a
> sequence of micro-instruations by the inner machine.

This may be your personal point of view, but this is not common sense.

> Programming FPGAs etc., however is NOT instruction-stream-based (i. e.
> NOT a procedural issue), and it should not be called "software" how
> some people do, because a software compiler generates an instruction
> schedule. Configuration code, however, is NOT an instruction schedule.
> It is a structural issue (but NOT procedural).

Right.

> The sources for compilation into configuration code should be called
> CONFIGWARE, and not software, nor firmware. A typical configware
> compilation process uses placement and routing, however, NOT
> instruction scheduling.

> FPGA code I call configware code - the output of configware compilation
> of design flow

Welcome to the post-babylonian world ;-)

Regards
Falk

reiner@hartenstein.de schrieb:

> [...] Configuration code, however, is NOT an instruction schedule.
> It is a structural issue (but NOT procedural).
> 
>[...] A typical configware
> compilation process uses placement and routing, however, NOT
> instruction scheduling.

Now, this discussion is going to become really interesting with multi
context FPGAs. In that case there is a stream of very few very large
instructions.

Configware is ok, but I like stiffware better because it fits nicely
between software, firmware and hardware.

Kolja Sulimma