Is FPGA code called firmware?

Traditionally, firmware was defined as software that resided in ROM. So, my question is, what do you call FPGA code? Is "firmware" appropriate?

Reply to
Marko
Loading thread data ...

Marko schrieb:

Why not?

Regards Falk

Reply to
Falk Brunner

Are you answering my question with a question?

Seriously, I just want to know what other people call it. It seems incorrect to refer to FPGA code by the same name used for ROMable S/W. At my previous job, we just called it "FPGA Code". At my new job, it's called "firmware".

Reply to
Marko

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, I see it fit to refer to the FPGA, when it is configured, as hardware, and to the code itself as a description language.

Julian

Reply to
Julian Kain

Marko schrieb:

I don't see the big problem there. There are hundreds of synonyms floating around. "FPGA-Code" is more or less the same as "Firmware". There is no official definition or standard, also no defacto standard. So call it whatever you like it as long as it's in sync with the people you are talking to.

Regards Falk

Reply to
Falk Brunner

Julian Kain schrieb:

VHDL may "produce" hardware when doing ASIC design. In an FPGA not a single bit is "produced", all is fixed. Only the connections between the bits are set, so all that is done in an FPGA is configuration. Surprisingly this process is called configuration for quite a long time ;-)

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

Regards Falk

Reply to
Falk Brunner

At one previous place of employment, we called it Roland C. Higgenbottom the Third. We figured we could charge extra by making it sound more dignified than it actually was.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

So what do you call a gate array or structured asic ? What does VHDL 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). 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 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.

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 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 behaviour of combinational FSMs ?

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

Reply to
m

Dunno if it's appropriate, but I see it called that in many places. "FPGA configuration file" is probably best, but that makes managers' eyes cross. Call it "firmware" and it sounds safely familiar.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

One should check out the source of the term "firmware". I suspect that most of you weren't around in the early 70's when the term was invented (at least not in the professional sense). Firmware was invented with the advent of microcoded computers. Microcode is "software", but a different kind of software than most of us were familiar with. And, usually, it wasn't something that the user could change (with a very few exceptions). So they came up with "firmware", meaning it was programmed into read-only memories (ROM). Eventually, anything programmed into ROM, EPROM, EEPROM, etc. became known as firmware. But it was, still, instructions that were fed to an instruction execution unit, one at a time sequentially. 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.

Tom

Reply to
soar2morrow

mk schrieb:

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

Yep.

There is always an exeption to every rule ;-)

SoC ;-)

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

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

;-) C'mon.

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

Reply to
Falk Brunner

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.

Reply to
James Morrison

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.

Reply to
fpga_toys

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.

Reply to
fpga_toys

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.

Reply to
fpga_toys

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
Reply to
Joseph Samson

fpga snipped-for-privacy@yahoo.com schrieb:

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

Reply to
Falk Brunner

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

formatting link

Reply to
reiner

snipped-for-privacy@hartenstein.de schrieb:

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

Right.

Welcome to the post-babylonian world ;-)

Regards Falk

Reply to
Falk Brunner

snipped-for-privacy@hartenstein.de schrieb:

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

Reply to
Kolja Sulimma

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.