Is FPGA code called firmware?

[Rick C]

On Friday, January 31, 2020 at 10:53:52 AM UTC-5, David Wade wrote:

On 30/01/2020 19:34, gtwrek wrote:
In article <r0u7pd$i5k$1@dont-email.me>,
David Wade <g4ugm@dave.invalid> wrote:
Interesting question. You write a hardware description language so what
you produce must be the "Hardware description"...

I personally am quite happy to call the HDL source code an "Program" or
an "hdl program".

A "program" really is just a list of instructions. Just as "g-code" is a
programming language used to control a 3-d printer or milling. machine,
VHDL is a programming language that is used to "program" a "logic
synthesisers" which generates the bitstream.

Not trying to dig or start a flame here... But when I hear someone
describe Verilog or VHDL as a "program", I'm almost certain to
(prejudge) that such individual is a newbie, or inexperienced at FPGA
design. Thinking of traditional "programs" or "list of instructions" when
designing an FPGA is certainly the wrong mindset.

FPGA vendors would love to think that there new wonderful C like "High
level languages" are just super programs that make things run fast on an
FPGA. But they're nothing of the sort. One "designs" with an HDL akin
to how one designs with a schematic.


correct.

While I tend to think in terms of the logic involved and write my HDL to describe the logic I have in mind, not everyone works that way (many call this RTL coding).

Once I was interviewing for a job and when asked I described this method of designing. The lead engineer of a Japanese team disagreed saying they didn't have time to optimize the code so they wrote to describe the behavior instead (many call this behavioral coding). I was trying to point out that the two do not need to be in conflict, that an RTL coding style can be used to describe behavior with little or no additional effort. The lead engineer disagreed and we discussed it a little. When I was in touch with the recruiter he asked me about the "confrontation"! I didn't realize there was a confrontation. lol Obviously there was not a good match of cultures.

Comparing to instruction based CPU's just doesn't fit, which is (in my
mind) what "programs" traditionally do.


Thats what typical modern programs do. But that is a very narrow use of
the word "program" Those of us who are old enough to have programmed
an analog computer may recall that we did so by physically wiring analog
adders, integrators, comparators and other components together.

In fact using a very similar process to that we use to configure an FPGA.

Going back to Eniac that was also "programmed" with wires and plug boards..

so whilst many folks assume a "program" is restricted to digitl
languages, historially it was applied to other processes..

Yes, I wish there were better terms to describe programs written to run on sequential processors to distinguish them from programs written to describe hardware. The emphasis these days is to try to merge the two so the entire application can be written in one language and different layers can be implemented in either domain as best suits the particulars of the system being designed.

Just some thoughts...

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

 

[Zach Metzinger]

On 02/01/20 11:25, Rick C wrote:

While I tend to think in terms of the logic involved and write my HDL
to describe the logic I have in mind, not everyone works that way
(many call this RTL coding).

I have a computer engineering degree, but I've spent most of my
professional career writing software for embedded CPUs (with a bit of
hardware designed on the side). So, I'm probably tainted in this respect.

I agree with your statement, Rick. A grumpy old FGPA engineer once told
me that anyone who says they're "writing a program for an FPGA" doesn't
know what they're doing. He says they typically end up with a design
which is not synthesizable. He and I agree on this point.

You're describing how you're hooking up logic within the FPGA, virtually
connecting the wires between logic gates. HDLs let you cheat a bit and
say what you want to do, then they try to figure out what you meant.
This elaboration process can be perilous, if one does not know the
proper incantations. The older HDLs, such as PALASM and CUPL were so
close to wiring gates together that it was painful, but they didn't
infer much, if anything, about what you meant.

So, here's my nomenclature:

"Software" -> Stored program code, typically stored in offline memory
and then loaded into RAM to run on a CPU. Also a generic term, even if
applied to embedded systems.

"Firmware" -> Stored program code, residing in Flash/EPROM/EEPROM/etc.
and ready for instant fetch/execute by a CPU.

