EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

Is FPGA code called firmware?

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Is FPGA code called firmware?

Goto page 1, 2, 3, 4  Next

Marko
Guest

Mon Feb 20, 2006 7:18 pm   



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

Julian Kain
Guest

Mon Feb 20, 2006 8:39 pm   



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

Falk Brunner
Guest

Mon Feb 20, 2006 9:01 pm   



Julian Kain schrieb:
Quote:
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.

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

Quote:
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.

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 Wink FPGA and microprocessor bitstreams are becomming
more and more similar "Firmware".

Regards
Falk

Bob Perlman
Guest

Mon Feb 20, 2006 9:09 pm   



On Mon, 20 Feb 2006 11:32:38 -0800, Marko <cantsay_at_comcast.net> wrote:

Quote:
On Mon, 20 Feb 2006 19:47:16 +0100, Falk Brunner <Falk.Brunner_at_gmx.de
wrote:

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

Why not?

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

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


Guest

Mon Feb 20, 2006 10:39 pm   



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

Falk Brunner
Guest

Tue Feb 21, 2006 12:12 pm   



reiner_at_hartenstein.de schrieb:
Quote:
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.

Quote:
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.

Quote:
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

Stephane
Guest

Tue Feb 21, 2006 1:10 pm   



Wow, I wouldn't use such a word...

stiffware
noun

1. computing.
Software that is difficult or impossible to modify because
it has been customized or there is incomplete documentation, etc.


Well, googlefight can confirm:

http://www.googlefight.com/index.php?lang=en_GB&word1=configware&word2=stiffware

Kolja Sulimma wrote:
Quote:
reiner_at_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


Brannon
Guest

Tue Feb 21, 2006 5:58 pm   



I've heard it referred to as gateware for a long time where I work. I
think that's a fine name.

Bob Perlman
Guest

Tue Feb 21, 2006 7:58 pm   



On Tue, 21 Feb 2006 10:52:42 -0800, Mike Treseler
<mike_treseler_at_comcast.net> wrote:

Quote:
Brannon wrote:
I've heard it referred to as gateware for a long time where I work. I
think that's a fine name.

I fifth the motion.
All in favor of gateware say aye.

-- Mike Treseler

Sounds good to me. Anything that disabuses people of the notion that
FPGA design is the same as or similar to software design meets with my
approval.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Isaac Bosompem
Guest

Tue Feb 21, 2006 8:58 pm   



Mike Treseler wrote:
Quote:
Brannon wrote:
I've heard it referred to as gateware for a long time where I work. I
think that's a fine name.

I fifth the motion.
All in favor of gateware say aye.

-- Mike Treseler

aye,

For me the biggest hurlde of learning to utilize VHDL was programming
my brain to not think of it as a programming language. Then everything
began to fall into place.

-Isaac


Guest

Tue Feb 21, 2006 10:03 pm   



Here, we usually call it "broken". On rare occasions we will call it
"the bitstream" or "the configuration file".

$0.02

Mike Treseler
Guest

Tue Feb 21, 2006 10:57 pm   



Isaac Bosompem wrote:

Quote:
aye,

For me the biggest hurdle of learning to utilize VHDL was programming
my brain to not think of it as a programming language.

Yes. The trickery is that synthesis code describes
a testable simulation model, not hardware.

Hardware which matches this model is inferred
based on the device, Fmax and other constraints.

The "software" aspect to rtl code
just answers the question:

"Oh, another clock, what should we output this time?"

-- Mike Treseler

Mike Treseler
Guest

Tue Feb 21, 2006 11:09 pm   



fpga_toys_at_yahoo.com wrote:

Quote:
Interesting discussion. In a prior discussion regarding "programming"
or "designing" with C syntax HLL or HDLs, it was interesting how many
people took up arms that they could do everything in VHDL or Verilog
that could be done with a C based fpga design language such as
Celoxica's Handel-C, Impulse-C, FpgaC or similar tools. That arguement
was that VHDL/Verilog really isn't any different that C based HLL/HDL's
for FPGA design, and frequently with the assertion that VHDL/Verilog
was better.

Yes. The only advantage to C-based HDLs
is that lots of people already know C.

Quote:
Now, we have the looks like a duck, walks like a duck, quacks like a
duck, must be a duck argument that if in fact VHDL/Verilog is some
equivalent to C based HDL/HLL's, then it's probably has some
significant aspects of software development, rather than gate level
schematic based hardware design.

Yes. Version control, Checkout into an empty directory,
Makefile generation and regression testing is just as effective
on an hdl project as it is on a C++/Java project.

Quote:
So is an fpga design in VHDL/Verilog hardware, and the same realized
equiv gates written in in Celoxica's Handel-C software just because of
the choice of language? Or is a VHDL/Verilog design that is the same
as a Handel-C design software?

They are just different simulation models of the same thing.

-- Mike Treseler

Isaac Bosompem
Guest

Wed Feb 22, 2006 1:50 am   



