Welcome Notice

Register Log in

Is FPGA code called firmware?

J

JJ

Guest
fpga_toys@yahoo.com wrote:

snipping, kind of tired of being told software taking over hardware
design, it ain't

The Google description for this group is: Field Programmable Gate Array
based computing systems, under Computer Architecture FPGA. And, after
a few years, I think we are finally getting there .... FPGA based
coputing instead of CPU based computing.

The days of FPGA's being only for hardware design are slipping away.
While this group has been dominated by hardware designers using FPGA's
for hardware designs, I suspect that we will see more and more
engineers of all kinds here doing computing on FPGA's, at all levels.
While thats likely somewhat true and I really welcome anyone with
interesting content problems, I suspect it's already too late for new
comers without strong EE backgrounds or associates.

15 years ago FPGAs were pretty darn simple and not much use for
anything but glue logic. Good ole days when any old CMOS logic slapped
together just worked. Synthesis just around the corner.

10 years ago they got big enough but not performance enough to start to
make predictions about RC and the possibly of replacement of general
purpose cpus with hardware computing ie the 4000 days and a couple of
new companies to boot. ASIC design started to get harder.

5 years ago with Virtex I'd say they started to get the ASIC
performance with the embedded blocks and specialized IO resources
making performance almost even to cover the much slower LUT blocks, and
we also got the hugely more complex data sheets.

Today most FPGAs seem to have the whole kitchen sink in there to make
complex systems more practical if the sink can be made small enough to
hide cost when not used.

Look at any data sheet for modern parts, maybe 5% or less could be
understood by your avg SW engineer (far less I bet), the rest is all
electrical stuff, signal integrity, power supplies, packaging,
reliabilty, clocking in no particular order.

Ask around here for books on FPGA computing, there aren't any, there
all old shit 10yrs or more from the easy days. I have one that covers
the 3000 series. Ray has one coming and it sure ain't targeted at
software guys, he's too busy with real work, as are most EEs with a job
to write up their current knowledge. FPGAs are simply moving too fast
to be documented for the laissez faire user.

SW engineers with the mathematical applications are used to dealing
with ready made PC boxen, give enough ventilation and hot math
shouldn't faze a P4. There really isn't anything available in the same
sense of off the shelf FPGA computing that can be sold as a std board
to all the math, idea guys with out HW pain. Yeh there are lots of FPGA
PCI cards but they are mostly not useable to software guys without some
EE around as well as hardware lab tools. So that means a special
application likely needs special boards to be built. Welcome to the
real world, power supplies, interfaces, SI, GHz IO's, lead free. They
haven't tought that in school in CS ever, and perhaps maybe some EE
schools too. I can feel pretty sure that EEs that don't know this won't
get much work. I suspect logic classes are going to be with us too for
ever.

When I interviewed candidates that don't know basic bool algebra but
would like to do mil gate designs, I'd say let you know later, or let
them know what they need to know. Is that job protection, sure it is,
EEs don't want Joe90 liability around, bad ASIC design kills companies.
We are going the same place with FPGA systems, bad designs will never
work but only the project is lost, not million $ mask sets. My last
employer's FPGA project cost far more than previous predecessor full
custom mixed signal ASIC, it had lots of nice new math in it to figure
out. Even really good EEs make logic mistakes, so some further
abstractions are likely but that doesn't help much with all the dirty
backend EE stuff.

From time to time we have had a few math, bio guys come here with
questions about their interesting problems, but what I noticed is that
they seem to be pretty coy about what they are upto. I suspect the days
of SW engineers coming to the FPGA party are already over. FPGAs are
getting bigger and more interesting but a darn site harder to use and
that won't ever get covered up by synthesis tools.

Also from what I have seen of some of the applications of FPGAs to
computing v PC computing, the FPGA projest didn't even match the PC
solution on cost. Not because the FPAG doesn't have the grunt but
because too much was left on the table since the design was done by
math oriented people. Now as I said before cpu designers have decided
to go the same way FPGA are, packing density plus any incremental clock
speed so its a parallel race again. My gut tells me that PC computing
is still the best way to go if a plain C description works using 32 bit
int math and esp FP math. But when the math looks like crypto with S
boxes and shuffles or has dedicated IO interface, FPGAs cream all over.

