How the LED light of a USB card reader works?

[magic]

Not gonna participate in a dumb flamewar, but

To me, "firmware" refers to the complex programmable logic and behaviour implemented in an FPGA, ASIC, microcontroller, or other processor, that is fundamental to its operation.  I consider the FTDI FT232H and others ASICs.  (For example, AMD64 aka x86-64 processors themselves have firmware, in the form of updateable microcode, that can change the behaviour of these processors.)

This is because they are designed using programming languages, typically Verilog/VHDL or some variant of C, and not as logic circuits.
That is, humans do not care exactly what logic circuits are implemented; the designers only specify the behaviour, using an abstract programming language.

I think most people have a slightly different concept of what "firmware" is

[Nominal Animal]

I think most people have a slightly different concept of what "firmware" is

If you stoop down to just sniping, and don't even bother to define what you insinuate what that might be, what worth is your post except to fan the flamewar?  Then again, fanning the flamewar is what you usually do, rather than help others, isn't it, magic?

I personally would honestly be quite interested in learning what that "concept of firmware that most people have" actually is.  (I'm being precisely thruthful here; I do realize that my use of "firmware" threw some of you way off, and therefore I can do better.  But, to do better, I'd need a better definition.  Instead of providing one, you're just fanning the flames by insinuating that one so superior exists that everybody knows it, except Nominal Animal, of course.)

Would you, magic, for once put your money where your flamewar-fanning mouth is, and provide the definition of firmware you believe most people have?  And don't just point to elsewhere or talk shit, just write your definition down.  Please?

[radiolistener]

I personally would honestly be quite interested in learning what that "concept of firmware that most people have" actually is. 

Classic "firmware" means MCU code which is stored in device read-only memory and implements the main function of the device.

Here is definition from dictionary:

In computer systems, firmware is a set of commands which are stored on a chip rather than as part of a program, because the computer uses them very often.

But modern devices is more flexible, it may load firmware from external flash or it can be uploaded to device at OS boot. But this is still the part of computer program code which implements the main function of the device and is executed on computer inside device.

If you talking about gate configuration for FPGA, then this is gateware. There is no computer commands and it is not used to produce computer program, it uses very different concept than computer program, so you cannot name it as firmware.


And to be clear, yes - verilog has a part of syntax which can be used to write computer programs. But this part cannot be used to describe hardware. It's just a kind of embedded script, which helps to do testing. This part of code is just ignored during gateware synthesis.

Using C code to describe hardware circuit is the same as write hardware emulator in C, it can work but hardware emulator and real hardware are different things, there is no equality between emulator and real hardware despite the fact that both may do the same things and result may looks similar.

[pcprogrammer]

If you talking about gate configuration for FPGA, then this is gateware. There is no computer commands and it is not used to produce computer program, it uses very different concept than computer program, so you cannot name it as firmware.

I beg to differ on this. Since it is possible to load memory cells from the FPGA configuration stream, there can be "computer commands" in the configuration storage used for a FPGA.

Logic in a FPGA can be used to make a processor core (think of Risc-V) which needs a program to run, and that program can be stored in the FPGA's memory cells, either as ROM or as RAM. So the FLASH memory that holds the configuration data for the FPGA can also hold the firmware being run by the so called "soft core".

Basically this is a useless discussion and just boils down to semantics. To me the term firmware is an indication that it is fixed firmly into the device, and not like software that can be loaded or unloaded when needed. Hardware, well the name gives a glue means the hardwired components that make up a device.

A gate is just a term for a gathering of components that in that way make up a logic function, or it can, in a different setting, be a device to keep you from getting in. 

[radiolistener]

Logic in a FPGA can be used to make a processor core

Yes, gateware may implement processor core emulation, so gateware may include bitstream with firmware image for this core emulator. But this is still gateware which implements computer emulator. Because there is no processor core, it is emulated by gateware. 

The same you can emulate analog circuit in LTSpice or other software, but you cannot say that software is hardware, these are different concepts.

[pcprogrammer]

Logic in a FPGA can be used to make a processor core

Yes, gateware may implement processor core emulation, so gateware may include bitstream with firmware image for this core emulator. But this is still gateware which implements computer emulator. Because there is no processor core, it is emulated by gateware. 

The same you can emulate analog circuit in LTSpice or other software, but you cannot say that software is hardware, these are different concepts.

Nope. It is not an emulation of a processor core. It is building a core from logic cells just like the original one. Going on your definition everything in a FPGA would be an emulation. Describe a UART in HDL and synthesize it for your FPGA. Oh, that is not a real UART, that is an emulation. You see where I'm heading?

What you call gateware is a bunch of bits that define the state of the logic cells in the FPGA and how the connections are made. Comparable with taking a bunch of 74 logic ic's and wire them up with wire wrap. The type of logic ic is based on the configuration bits for the logic cells and the wiring is based on the configuration bits for the connections. So no emulation, but actual real hardware.

I wonder if you have even studied in depth how a FPGA works. Having reversed engineered the configuration bit stream of one of them I can say that I did.

[radiolistener]

Nope. It is not an emulation of a processor core. It is building a core from logic cells just like the original one.

It is emulation, because there is no processor core, there is array or programmable logic elements. And the file represents its configuration. This is why it is named gateware.

Going on your definition everything in a FPGA would be an emulation. Describe a UART in HDL and synthesize it for your FPGA. Oh, that is not a real UART, that is an emulation. You see where I'm heading?

Yes, everything what you do on FPGA is emulation and the file which you upload to FPGA is gateware, even if it implements computer emulator with commands, all this is represented with gate configuration bitstream.

Everything designed on an FPGA is implemented by configuring programmable logic elements, and these elements are configured using a gateware bitstream. So, even if you've implemented a ZX Spectrum computer on an FPGA, you cannot say that the gateware is firmware for the ZX Spectrum. No, this is still gateware, but it configures the FPGA to emulate the ZX Spectrum's hardware and its behavior, including the ability to run the original firmware, using the gate configurations defined in the gateware.

Some FPGA IC contains both FPGA and MCU, in this case you need to upload gateware and firmware.

[radiolistener]

What you call gateware is a bunch of bits that define the state of the logic cells in the FPGA and how the connections are made. Comparable with taking a bunch of 74 logic ic's and wire them up with wire wrap.

No, this is not entirely accurate. While FPGAs can indeed emulate logic gates like AND, OR, XOR, NOT or 74 ic's, they do it using more complex structures named Logic Elements. An FPGA is composed of numerous logic elements (LEs), each containing a lookup table (LUT), registers, and sometimes additional components like flip-flops. These LEs are not simple gates or 74 ic's equivalent, but configurable units that can be programmed to perform a variety of digital functions, including emulating multiple logic gates or even small blocks of a circuit.

For example, here is what a single logic element in a Cyclone IV FPGA looks like:


So, while FPGAs can emulate circuits made of logic gates like in 74 series ICs, they do this through a more sophisticated process that involves programming LUTs and connecting these LEs in specific ways.

Gateware is a configuration bitstream which define how to configure these LE in that way that they can emulate your circuit described with HDL with using array of LE's.

So, if you write something like `a & b` in Verilog, it doesn’t directly translate to "connect a and b signals to an AND gate and get the output." Instead, it leads to the emulation of the AND gate using an LE element. Everything you write in HDL will be synthesized and implemented on FPGA using these logic elements. The FPGA logic elements will be configured to perform the desired logic functions by using lookup tables that can emulate multiple logic gates or even small portions of your circuit.

[radiolistener]

To be short, firmware is a program for MCU.
Gateware is a configuration bitstream for FPGA.

And now I think it's pretty clear that these things are very different.

[magic]

I think most people have a slightly different concept of what "firmware" is

If you stoop down to just sniping, and don't even bother to define what you insinuate what that might be, what worth is your post except to fan the flamewar?  Then again, fanning the flamewar is what you usually do, rather than help others, isn't it, magic?

It's just a hint that you may be going off the rails, in my opinion.
I don't feel like writing walls of text to argue with people.

And I don't feel like reading such either, so you can rest assured I only respond to small bits that somehow catch my attention in such threads, hence "sniping".

In fact, I respond here because somebody quoted your angry post in the other thread that you started. Off the top of my head, I can't even tell if I would notice it myself while scrolling down and if I would come here ever again. I don't understand the mentality behind reading such threads, analyzing other people's posts for hours, and responding to them for hours. Sounds like massive waste of time, and for what gain exactly? "Two guys argue about definitions of words" is all that's left when the dust settles.

Would you, magic, for once put your money where your flamewar-fanning mouth is, and provide the definition of firmware you believe most people have?  And don't just point to elsewhere or talk shit, just write your definition down.  Please?

You would be better off asking most people than me, as I specifically said I think it's them that you are out of touch with, not me.

Who cares about my opinion? But here it is, to show I'm not making stuff up:

I think, and I think most people think, that "firmware" is software or data programmed into a device for it to work. So, executable code for embedded cores, maybe FPGA bitsteams (hello, radiolistener ) or flowcharts in some formal langauge, PHP code, whatever. Specifically, not any formal description of the hardware or requirements specification used to derive the former. Gerber files are not firmware, and neither is HDL, neither are questions you asked GPT to make it spit out the Gerbers and HDL for you, and so on.

[tooki]

To be short, firmware is a program for MCU.
Gateware is a configuration bitstream for FPGA.

And now I think it's pretty clear that these things are very different.

Weeeeeellll……

Even the FPGA manufacturers can’t agree on what it’s called, so “gateware” is certainly not established enough a term that you can decree that it is the only correct term.

As for firmware vs software, let’s review the history of the terms.

Of course we started with hardware, the hard-wired circuitry. The earliest computers were always hard-wired for a particular function.

When computers were later introduced which ran programs that first had to be loaded into working memory (what we imprecisely call RAM) to be run, and the working memory is typically initialized and blanked on startup. So software became the term for program code loaded into volatile memory from a storage medium like punch cards, punched tape, magnetic tape or disks, etc. (Or even from a paper code listing, if manually entered by the operator like on an Altair.)

When we started storing program code in read-only storage that is built into the machine (core rope memory, mask ROM, PROM, and EPROM), we coined “firmware” to mean “software that’s fixed in hardware”, with “firm” being a consistency between hard and soft. At the time the term was coined, these were truly read-only storage, with even EPROMs being programmed separately and being unalterable without removing it from the computer. So “firmware” first came to mean “program code that never changes without modifying the hardware”. In many things, we just referred to them as the ROM. And as we know, this usually was used for either low-level code in complex systems, or for all the code in little embedded systems like MCUs. (Very few complex systems used ROM for high-level code, but there are a few examples, like very early Macs, which contained most of the operating system in ROM, and just had clever mechanisms to let the OS on the disk “patch” the ROM code when changes were needed.) In a strict sense, firmware is a subtype of software.

Later, by the time EEPROMs that can be programmed in-circuit came out, the term “firmware” was already fairly established to mean “low-level code in complex systems, or all the code in little embedded systems like MCUs”, and so we kept it even after the hardware gained the capability of modifying said code. And that’s the meaning it retains to this day. It doesn’t have to mean an MCU exclusively, it can also mean the low-level code for a main CPU.


FPGAs are an interesting case, insofar as the source for the bitstream can be firmware or software. (For example, in many modern oscilloscopes the firmware contains the FPGA bitstream, but in Windows-based oscilloscopes, it can be loaded directly from the software on the boot drive.)

[tooki]

Nope. It is not an emulation of a processor core. It is building a core from logic cells just like the original one.

It is emulation, because there is no processor core, there is array or programmable logic elements. And the file represents its configuration. This is why it is named gateware.

Going on your definition everything in a FPGA would be an emulation. Describe a UART in HDL and synthesize it for your FPGA. Oh, that is not a real UART, that is an emulation. You see where I'm heading?

Yes, everything what you do on FPGA is emulation and the file which you upload to FPGA is gateware, even if it implements computer emulator with commands, all this is represented with gate configuration bitstream.

While I understand your logic in wanting to say that everything done in an FPGA is “emulation”, in that it isn’t hard-wired to do something, that is not how the term emulation is used in either the electronics or computing worlds. In computing, FPGAs are typically contrasted with emulation. In electronics, “hardware emulation” (because of historical usage) generally means a system with extra debugging instrumentation, whereas an FPGA doesn’t add those extra things.

But broadly speaking, when you emulate something, you don’t become it. So when you emulate one CPU on another CPU in software, the host CPU does things, but it doesn’t become the emulated CPU. In contrast, when an FPGA loads its bitstream containing the CPU core, that part of the FPGA effectively becomes that CPU. Until another bitstream is loaded, those logic cells are that CPU.

Think of it like this: if you use simple 7400- or 4000-series logic chips to build an alarm clock, for example, would you say that they are “emulating” an alarm clock? You could still desolder them and use them to build something else. But during the time they’re installed in the alarm clock, we would say that you have an alarm clock, not an emulated alarm clock.

Everything designed on an FPGA is implemented by configuring programmable logic elements, and these elements are configured using a gateware bitstream. So, even if you've implemented a ZX Spectrum computer on an FPGA, you cannot say that the gateware is firmware for the ZX Spectrum. No, this is still gateware, but it configures the FPGA to emulate the ZX Spectrum's hardware and its behavior, including the ability to run the original firmware, using the gate configurations defined in the gateware.

”Implement”, like you use in the first sentence here, is a much better way of describing what an FPGA is doing. It’s implementing something using its logic cells. But it isn’t emulating it.

[radiolistener]

When we started storing program code in read-only storage that is built into the machine (core rope memory, mask ROM, PROM, and EPROM), we coined “firmware” to mean “software that’s fixed in hardware”, with “firm” being a consistency between hard and soft. At the time the term was coined, these were truly read-only storage, with even EPROMs being programmed separately and being unalterable without removing it from the computer. So “firmware” first came to mean “program code that never changes without modifying the hardware”. In many things, we just referred to them as the ROM. And as we know, this usually was used for either low-level code in complex systems, or for all the code in little embedded systems like MCUs. (Very few complex systems used ROM for high-level code, but there are a few examples, like very early Macs, which contained most of the operating system in ROM, and just had clever mechanisms to let the OS on the disk “patch” the ROM code when changes were needed.) In a strict sense, firmware is a subtype of software.

Great explanation 

FPGAs are an interesting case, insofar as the source for the bitstream can be firmware or software. (For example, in many modern oscilloscopes the firmware contains the FPGA bitstream, but in Windows-based oscilloscopes, it can be loaded directly from the software on the boot drive.)

Yes, firmware can contain embedded resources, include gateware. But it still named firmware because it is intended to use on MCU.

The same gateware can contain embedded resources, include firmware. But it still named gateware because it is intended to use on FPGA.

The same software can contain embedded resources, include firmware or/and gateware. But it still named software because it is intended to use on CPU.

In electronics, “hardware emulation” (because of historical usage) generally means a system with extra debugging instrumentation, whereas an FPGA doesn’t add those extra things.

No. Emulation is not about debugging.

Emulation is the process of mimicking the behavior of one system or environment using another system or environment.

In our example FPGA mimicking the behavior of circuit described by your HDL using its array of programmable logic elements. This this exactly what "emulation" means. 

I wrote many emulators in the past, include ZX Spectrum, MSP430, and many other things, so I know what I'm talking about. 

And note that the key point here is that FPGA don't implement circuit which you describe with HDL, it emulate it. 

[tooki]

FPGAs are an interesting case, insofar as the source for the bitstream can be firmware or software. (For example, in many modern oscilloscopes the firmware contains the FPGA bitstream, but in Windows-based oscilloscopes, it can be loaded directly from the software on the boot drive.)

Yes, firmware can contain embedded resources, include gateware. But it still named firmware because it is intended to use on MCU.

The same gateware can contain embedded resources, include firmware. But it still named gateware because it is intended to use on FPGA.

The same software can contain embedded resources, include firmware or/and gateware. But it still named software because it is intended to use on CPU.

Are you sure you fully understood my definition of “firmware”? Because firmware can target an MCU, or it can target a CPU.

And I think that at least some MCUs are capable of running “true” software; that is, program code loaded into RAM after startup from some external storage device that isn’t an integral part of the hardware, like an SD card.



Anyway, what I was saying here is that the FPGA bitstream can be stored as a resource within firmware, or as a resource within software. I wasn’t saying that this means the bitstream becomes firmware or software as such!

[radiolistener]

Are you sure you fully understood my definition of “firmware”? Because firmware can target an MCU, or it can target a CPU.

Yes, I understand what you're talking about. And yes, some devices may not have MCU at all and may use main CPU to execute firmware. But since this code implements device functions it can be named firmware.

And I think that at least some MCUs are capable of running “true” software; that is, program code loaded into RAM after startup from some external storage device that isn’t an integral part of the hardware, like an SD card.

Yes, CY7C68013A runs in that way. But since we talking about the program code which implements device function, this is firmware. It doesn't depends if it's flashed into the chip or loaded on every boot...

Anyway, what I was saying here is that the FPGA bitstream can be stored as a resource within firmware, or as a resource within software. I wasn’t saying that this means the bitstream becomes firmware or software as such!

Yes, if you implement emulation for some CPU/MCU on FPGA, you need to attach embedded resource to your gateware for emulated system. But since this is still bitstream for FPGA, it's name still gateware, even if it has embedded resources inside, like firmware, software, bitmap images or whatever you want...

The same with firmware, if your MCU needs to upload gateware into FPGA, it may embed resource with gateware. But this is still firmware.

The software emulator for some device needs to embed resource with firmware. But it still remains software even with firmware inside.

[tooki]

In electronics, “hardware emulation” (because of historical usage) generally means a system with extra debugging instrumentation, whereas an FPGA doesn’t add those extra things.

No. Emulation is not about debugging.

Preface 1. Scope for this definition is limited to electronics.
Preface 2. Scope for this definition is “hardware emulation”, not emulation in general.

Yes, it is. See e.g. https://en.wikipedia.org/wiki/Hardware_emulation#Emulation_versus_prototyping

Historically, it meant in-circuit emulators like the one described in the attached PDF.

Those existed entirely because of debugging. If you didn’t need debugging, you’d just insert the standard chip!

Emulation is the process of mimicking the behavior of one system or environment using another system or environment.

In our example FPGA mimicking the behavior of circuit described by your HDL using its array of programmable logic elements. This this exactly what "emulation" means. 

I wrote many emulators in the past, include ZX Spectrum, MSP430, and many other things, so I know what I'm talking about. 

And note that the key point here is that FPGA don't implement circuit which you describe with HDL, it emulate it. 

A CPU running code to emulate another CPU is indeed emulation: it is mimicking the emulated CPU. But the host CPU itself is not being reconfigured to accomplish this, and the result is not necessarily identical.

An FPGA is reconfiguring its circuits into the CPU core. It does that once, and after that, the CPU is running as a piece of hardware that operates the same as the real deal. Again: would you claim that an alarm clock made out of 7400 logic chips is only “emulating” an alarm clock? Or would you say it is an alarm clock? An FPGA is like a box of 7400 chips and a breadboard, with a little robot inside that installs the jumper wires for you. It isn’t performing the logic functions in software, it is configuring hardware to do it directly.

[tooki]

Are you sure you fully understood my definition of “firmware”? Because firmware can target an MCU, or it can target a CPU.

Yes, I understand what you're talking about. And yes, some devices may not have MCU at all and may use main CPU to execute firmware. But since this code implements device functions it can be named firmware.

And I think that at least some MCUs are capable of running “true” software; that is, program code loaded into RAM after startup from some external storage device that isn’t an integral part of the hardware, like an SD card.

Yes, CY7C68013A runs in that way. But since we talking about the program code which implements device function, this is firmware. It doesn't depends if it's flashed into the chip or loaded on every boot...

OK. I ask because in reply #62, you responded that it’s “firmware because it’s intended to run on an MCU” and “software because it’s intended to run on a CPU”, but both of those statements are provably false — even if it is probably true that most firmware runs on MCUs and most software-that-isn’t-firmware runs on CPUs.

Anyway, what I was saying here is that the FPGA bitstream can be stored as a resource within firmware, or as a resource within software. I wasn’t saying that this means the bitstream becomes firmware or software as such!

Yes, if you implement emulation for some CPU/MCU on FPGA, you need to attach embedded resource for emulated system to your gateware. But since this is still bitstream for FPGA, it's name still gateware, even if it has embedded resources inside, like firmware, software, bitmap images or whatever you want...

I didn’t say anything about firmware or software resources stored within an FPGA bitstream.

What I said is:

FPGAs are an interesting case, insofar as the source for the bitstream can be firmware or software. (For example, in many modern oscilloscopes the firmware contains the FPGA bitstream, but in Windows-based oscilloscopes, it can be loaded directly from the software on the boot drive.)

The interesting thing is that (correct me if I’m wrong) with modern FPGAs, they are entirely volatile and must have the bitstream reloaded after every power up, and that this bitstream can be stored in the hardware as firmware, or as a resource in software (on a hard disk or SD card or whatever).

[radiolistener]

An FPGA is reconfiguring its circuits into the CPU core. It does that once, and after that, the CPU is running as a piece of hardware that operates the same as the real deal.

No FPGA don't reconfigure anything. It just use its LE to emulate your circuit. FPGA LE array remains the same with any gateware. Gateware just configure exitsing LE to emulate your circuit. There is no real circuit described with your HDL, it is emulated on FPGA LE array. The precision of emulation depends on your HDL description.

For example my ZX Spectrum emulator was able to emulate almost all undocumented behavior of Z80, include hidden registers and precisely emulated CRT ray effects. Software running on emulator was unable to detect that it runs on emulator even with using different tricks and undocumented behavior. Because CPU was emulated include every flag behavior and every timing details. But even if it produces very precise emulation result, this is still emulator, not the real circuit.

The interesting thing is that (correct me if I’m wrong) with modern FPGAs, they are entirely volatile and must have the bitstream reloaded after every power up, and that this bitstream can be stored in the hardware as firmware, or as a resource in software (on a hard disk or SD card or whatever).

It is stored as gateware image. The firmware is not needed for FPGA. Yes, it can be configured to automatically load gateware from external flash on startup, or it can be uploaded by MCU or from host PC.

[tooki]

An FPGA is reconfiguring its circuits into the CPU core. It does that once, and after that, the CPU is running as a piece of hardware that operates the same as the real deal.

No FPGA don't reconfigure anything. It just use its LE to emulate your circuit. FPGA LE array remains the same with any gateware. Gateware just configure exitsing LE to emulate your circuit. There is no real circuit described with your HDL, it is emulated on FPGA LE array. The precision of emulation depends on your HDL description.

For example my ZX Spectrum emulator was able to emulate almost all undocumented behavior of Z80, include hidden registers and precisely emulated CRT ray effects. Software running on emulator was unable to detect that it runs on emulator even with using different tricks and undocumented behavior. Because CPU was emulated include every flag behavior and every timing details. But even if it produces very precise emulation result, this is still emulator, not the real circuit.

Again, not “emulation”. You’re just going to have to accept that FPGAs are not called emulation, regardless of how they do or do not function internally. The term “emulation” is kinda reserved for other things that are farther away from bare metal than an FPGA is.

Anyway, the FPGA certainly does configure itself: it configures the logic cells and sets the switches in the connection fabric. But once that’s done, it isn’t reconfiguring them during execution. As I said: that is like a little robot running jumper wires between chips on a breadboard.