Is FPGA code called firmware?

Except there really aren't any useable gates in the FPGA, LUTs only
model them and other functions that might be built of gates in an ASIC.
We hardly think in terms of gates do we, usually equations, registers
and memory blocks otherwise we would still be using schematics.

I'd would offer bitware since we also use bitfiles, maybe boolware,
lutware, flexware, mixware, dunnoware, undewear:-).

Some other thoughts

Now to those who rail that xxxxware isn't software just because Verilog
also uses some C style syntax. What happens if say SystemVerilog is
used to describe a system with both hardware & software components,
half (mostly the parallel part) being synthesized and the rest being
executed by a cpu in the FPGA. Suppose that cpu is in control of
dynamic reconfiguration and allows hardware blocks to be loaded at
will. Right now we have no language to support this (do we?). What
about the far future when the onboard processor(s) might even run the
synthesis locally on demand. Maybe too much coolaid.

One should also note the industry shift by Intel, AMD, IBM to 2, 4 and
n way cores and multithreaded cpus. Eventually the software industry
will look over our shoulders and see that hardware guys have had
parallel figured out for 50+ years and don't fall over themselves with
it. They might even notice that SystemVerilog includes a good chunk of
C and that Verilog seems to describe concurrency pretty well too. For
the most part software guys even OS and language experts (not embedded)
have zero clue about our side of the language fence v the 1000s of
languages they reinvent all the time.

A lite version of Verilog combined with a subset of C++ that describes
processes as objects as well as Verilog describes modules using C
syntax all the way might be an attractive alternative to the rather
biggish SystemVerilog. It might allow all execution as code with a
provided runtime event wheel or might be synthesized to hardware or any
mix of the two, at least its one language. Not sure when that might
arrive but it would be alot better than most of these parallel C
dialects that haven't been thought out to well like Jave, C# which
completeley ignored CSP theory.



John Jakson
transputer guy

Except there really aren't any useable gates in the FPGA, LUTs only
model them and other functions that might be built of gates in an ASIC.
We hardly think in terms of gates do we, usually equations, registers
and memory blocks otherwise we would still be using schematics.

I'd would offer bitware since we also use bitfiles, maybe boolware,
lutware, flexware, mixware, dunnoware, undewear:-).

Some other thoughts

Now to those who rail that xxxxware isn't software just because Verilog
also uses some C style syntax. What happens if say SystemVerilog is
used to describe a system with both hardware & software components,
half (mostly the parallel part) being synthesized and the rest being
executed by a cpu in the FPGA. Suppose that cpu is in control of
dynamic reconfiguration and allows hardware blocks to be loaded at
will. Right now we have no language to support this (do we?). What
about the far future when the onboard processor(s) might even run the
synthesis locally on demand. Maybe too much coolaid.

One should also note the industry shift by Intel, AMD, IBM to 2, 4 and
n way cores and multithreaded cpus. Eventually the software industry
will look over our shoulders and see that hardware guys have had
parallel figured out for 50+ years and don't fall over themselves with
it. They might even notice that SystemVerilog includes a good chunk of
C and that Verilog seems to describe concurrency pretty well too. For
the most part software guys even OS and language experts (not embedded)
have zero clue about our side of the language fence v the 1000s of
languages they reinvent all the time.

A lite version of Verilog combined with a subset of C++ that describes
processes as objects as well as Verilog describes modules using C
syntax all the way might be an attractive alternative to the rather
biggish SystemVerilog. It might allow all execution as code with a
provided runtime event wheel or might be synthesized to hardware or any
mix of the two, at least its one language. Not sure when that might
arrive but it would be alot better than most of these parallel C
dialects that haven't been thought out to well like Jave, C# which
completeley ignored CSP theory.



John Jakson
transputer guy

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

$0.02

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.

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.

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?

Isaac Bosompem wrote:

> 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

Just to throw in my 2 cents on the semantics of FPGA configuration
code/bitstream/whatever...

In the software realm, software vs. firmware is generally the
difference
between something easily changed (i.e. stored on your hard
disk) vs. something not as easily changed (i.e. stored in a ROM).

There is a bit of grey area here, like the BIOS in your PC which is
in a flash memory in most modern systems and can be upgraded
by running a program you download from the Internet.  I would still
call it firmware, though.

At our company we call FPGA configuration code "software" if it
is stored on the hard drive and uploaded at run time by a user
application.  When it is stored in a serial PROM or flash memory
on the board we call it firmware.

I don't think the terms "firmware" or "software" have as much to do
with the programming paradigm as with the delivery of the bits to
make the actual hardware run.

Interesting thread...
Gabor

fpga_toys@yahoo.com wrote:
> 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.
>
> 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.
>
> 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?

fpga_toys@yahoo.com wrote:

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

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

> 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

Gabor wrote:
> At our company we call FPGA configuration code "software" if it
> is stored on the hard drive and uploaded at run time by a user
> application.  When it is stored in a serial PROM or flash memory
> on the board we call it firmware."