Multi disciplined teams are the future but EEs won't be in the back
seat.

I am done

John Jakson
transputer guy
Marlboro MA

BTW I don't know how to change brake pads or do oil changes (or even
spell) so none of the above makes diddly squat.
 
N

Nial Stewart

Guest
<fpga_toys@yahoo.com> wrote in message news:1140727198.395726.97600@u72g2000cwu.googlegroups.com...


and low level hardware design is soon to be long gone for all the
same reasons of labor cost vs. hardware cost.
Where price, performance and power consumption don't matter a higher
level language might become more prevalent.

The power argument is moot, as the difference between power for a good
C coder and a good asm coder, is probably less than a fraction of a
percent.
I was talking about the FPGA domain here, not SW.


I also wonder if price/performance/power consumption will become much
less important in the future, as it has with software. These days
you can assume application software will be run on a 'standard'
sufficiently powerful PC. It won't be the case that at the start of
every hardware project that you can assume you have a multi million
gate FPGA (or whatever) at your disposal.

Today, the price difference between low end FPGA boards and million
gate boards is getting pretty small, with megagate FPGAs in high
volume. Five, or even two years ago, was pretty different.
Not every design has the need for million gate device functionality,
Altera and Xilinx's low cost families seem to be selling in big
numbers. Sometimes it's important to push the performance of these
lower cost devices to keep costs down. Getting the same functionality
into a smaller device can also be important if power consumtion is
critical (my original point).

How many power supplies do you need for your big devices?

The Google description for this group is: Field Programmable Gate Array
based computing systems, under Computer Architecture FPGA. And, after
a few years, I think we are finally getting there .... FPGA based
coputing instead of CPU based computing.
This newsgroup and FPGAs were around long before some numpty at Google
decided what their description should be. I don't think we should
be taking this as a guiding pointer for the future.


The days of FPGA's being only for hardware design are slipping away.
While this group has been dominated by hardware designers using FPGA's
for hardware designs, I suspect that we will see more and more
engineers of all kinds here doing computing on FPGA's, at all levels.
That's probably true, and I expect to be using other tools as well as
VHDL in 5 years. However as John posted above, there's alot more to
implementing an FPGA design than the description used for the logic
and I think we'll still be using HDLs to get the most out of them for
a long time to come (to a bigger extent than with C/asm).



Nial.
 

Guest
Nial Stewart wrote:
That may be the case for large multi designer designs, for smaller
devices someone who understands the underlying architecture and
what they're actually trying to design to will be needed.
I think that has always been the case for embedded, and realtime, and
any other tightly integrated hardware/software design of any size.

The problem is, people who talk about this stuff get into their niche
and see everything else from that perspective. Few people routinely
work with a broad spectrum of systems from 4-bit to 64-bit and code
volumes from a few hundred bytes to a few dozen megabytes."
Certainly true. As a consultant, I can only view the diverse sample of
my clients for a perspective ... and that is certainly harder for W-2
employees that have lived inside the same company for the last 10
years. It would be interesting to take a survey at a developers
embedded conference as get a better feel for the real numbers.

You seem to have a deeply entrenched view of the FPGA development future.
Only time will tell if you are correct or not, I don't believe you are
and I'll leave it at that.
More like a receintly converted evangelist, with a pragmatic view of my
prior 35 years of systems programming experiences casting a view on
this new field and watching what is happening around me too.

I did have a little fun this evening, writing a PCI target mode core in
FpgaC as an example for the beta-2 release that is nearly at hand. It's
not quite done, but checked in to subversion on sourceforge in the
FpgaC examples directory. For something that is a bus interface state
machine, it is expressed in C pretty nicely, and will get better as
unions/enums are added to FpgaC.