fpga_toys_at_yahoo.com wrote:
Quote:
Isaac Bosompem wrote:
For me the biggest hurlde of learning to utilize VHDL was programming
my brain to not think of it as a programming language. Then everything
began to fall into place.

Interesting discussion. In a prior discussion regarding "programming"
or "designing" with C syntax HLL or HDLs, it was interesting how many
people took up arms that they could do everything in VHDL or Verilog
that could be done with a C based fpga design language such as
Celoxica's Handel-C, Impulse-C, FpgaC or similar tools. That arguement
was that VHDL/Verilog really isn't any different that C based HLL/HDL's
for FPGA design, and frequently with the assertion that VHDL/Verilog
was better.
Definitely C is linked fairly close to VHDL/Verilog. But there are a

few key differences that I had to consider when learning HDL's to truly
understand what was going on. For example the non-blocking statements
in a clocked sequential processes in VHDL. I orignally assumed that
like software , signal assignments would happen instantly after the
line has executed, but I was wrong. A few minutes playing around with
ModelSim revealed that they occur on the following clock pulse (when
the flip flops sample the data input).

So there was a bit of a retraining process even though the syntax was
somewhat familiar.


Quote:
So is an fpga design in VHDL/Verilog hardware, and the same realized
equiv gates written in in Celoxica's Handel-C software just because of
the choice of language? Or is a VHDL/Verilog design that is the same
as a Handel-C design software?

This is a fairly tough question as we wouldn't be discussing this if
this was something that we could all agree on. I believe that both are
hardware and I will explain my reasoning:

FpgaC for example is a totally different ball game from VHDL/Verilog
but they ultimately result in a piece of hardware at the output.

FpgaC (from the example posted at the TMCC's website at U of Toronto,
where I happen to live Smile ) hides completely the hardware elements from
the designer. Allowing them to give a software-like *DESCRIPTION* (key
word) of the hardware. What you get is ultimately hardware that
implements your "program".

VHDL/Verilog on the other hand do hide most of the grunt work of doing
digital design but still you have somethings left over like what I
pointed out above about the non blocking signal assignments.

We have always progressed towards abstraction in the software
world,similar pushes have also been made in the hardware world with
EDA's and CAD software packages like MATLAB, which automate most of the
grunt work. Perhaps program like HDL's are the new progression.

All I can say though, is only time will tell. It depends on how well
compilers like FpgaC will be able to convert a program to hardware
description. Also how well it be able to extract and fine opportunities
for concurrency.


-Isaac

JJ
Guest

Wed Feb 22, 2006 9:51 am   



fpga_toys_at_yahoo.com wrote:
Quote:
Isaac Bosompem wrote:
For me the biggest hurlde of learning to utilize VHDL was programming
my brain to not think of it as a programming language. Then everything
began to fall into place.

Interesting discussion. In a prior discussion regarding "programming"
or "designing" with C syntax HLL or HDLs, it was interesting how many
people took up arms that they could do everything in VHDL or Verilog
that could be done with a C based fpga design language such as
Celoxica's Handel-C, Impulse-C, FpgaC or similar tools. That arguement
was that VHDL/Verilog really isn't any different that C based HLL/HDL's
for FPGA design, and frequently with the assertion that VHDL/Verilog
was better.


snipping

Quote:

So is an fpga design in VHDL/Verilog hardware, and the same realized
equiv gates written in in Celoxica's Handel-C software just because of
the choice of language? Or is a VHDL/Verilog design that is the same
as a Handel-C design software?

It reaslly depends on the style of design and synthesis level.
Traditionally Synopsys style DC synthesis performed on RTL code is
hardware design more or less no matter how the RTL is prepared, even
javascript if thats possible. But HandelC and the other new entrants
from my knowledge are usually based on behavioural synthesis, thats the
whole point for their existance is to raise productivity by letting
these tools figure how to construct the RTL dataflow code so that mere
mortal software engineers don't have to be familiar with RTL design.
They still find out about real harware issue sooner or later though.

On the ASIC side, Synopsys BC didn't fare too well with hardcore ASIC
guys, better with system guys. Since FPGAs let software, system guys
into the party, BC style synthesis is going to be far more acceptable
and widespread, cost of failure so much lower than with ASICs. As for
is it HW or SW, I decline, but the ASIC guys would tend to call BC
design too software like given early results, I don't think their
opinion for C style behavioural design has changed any either.

If the end result of BC style design produces results as good as
typically achieved by DC synthesis then it is everybit as good as
hardware but does it produce such results? In hardcore hardware land we
expect to drive upwards of 300MHz cycle rates and plan a hardware
design onto a floorplan but I wouldn't expect such performance or
efficiency from these BC tools. Do they routinely produce as good
results, I very much doubt? Replacing RTL for behavioural design may
raise productivity but it is not the same thing as replacing assembler
coding for HLL coding IMHO given the current nature of OoO cpus.

Goto page 1, 2, 3, 4  Next

elektroda.net NewsGroups Forum Index - FPGA - Is FPGA code called firmware?

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map