Interesting.  So the devices which have flash/eeprom based "solid state
disks" (SSD) such as your typical hand held IPOD, Windows CE based
PDA's, are not "software" based systems?

heck even phones these days are becoming PDA's and MP3 players with
very large SSD's in flash. Even most new "platform flash" FPGA's load
off the same SSD's in the form of compact flash cards.

So if SSD's are the factor for software vs. hardware, then it seems
that any FPGA that loads and runs off SSD related storage technology,
is probably software by the looks like a duck, quacks like a duck, must
be a duck test. No? Why not?

Why is an FSM and data paths controlled by it when written in a C based
HDL/HLL software, and the same FSM and data paths written in
VHDL/Verilog hardware?

It wasn't that many years ago I wrote software/firmware/microcode for
bit sliced "processors" implementing 'smart' high speed data
controllers, but we called it hardware. Now I write
software/firmware/microcode AND instantiate it as hard LUT/FFs in
FPGA's and it just doesn't seem like hardware any more ... when the
same "code" can be moved to a $0.99 microprocessor with a PLD wrapped
around it as a cost reduction.

Gabor wrote:

> Just to throw in my 2 cents on the semantics of FPGA configuration
> code/bitstream/whatever...
> 
> In the software realm, software vs. firmware is generally the
> difference
> between something easily changed (i.e. stored on your hard
> disk) vs. something not as easily changed (i.e. stored in a ROM).
> 
> There is a bit of grey area here, like the BIOS in your PC which is
> in a flash memory in most modern systems and can be upgraded
> by running a program you download from the Internet.  I would still
> call it firmware, though.
> 
> At our company we call FPGA configuration code "software" if it
> is stored on the hard drive and uploaded at run time by a user
> application.  When it is stored in a serial PROM or flash memory
> on the board we call it firmware.
> 
> I don't think the terms "firmware" or "software" have as much to do
> with the programming paradigm as with the delivery of the bits to
> make the actual hardware run.
> 
> Interesting thread...

  There is another thread, where this actually matters from a medical 
systems /regulatory basis.

  Since you must have SOFTWARE to create the bitstream, then the
admin has to include software-handling discipline.

  Many FPGA systems now include SoftCPUs, and that puts some portion
of the design clearly into the software box.

  -jg

Jim Granville wrote:
>   Many FPGA systems now include SoftCPUs, and that puts some portion
> of the design clearly into the software box.

In a prior thread about HDL's the VHDL camp was VERY VERY proud to
state they didn't need sequential programming languages like C based
HDL/HLL's, since VHDL already had nearly functionally idential
sequential statements and expressions, including extended data types
like floating point.

*IF* software is defined as sequential programming in a high level (or
any level) language, then sequential VHDL (and verilog) clearly passes
the walks like a duck, quacks like a duck, looks like a duck test for
being software.

I'm sure any lawyer would have little trouble showing C source and VHDL
source for sequential floating point data manipulation as functionally
identical, and a jury probably would completely ignore any hardware
designer claiming that it was hardware because his degree was in
electrical engineering and not computer science. Ditto for control and
data paths with integer data representations. Ditto for control and
data paths with bit level representations.  Bit level "var1 AND var2"
is the same if written var1*var2 or var1&var2, syntax doesn't matter.

There is a lot of chest beating about being a hardware designer, and
having been formally trained in the lost art of schematic logic level
design.  Every year, as hardware design is dominated by large HDL
systems designs, using algorithmic based FSMs and data paths in
languages which are functionally identical to HLL programming
languages, the difference and importanance of obsolete logic level
design training vanishes. If anything, programmers which have been
trained to design, implement, and manage the life cycles of huge zero
defect software projects are much better prepared to manage large
HDL/HLL hardware development projects as automated synthesis completely
replaces gate level design as an acceptable design practice.

Language features which impair the ability of synthesis tools to always
generate formally verifiable and provably correct constructions will
slowly fall by the way side,
and with it the ability to use arcane language hints to save a single
gate in a few hundred instances of a large 20M gate design. Saving a
few hundred (or thousand) gates in a $100 20M gate device if it risks
design errors that would cause a field problem or development delay are
a liability, not a necessary feature.  HLL/HDL language features which
are simply there to ensure job security for a certain class of
programmers, will fade away, in favor of expanding the labor pool and
the ability to reused engineering talent in multiple disciplines.

Even in the software world, there are MANY zero defect design
environments ... from space craft mission systems to financial
banking/transactions systems where bugs are simply not an option and
rigorous testing is done before taking any line of code production. And
there are many hardware designs shipped just as buggy as your favorite
Microsoft product, where 99.9% functionality with a one year
operational life is good enough to ship, especially if there is a watch
dog reset to clear latchups caused by known race conditions or
power/ground rail instabilities at marginal operating conditions.