It brought out a couple problems with using I/O ports as structure
members that I need to fix in FpgaC tomarrow, then finish the pci
coding along with a C test bench before testing/installing on my Dini
DN2K card.
 
C

Colin Paul Gloster

Guest
In news:nn1kv1t60lgcsm0tn2v5tnhnbn836166ed@4ax.com timestamped 23 Feb 2006 12:39:58 -0800, it was posted

"[..]

The Google description for this group is: Field Programmable Gate Array
based computing systems, [..]

[..]"

In news:468449F9vf44U1@individual.net timestamped Fri, 24 Feb 2006
10:06:01 -0000, Nial Stewart replied:

"[..]

This newsgroup and FPGAs were around long before some numpty at Google
decided what their description should be. [..]

[..]"

This has nothing to do with Google. Check your newsgroups file, the
description of this group is "Field Programmable Gate Array
based computing systems." See
WWW.SLRN.org/manual/slrn-manual-6.html#ss6.117
or
HTTP://Quimby.Gnus.org/gnus/manual/gnus_358.html#SEC358
or something similar.
 

Guest
Nial Stewart wrote:
You've had to understand the target architecture and what's causing your
timing constraint to fail, then re-jig your HDL to reduce the number of
levels of logic to achieve timing closure.

Not at all. Programmers juggle instruction/statement flow all the time
to reach timing closure in C and asm for device drivers and embedded
applications in many fields
First, your cut an paste of several different points and answers isn't
accurate. My answer above is to this part that that it directly
followed:

||> I thought that one of the arguments for using a C based HDL was you
can avoid
||> this level of design implementaion detail?

My point was and is that low level programmers have to understand the
underlying hardware in significant detail to program it properly ...
that has never changed in 35 years. It really doesn't mater if we are
talking about clock latency and scheduling for multiple pipelines, or
the physics and dynamics of a motion control system. I really does
matter if the system measurement units are hours, seconds, microseconds
or picoseconds. Or that the units are core access and cycle times,
pipeline latencies, clock cycles, gate delays or routing segment
latencies.

But you're not just juggling lines of code about so the order of
execution is different (ie to make sure things are picked up
quickly enough in an ISR or whatever).
Certainly. So what's your point?

Looking at the problem a little more this afternoon, the C based 66mhz
PCI core is looking much more viable. The combinatorial length was
actually from unnecessarily including the main references to the pci
bus signals in the else side of the reset conditional. Breaking that
dependency changed the base FSM speed from 63mhz to better than 73mhz,
making it likely the other setup and hold times can be met as well.

I still think this is an accurate observation...

"You've had to understand the target architecture and what's causing your
timing constraint to fail, then re-jig your HDL to reduce the number of
levels of logic to achieve timing closure."
Certainly. But the second part and real point in your question remains,
and that I addressed in detail I still have issues with:

|| > I thought that one of the arguments for using a C based HDL was
you can avoid
||> this level of design implementaion detail?

and the answer remains, not at all.
 

Guest
On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote:
On Mon, 2006-02-20 at 10:18 -0800, 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?

In a former position I pondered this very question.

What is firmer than firmware (the term they used to describe code
designs for micro-controllers) but softer than hardware (designs using
wires to connect together various components)?

The answer I came up with was "stiffware".

The problem is that there are elements of both in FPGA code, or at least
there can be. And depending on how you write your VHDL it may resemble
one more than the other.

James.
"Stiffware" I love it!!
 
J

Jon Elson

Guest
On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote:

On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote:
On Mon, 2006-02-20 at 10:18 -0800, 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?
The FPGA manufacturers call it the "configuration", but I don't think
firmware is very wrong when talking to less-technical folks.

Jon
 
R

Rick C

Guest
On Wednesday, January 29, 2020 at 3:07:11 PM UTC-5, Jon Elson wrote:
On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote:

On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote:
On Mon, 2006-02-20 at 10:18 -0800, 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?
The FPGA manufacturers call it the "configuration", but I don't think
firmware is very wrong when talking to less-technical folks.