"Program" -> Noun: Source code for Firmware or Software, Verb: The
physical act of putting bits into some storage, usually Flash/EPROM/...

"RTL" or "Design" -> The embodiment of a Boolean logic design, typically
in the form of a Hardware Design Language such as Verilog, VHDL, etc.

"Bitstream" or "Configuration" -> When the RTL/Design is fed into a
design tool that compiles/elaborates/synthesizes the former, along with
a description of the target hardware, into a series of bits or bytes in
a file. This file, when loaded into the FPGA, configures the
gates/LUTs/other-logic-elements into the hardware design described by
the RTL/Design.

Anyway, if one stays away from the terms "Software" or "Firmware" for
hardware design and remembers that FPGAs are just a sea of look-up
tables and logic, one won't fall into the trap of thinking that stuff at
the top of the HDL source file executes before the stuff at the bottom.

--- Zach

 

[Rick C]

On Sunday, February 2, 2020 at 8:09:09 PM UTC-5, Zach Metzinger wrote:

On 02/01/20 11:25, Rick C wrote:
While I tend to think in terms of the logic involved and write my HDL
to describe the logic I have in mind, not everyone works that way
(many call this RTL coding).

I have a computer engineering degree, but I've spent most of my
professional career writing software for embedded CPUs (with a bit of
hardware designed on the side). So, I'm probably tainted in this respect.

I started with electronic hardware when I was a young teenager with a hand wired kit/toy with bells, lights, switches and batteries. I call it "electronic" because I learned to gang SPST switches together to make DPDT switches, my first logic exercise. lol From then on it was all a direct path.

So I'm probably "tainted" too.


> I agree with your statement, Rick.

That's always a great way to start a discussion even if you disagree. A friend makes a point of telling me every time I see him, "You are not only right, you are absolutely correct". Lol... so far it hasn't completely taken, I tend to be a bit argumentative online.

A grumpy old FGPA engineer once told
me that anyone who says they're "writing a program for an FPGA" doesn't
know what they're doing. He says they typically end up with a design
which is not synthesizable. He and I agree on this point.

Your friend was not only right, but absolutely correct... except for the part about then not knowing what they are doing. I call it a program, but usually add "code" as in "I'm working on the program code now". While processor code is written differently most of the time, they are both still actually not totally different. Just don't confuse a process sensitivity list for a subroutine parameter list.

You're describing how you're hooking up logic within the FPGA, virtually
connecting the wires between logic gates.

That would be true of instantiated logic which I typically use at the module level, but not true of the logic defined in the modules. Inside the modules the logic is simply described in the assignment expressions. It is entirely up to the synthesis tool to synthesize the logic and it's up to the back end tools to place and route. My code has nothing/little to do with the P&R unless I add very detailed instructions which are vendor unique and very laborious.

HDLs let you cheat a bit and
say what you want to do, then they try to figure out what you meant.

Not so much "try to figure out" since logic is a well defined part of the language. The synthesis tool tries to provide an optimal solution. In one, not unusual case I recall getting poor results because my code was not describing what I was seeing in my head like I thought it was. So instead of getting an optimized structure, I was duplicating the adder chain to get the carry out. My coding style learned from that. Now I code the logic of such adders/counters outside the process so there will only ever be one adder/carry chain and use the results of that adder in the process. I suppose if I were more organized, I could make the adder logic a library function resulting in a single, simple, consistent line of code where used.

This elaboration process can be perilous, if one does not know the
proper incantations. The older HDLs, such as PALASM and CUPL were so
close to wiring gates together that it was painful, but they didn't
infer much, if anything, about what you meant.

Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're more like assemblers for logic than high level languages.

So, here's my nomenclature:

"Software" -> Stored program code, typically stored in offline memory
and then loaded into RAM to run on a CPU. Also a generic term, even if
applied to embedded systems.

"Firmware" -> Stored program code, residing in Flash/EPROM/EEPROM/etc.
and ready for instant fetch/execute by a CPU.

