FPGARelated.com
Forums

Is FPGA code called firmware?

Started by Marko February 20, 2006
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