Jon
I think "configuration" would be equivalent to the machine code that is produced by a standard compiler for CPUs. The OP is asking what to call the source code. In PCs and other typical computers it is "software". In embedded applications it is "firmware", mainly because it is loaded into a write only memory (or write mostly). So what name to use for programming that is for configuring hardware?

I think I'm in favor of "hardware"... oh, what, that's already used... lol

Firmware is as good as any term. I'm ok with calling it software.

--

Rick C.

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

gtwrek

Guest
In article <7d2a4342-3444-435c-a73b-9e130834212f@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:
Firmware is as good as any term. I'm ok with calling it software.
"Firmware" is one of those terms that has a very specific meaning in a
very specific context. And means exactly what it is intended to mean.
But as soon as the context changes... So does the definition.

Which makes the term practically useless as a general use technical
description. Sure for the general public, (or anything above a level 2
manager), "Firmware" might as well mean "The magic smoke which makes my
device do things when I turn it on". Usually one thinks of it as
applying to "embedded" electronic devices - which is another fuzzy
definition in itself. Here, "Embedded" usually means any device that's
not a personal computer sitting on one's desk. But even that's up
for argument...

Regards,
Mark
 
R

Rick C

Guest
On Wednesday, January 29, 2020 at 7:28:18 PM UTC-5, gtwrek wrote:
In article <7d2a4342-3444-435c-a73b-9e130834212f@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:

Firmware is as good as any term. I'm ok with calling it software.

"Firmware" is one of those terms that has a very specific meaning in a
very specific context. And means exactly what it is intended to mean.
But as soon as the context changes... So does the definition.

Which makes the term practically useless as a general use technical
description. Sure for the general public, (or anything above a level 2
manager), "Firmware" might as well mean "The magic smoke which makes my
device do things when I turn it on". Usually one thinks of it as
applying to "embedded" electronic devices - which is another fuzzy
definition in itself. Here, "Embedded" usually means any device that's
not a personal computer sitting on one's desk. But even that's up
for argument...
So what is that very specific meaning of "firmware"??? I've not come across it. Every source I check has a different wording and meaning.

Wikipedia - In computing, firmware[a] is a specific class of computer software that provides the low-level control for the device's specific hardware.

Google - permanent software programmed into a read-only memory.

techterms.com - Firmware is a software program or set of instructions programmed on a hardware device. It provides the necessary instructions for how the device communicates with the other computer hardware.

lifewire.com - Firmware is software that's embedded in a piece of hardware

So each one is different enough that the included classes vary hugely!

What is yours?

--

Rick C.

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

Theo

Guest
Jon Elson <elson@pico-systems.com> wrote:
On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote:

On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote:
On Mon, 2006-02-20 at 10:18 -0800, 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?
The FPGA manufacturers call it the "configuration", but I don't think
firmware is very wrong when talking to less-technical folks.
I'm uncomfortable with the use of 'firmware', because FPGAs frequently have
some kind of processors on them, either soft cores or hard cores like the
ARM on a Zynq. Those cores run a software stack - either bare metal, some
RTOS or maybe Linux. There's quite a difference between the software
running on these cores and the hardware design programmed into the FPGA.
Typically when one refers to an embedded product 'firmware' is referring to
software for a processor. If you advertise for FPGA firmware engineers you
might expect software people to apply for the job, for instance.

Another term used for the hardware is 'bitstream' - not very descriptive,
although it does imply the hardware-blockbox overtones to it.

If you're talking in general terms about the lump of data loaded from flash
on boot, used to make the product usable, without any distinction of whether
it's hardware or software, then maybe firmware works slightly better.

Theo
 
R

Rick C

Guest
On Wednesday, January 29, 2020 at 8:07:01 PM UTC-5, Theo wrote:
Jon Elson <elson@pico-systems.com> wrote:
On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote:

On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote:
On Mon, 2006-02-20 at 10:18 -0800, 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?
The FPGA manufacturers call it the "configuration", but I don't think
firmware is very wrong when talking to less-technical folks.