You are not only right, but absolutely correct! So what exactly is the difference between reading a program from a flash drive into ram for execution and loading a program from a flash chip into ram for execution? Does a Raspberry Pi built into a box to control lighting in a house load software from it's SD card or load firmware? If the same job is being done by a TI MSP430 does it load software or firmware from the internal Flash on the chip? What if either of these devices are connected to a rotating disk for program storage?

Or are you saying firmware has to be in Flash that can be directly addressed and executed by the CPU?

This is what I mean by there not being much value in even distinguishing the terms. To me it's more of a "who cares" about using one term or the other since the boundary is so subjective and not of much value. What does calling it software imply that firmware doesn't or vice versa?

"Program" -> Noun: Source code for Firmware or Software, Verb: The
physical act of putting bits into some storage, usually Flash/EPROM/...

"RTL" or "Design" -> The embodiment of a Boolean logic design, typically
in the form of a Hardware Design Language such as Verilog, VHDL, etc.

What does it mean to you to say "Boolean logic" exactly? Don't most computer programs utilize Boolean logic in one way or the other, the same as HDL.

A <= B + C;

Is this RTL or software or what exactly? Is this different?

A = B + C;

"Bitstream" or "Configuration" -> When the RTL/Design is fed into a
design tool that compiles/elaborates/synthesizes the former, along with
a description of the target hardware, into a series of bits or bytes in
a file. This file, when loaded into the FPGA, configures the
gates/LUTs/other-logic-elements into the hardware design described by
the RTL/Design.

Anyway, if one stays away from the terms "Software" or "Firmware" for
hardware design and remembers that FPGAs are just a sea of look-up
tables and logic, one won't fall into the trap of thinking that stuff at
the top of the HDL source file executes before the stuff at the bottom.

That's a very fundamental difference that has to be understood before doing any HDL work. I took a 1 week class in VHDL and they didn't do that. The instructor just followed a book that wasn't really so good and he seemed incapable of making that distinction of everything at the top level (concurrent code) was running in parallel rather than sequential. He also failed to explain that a process was not a subroutine in any way that helped. (Just saying they aren't the same doesn't really help) The biggest issue is that the sensitivity list is not a parameter list. Then there is the fact that outside a process the code is parallel, inside the code is sequential. Nope, no real explanation of that. The guy had no business teaching the stuff.

Anyway, I find it interesting to discuss experiences. I haven't done any coding in a while.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

 

[Zach Metzinger]

On 2020-02-02 23:32, Rick C wrote:

Your friend was not only right, but absolutely correct... except for
the part about then not knowing what they are doing. I call it a
program, but usually add "code" as in "I'm working on the program
code now". While processor code is written differently most of the
time, they are both still actually not totally different. Just don't
confuse a process sensitivity list for a subroutine parameter list.

:-D

Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're
more like assemblers for logic than high level languages.

They're definitely more limited, to be sure. But CUPL does have syntax
for truth tables, state machines, etc.

Or are you saying firmware has to be in Flash that can be directly
addressed and executed by the CPU?

Yes, this is what I'd consider the turning point for "firmware".
Something that is instantly available for execution, without being first
loaded by some other mechanism (ROM, 1st/2nd stage bootstrap, etc.)

"RTL" or "Design" -> The embodiment of a Boolean logic design,
typically in the form of a Hardware Design Language such as
Verilog, VHDL, etc.

What does it mean to you to say "Boolean logic" exactly? Don't most
computer programs utilize Boolean logic in one way or the other, the
same as HDL.

You are correct. Perhaps the best thing is to delete "Boolean logic" out
of that sentence and replace it with "hardware".

A <= B + C;

Is this RTL or software or what exactly? Is this different?

A = B + C;

Well, one is a nonblocking assignment and one is a blocking assignment,
but that's a bit off our topic.

> I took a 1 week class in VHDL and they didn't do that.

I know very little VHDL, other than my impression that it is more akin
to the rigidness of Ada or Pascal, whereas Verilog is closer to
anything-goes C.

--- Zach

 

