On Monday, February 20, 2006 at 10:18:59 AM UTC-8, 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 have seen gateware is used to differentiate HDL derived implementations f=
rom firmware.=20

The landscape has changed over time quite a bit.  Nowadays we have a soft c=
ore processor running software.=20

At its core, all data processing systems (discrete systems) are doing two t=
hings;  implementation of an algorithm, and running a state machine.
When implemented in gateware, an algorithm is implemented as a combinatoria=
l circuit, and the state machine is implemented as a sequential circuit.

It is possible to design a complete data processing system as a single disc=
rete system with different frequencies attached to each seq circuit and del=
ays to the algorithms, analyze for throughput, and change the software/gate=
ware boundary at the time of implementation.

Narada

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

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

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

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).
>=20
> I have a computer engineering degree, but I've spent most of my=20
> professional career writing software for embedded CPUs (with a bit of=20
> 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 "elect=
ronic" because I learned to gang SPST switches together to make DPDT switch=
es, my first logic exercise.  lol  From then on it was all a direct path.=
=20

So I'm probably "tainted" too. =20


> I agree with your statement, Rick.=20

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


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

Your friend was not only right, but absolutely correct... except for the pa=
rt about then not knowing what they are doing.  I call it a program, but us=
ually add "code" as in "I'm working on the program code now".  While proces=
sor code is written differently most of the time, they are both still actua=
lly not totally different.  Just don't confuse a process sensitivity list f=
or a subroutine parameter list. =20


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

That would be true of instantiated logic which I typically use at the modul=
e level, but not true of the logic defined in the modules.  Inside the modu=
les the logic is simply described in the assignment expressions.  It is ent=
irely up to the synthesis tool to synthesize the logic and it's up to the b=
ack end tools to place and route.  My code has nothing/little to do with th=
e P&R unless I add very detailed instructions which are vendor unique and v=
ery laborious.=20


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

Not so much "try to figure out" since logic is a well defined part of the l=
anguage.  The synthesis tool tries to provide an optimal solution.  In one,=
 not unusual case I recall getting poor results because my code was not des=
cribing 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 th=
e carry out.  My coding style learned from that.  Now I code the logic of s=
uch adders/counters outside the process so there will only ever be one adde=
r/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 r=
esulting in a single, simple, consistent line of code where used.=20


> This elaboration process can be perilous, if one does not know the=20
> proper incantations. The older HDLs, such as PALASM and CUPL were so=20
> close to wiring gates together that it was painful, but they didn't=20
> 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 l=
ike assemblers for logic than high level languages.=20


> So, here's my nomenclature:
>=20
> "Software" -> Stored program code, typically stored in offline memory=20
> and then loaded into RAM to run on a CPU. Also a generic term, even if=20
> applied to embedded systems.
>=20
> "Firmware" -> Stored program code, residing in Flash/EPROM/EEPROM/etc.=20
> and ready for instant fetch/execute by a CPU.

You are not only right, but absolutely correct!  So what exactly is the dif=
ference 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 Ra=
spberry Pi built into a box to control lighting in a house load software fr=
om it's SD card or load firmware?  If the same job is being done by a TI MS=
P430 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 prog=
ram storage?=20

Or are you saying firmware has to be in Flash that can be directly addresse=
d and executed by the CPU?=20

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


> "Program" -> Noun: Source code for Firmware or Software, Verb: The=20
> physical act of putting bits into some storage, usually Flash/EPROM/...
>=20
> "RTL" or "Design" -> The embodiment of a Boolean logic design, typically=
=20
> 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 comput=
er programs utilize Boolean logic in one way or the other, the same as HDL.=
 =20

A <=3D B + C;=20

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

A =3D B + C;


> "Bitstream" or "Configuration" -> When the RTL/Design is fed into a=20
> design tool that compiles/elaborates/synthesizes the former, along with=
=20
> a description of the target hardware, into a series of bits or bytes in=
=20
> a file. This file, when loaded into the FPGA, configures the=20
> gates/LUTs/other-logic-elements into the hardware design described by=20
> the RTL/Design.
>=20
> Anyway, if one stays away from the terms "Software" or "Firmware" for=20
> hardware design and remembers that FPGAs are just a sea of look-up=20
> tables and logic, one won't fall into the trap of thinking that stuff at=
=20
> 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 i=
ncapable of making that distinction of everything at the top level (concurr=
ent code) was running in parallel rather than sequential.  He also failed t=
o explain that a process was not a subroutine in any way that helped.  (Jus=
t saying they aren't the same doesn't really help)  The biggest issue is th=
at the sensitivity list is not a parameter list.  Then there is the fact th=
at 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 st=
uff.=20

Anyway, I find it interesting to discuss experiences.  I haven't done any c=
oding in a while. =20

--=20

  Rick C.

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

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

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

On 31/01/2020 17:53, gtwrek wrote:
> In article <r11iid$ofc$1@dont-email.me>,
> David Wade  <g4ugm@dave.invalid> wrote:
>> 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..
> 
> It's no longer the canonical definition in my opinion.   When I hear a
> question on some FPGA group asking about some details on "my verilog
> program" it's inevitably a newbie with a software background.
> 

So what do experienced folks say? Simply "My VHDL" or "my verilog" I guess?

Perhaps the issue is with the training materials. Most of the VHDL 
tutorials I can find refer to VHDL programming and I don't see how you 
can have programming without a program.

I must admit I it took me a while to get my head round the 
non-sequential behaviour of VHDL and wondered how the tools that claim 
to let you program FPGAs in "C" work in practice.

> While I've never touch an Eniac - nor seen one outside a musuem - I've debugged a few
> wire-wrapped systems in my career early days.  Don't care to go back to that...
> 

Well most Tuesday I get to demonstrate the replica Manchester Baby/SSEM, 
a valve/tube computer but thats really just like a modern machine to the 
programmer. Inside it has some tweaks to cut down on valves/tubes.

But I also own an EAI TR-10 analoge computer which is definitely 
programmed with wires... (This one isn't mine)

http://www.analogmuseum.org/english/collection/eai/tr10/

> Regards,
> Mark

Dave
>   
> 

Dave

In article <r11iid$ofc$1@dont-email.me>,
David Wade  <g4ugm@dave.invalid> wrote:
>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..

It's no longer the canonical definition in my opinion.   When I hear a
question on some FPGA group asking about some details on "my verilog
program" it's inevitably a newbie with a software background.

While I've never touch an Eniac - nor seen one outside a musuem - I've debugged a few
wire-wrapped systems in my career early days.  Don't care to go back to that...

Regards,
Mark