I'm uncomfortable with the use of 'firmware', because FPGAs frequently have
some kind of processors on them, either soft cores or hard cores like the
ARM on a Zynq. Those cores run a software stack - either bare metal, some
RTOS or maybe Linux. There's quite a difference between the software
running on these cores and the hardware design programmed into the FPGA.
Typically when one refers to an embedded product 'firmware' is referring to
software for a processor. If you advertise for FPGA firmware engineers you
might expect software people to apply for the job, for instance.

Another term used for the hardware is 'bitstream' - not very descriptive,
although it does imply the hardware-blockbox overtones to it.

If you're talking in general terms about the lump of data loaded from flash
on boot, used to make the product usable, without any distinction of whether
it's hardware or software, then maybe firmware works slightly better.

Theo
I guess my interest is in a label for the program as written in the language, the HDL. I don't call that a bitstream. The bitstream is what gets loaded into the FPGA. I write software or firmware. I've never gotten used to the term "gateware" but it would be fine if that is what ends up being accepted ultimately.

Rather than to say, this term means this and that term means that, I would ask what the purpose of using those terms would be? What distinction is being made?

--

Rick C.

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

David Wade

Guest
On 30/01/2020 01:29, Rick C wrote:
On Wednesday, January 29, 2020 at 8:07:01 PM UTC-5, Theo wrote:
Jon Elson <elson@pico-systems.com> wrote:
On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote:

On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote:
On Mon, 2006-02-20 at 10:18 -0800, 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?
The FPGA manufacturers call it the "configuration", but I don't think
firmware is very wrong when talking to less-technical folks.

I'm uncomfortable with the use of 'firmware', because FPGAs frequently have
some kind of processors on them, either soft cores or hard cores like the
ARM on a Zynq. Those cores run a software stack - either bare metal, some
RTOS or maybe Linux. There's quite a difference between the software
running on these cores and the hardware design programmed into the FPGA.
Typically when one refers to an embedded product 'firmware' is referring to
software for a processor. If you advertise for FPGA firmware engineers you
might expect software people to apply for the job, for instance.

Another term used for the hardware is 'bitstream' - not very descriptive,
although it does imply the hardware-blockbox overtones to it.

If you're talking in general terms about the lump of data loaded from flash
on boot, used to make the product usable, without any distinction of whether
it's hardware or software, then maybe firmware works slightly better.

Theo

I guess my interest is in a label for the program as written in the language, the HDL. I don't call that a bitstream. The bitstream is what gets loaded into the FPGA. I write software or firmware. I've never gotten used to the term "gateware" but it would be fine if that is what ends up being accepted ultimately.
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.


Rather than to say, this term means this and that term means that, I would ask what the purpose of using those terms would be? What distinction is being made?
Generally we use the term "firmware" to refer to code that is in some
way an intrinsic part of the hardware, without which it won't function.

Dave
 
R

Rick C

Guest
On Thursday, January 30, 2020 at 4:31:29 AM UTC-5, David Wade wrote:
On 30/01/2020 01:29, Rick C wrote:
On Wednesday, January 29, 2020 at 8:07:01 PM UTC-5, Theo wrote:

If you're talking in general terms about the lump of data loaded from flash
on boot, used to make the product usable, without any distinction of whether
it's hardware or software, then maybe firmware works slightly better.

Theo

I guess my interest is in a label for the program as written in the language, the HDL. I don't call that a bitstream. The bitstream is what gets loaded into the FPGA. I write software or firmware. I've never gotten used to the term "gateware" but it would be fine if that is what ends up being accepted ultimately.

Interesting question. You write a hardware description language so what
you produce must be the "Hardware description"...
The source code is indeed a 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.



Rather than to say, this term means this and that term means that, I would ask what the purpose of using those terms would be? What distinction is being made?


Generally we use the term "firmware" to refer to code that is in some
way an intrinsic part of the hardware, without which it won't function.
My PC won't function without software. So what is really different? Originally it had to do with the fact that firmware resided in ROM or EPROM which could only be programmed by means other than just loading it into RAM.

