Is FPGA code called firmware?

re> FPGA code I call configware code - the output of configware compilation

At Pixel Velocity, we call it 'gateware'.

--
Joe Samson
Pixel Velocity

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

same at Starbridge Sys.

I've called it "gateware" for the last 15 years.

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

Yea verily. I do a lot of embedded software development, and a bit of FPGA design. While Verilog may bear a passing resemblance to C the thought processes that go into FPGA design vs. software design are considerably different.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

I think I'll start using that -- at least where I think it has a chance to stick.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

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

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

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?

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.

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

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.

They are just different simulation models of the same thing.

-- Mike Treseler

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.

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

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.