[Rick C]

On Tuesday, February 4, 2020 at 12:39:38 PM UTC-5, Zach Metzinger wrote:

On 2020-02-02 23:32, Rick C wrote:
Your friend was not only right, but absolutely correct... except for
the part about then not knowing what they are doing. I call it a
program, but usually add "code" as in "I'm working on the program
code now". While processor code is written differently most of the
time, they are both still actually not totally different. Just don't
confuse a process sensitivity list for a subroutine parameter list.

:-D

Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're
more like assemblers for logic than high level languages.

They're definitely more limited, to be sure. But CUPL does have syntax
for truth tables, state machines, etc.

Yes, nothing more than just direct logic of one output at a time is allowed.. There isn't much in the way of optimization. No conditional constructs (the sort of stuff that makes sense to humans and not just totally geek engineers like me). No complexity of assignments. If you want an output to be tristate, you don't assign a tristate value to the output, you manipulate the tristate control of the output. No targets other than simple devices.

Although I shouldn't say this about CUPL as I have not used it.

Or are you saying firmware has to be in Flash that can be directly
addressed and executed by the CPU?

Yes, this is what I'd consider the turning point for "firmware".
Something that is instantly available for execution, without being first
loaded by some other mechanism (ROM, 1st/2nd stage bootstrap, etc.)

Ok, so at least you have your clear definition of "embedded". Others include devices on external properties like the form factor or application. I guess my point is everyone having their own definition of the term makes it hard to have discussions with this language.

"RTL" or "Design" -> The embodiment of a Boolean logic design,
typically in the form of a Hardware Design Language such as
Verilog, VHDL, etc.

What does it mean to you to say "Boolean logic" exactly? Don't most
computer programs utilize Boolean logic in one way or the other, the
same as HDL.

You are correct. Perhaps the best thing is to delete "Boolean logic" out
of that sentence and replace it with "hardware".

Ok, but my point is that includes virtually every type of HDL program... er, design. Conventionally RTL is a coding style that directly specifies registers and the logic between them rather than a functional description that is more abstract in a way that allows the registers to be less obvious.

A <= B + C;

Is this RTL or software or what exactly? Is this different?

A = B + C;

Well, one is a nonblocking assignment and one is a blocking assignment,
but that's a bit off our topic.

That isn't want I intended to be saying. The latter is how you write an assignment in C. I guess my point is that both types of language have similar functionality in many ways... more similarities than differences.

I took a 1 week class in VHDL and they didn't do that.

I know very little VHDL, other than my impression that it is more akin
to the rigidness of Ada or Pascal, whereas Verilog is closer to
anything-goes C.

Yes, they have relaxed some of the stricter issues such as allowing "IF signal_a THEN" rather than requiring "IF signal_a = '1' THEN". But type checking is still pretty stiff. At one time a string constant (the way you specify a vector) had to be type cast as the logic type you wanted because it can be more than one type. They did something to relax that a couple of revisions ago. Still, strong typing can trip up a newbie. You quickly get used to it. Just think what you intend and if what you write can be interpreted more than one way. VHDL will not assume. That's the basis of its rigor. No assumptions. Verilog has many default assumptions which you have to know about to not get it wrong by not specifying that you want something different. It's easy to make a mistake doing math that is hard to find.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

 

On Monday, February 20, 2006 at 7:18:59 PM UTC+1, 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?

I usually use the phrase "FPGA config" but if it needs to end with "ware" I use "gateware" ;-)

 

> I usually use the phrase "FPGA config" but if it needs to end with "ware" I use "gateware" ;-)

I do FPGA design since 20+ years (MAX+PLUS II anyone?), but I came across the term "gateware" for the first time a few days ago in a job interview. So it is quite funny to find it again in this discussion here. But I think it is not really widely used...

BTW: Did anyone realize that this thread started in 2006?

To come back to the topic: In my company we just refer to it as "the FPGA design" which is a part of the firmware update file of a product. But I would not call a FPGA design (or configuration file) alone firmware.