Now with Flash memory being rewritable in the system, there is much less distinction and in many systems the Flash acts more like a hard drive with the program being executed from RAM. Raspberry Pi devices are like that. Everything about developing code for a rPi is like developing code for a PC, but in the end it is an embedded system.

So what would be the purpose of calling this firmware... or any other device?

--

Rick C.

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

gtwrek

Guest
In article <6b78649f-b7f1-42d8-bb78-c1431b762072@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:
On Wednesday, January 29, 2020 at 7:28:18 PM UTC-5, gtwrek wrote:
In article <7d2a4342-3444-435c-a73b-9e130834212f@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:

Firmware is as good as any term. I'm ok with calling it software.

"Firmware" is one of those terms that has a very specific meaning in a
very specific context. And means exactly what it is intended to mean.
But as soon as the context changes... So does the definition.

Which makes the term practically useless as a general use technical
description. Sure for the general public, (or anything above a level 2
manager), "Firmware" might as well mean "The magic smoke which makes my
device do things when I turn it on". Usually one thinks of it as
applying to "embedded" electronic devices - which is another fuzzy
definition in itself. Here, "Embedded" usually means any device that's
not a personal computer sitting on one's desk. But even that's up
for argument...

So what is that very specific meaning of "firmware"??? I've not come across it. Every source I check has a different wording and meaning.

Wikipedia - In computing, firmware[a] is a specific class of computer software that provides the low-level control for the device's specific hardware.

Google - permanent software programmed into a read-only memory.

techterms.com - Firmware is a software program or set of instructions programmed on a hardware device. It provides the necessary instructions for how the device communicates with the other computer hardware.

lifewire.com - Firmware is software that's embedded in a piece of hardware

So each one is different enough that the included classes vary hugely!

What is yours?
That's my point. My definition entirely depends on context. So much so
that as a general term "firmware" is next to useless in a general
technical forum...

Regards,

Mark
 
G

gtwrek

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

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

My 2cents.

Regards,
Mark
 
R

Rick C

Guest
On Thursday, January 30, 2020 at 2:23:26 PM UTC-5, gtwrek wrote:
In article <6b78649f-b7f1-42d8-bb78-c1431b762072@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:
On Wednesday, January 29, 2020 at 7:28:18 PM UTC-5, gtwrek wrote:
In article <7d2a4342-3444-435c-a73b-9e130834212f@googlegroups.com>,
Rick C <gnuarm.deletethisbit@gmail.com> wrote:

Firmware is as good as any term. I'm ok with calling it software.

"Firmware" is one of those terms that has a very specific meaning in a
very specific context. And means exactly what it is intended to mean.
But as soon as the context changes... So does the definition.

Which makes the term practically useless as a general use technical
description. Sure for the general public, (or anything above a level 2
manager), "Firmware" might as well mean "The magic smoke which makes my
device do things when I turn it on". Usually one thinks of it as
applying to "embedded" electronic devices - which is another fuzzy
definition in itself. Here, "Embedded" usually means any device that's
not a personal computer sitting on one's desk. But even that's up
for argument...

So what is that very specific meaning of "firmware"??? I've not come across it. Every source I check has a different wording and meaning.

Wikipedia - In computing, firmware[a] is a specific class of computer software that provides the low-level control for the device's specific hardware.

Google - permanent software programmed into a read-only memory.

techterms.com - Firmware is a software program or set of instructions programmed on a hardware device. It provides the necessary instructions for how the device communicates with the other computer hardware.

lifewire.com - Firmware is software that's embedded in a piece of hardware

So each one is different enough that the included classes vary hugely!

What is yours?

That's my point. My definition entirely depends on context. So much so
that as a general term "firmware" is next to useless in a general
technical forum...
Yeah, I think I misread your other post. I agree. It's like Humpty Dumpty said,

“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”

--

Rick C.

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

David Wade

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

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


My 2cents.

Regards,
Mark
Dave
 
G

gtwrek

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

David Wade

Guest
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
 
Toggle Sidebar

Welcome to EDABoard.com

Sponsor

Top