How the LED light of a USB card reader works? - Page 1
Forum section: electronics / general

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 01, 2024, 10:34:24 am
content: I need to know how the LED light of a USB card reader that indicates the data transfer works?Is it possible to create such a light using transistors and putting that circuit parallelly with a data cable connected to a USB storage drive?In this diagram how that LED connected with the GPIO0 pin works?I was talking about the light that blinks in this video.https://drive.google.com/file/d/1odw-TqbCfqCP_JEQI6smA7dSSWmZ1QNp/view?usp=drive_linkelectrical-engineeringpower-electronicscomputer-hardwaredatacomputer

author: darkspr1te
author_rank: Frequent Contributor
timestamp: August 02, 2024, 08:02:30 am
content: The led is triggered by the USB -> sdcard chip itself, you could not "tap into" the two USB data lines without adding interference to the signal and USB frames would mean the light would be on 99% of the time. it would be easier to find a USB storage drive with LED signal built in.darkspr1te

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 03, 2024, 03:11:19 pm
content: That's okay, I can use a LED blinking circuit but how am I going to get the Rx/TX voltage to make the LED glow? The voltage is very less, about 1V. How to make a sensor for the data lines using a transistor or mosfet?

author: Andy Chee
author_rank: Super Contributor
timestamp: August 04, 2024, 09:04:54 am
content: My brute force idea would be to buffer the Tx/Rx lines and feed them into a clock divider chain. The output of the dividers should be slow enough to make a blinking rate perceivable by the human eye.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 04, 2024, 05:40:30 pm
content: Many USB hub and controller ICs support a suspend LED; see e.g.Microchip USB2422.The suspend indicator is active/asserted when the hub receives or transmits data from/to the host, and inactive/deasserted when the hub is not yet configured or is suspended. Whenever it is idle for 3 milliseconds or longer, the hub is suspended, and the LED turns off.I do believe that USB mass storage devices use the same signal for their activity LEDs, perhaps extended via a simple capacitor-transistor circuit (delaying the turn-off by a constant time, so the LED does not have to be so bright). That is, the activity LED is ON whenever the device is fully powered (active), and OFF when suspended.

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 07, 2024, 07:12:46 am
content: So how do I build a simple circuit using a transistor or a MOSFET that can be connected in parallel with the Rx/Tx lines of the USB to make the LED turn on whenever there is a data transfer?

author: darkspr1te
author_rank: Frequent Contributor
timestamp: August 07, 2024, 07:41:43 am
content: As i mentioned prior, You CANNOT just tap into the usb lines and make a led flash, I would advise you start reading USB standards to understand why. It's to long to write here but the TL;DR is that usb data frames are almost constant so any led would be on all the time, devices that have leds use internal triggers to act on certain USB data frames they see and flash the light on those only reducing the PWM of the led to a point you can see easily.

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 15, 2024, 09:48:33 am
content: I am able to check the voltage of the Rx/Tx lines of the USB during the data transfer using a multimeter. If the multimeter can read the voltage without interfering with the data transfer then why not using a circuit to detect the voltage during the data transfer?If you can't help then I guess I have to build it all by myself.

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 15, 2024, 09:51:06 am
content: could you please email me with your ides to prabhatkarpe4@gmail.com

author: magic
author_rank: Super Contributor
timestamp: August 15, 2024, 10:37:01 am
content: I'm not familiar with hi-speed (that's what you deal with, I presume?) USB physical layer and I'm too lazy today to look it up. I know that it uses low amplitude differential signaling, so tapping into it is not as straightforward as into full-speed. Butifit's the case that the lines always idle in a particular state, say D- lower than D+,thenit might be possible to detect presence of packets with relatively simple, low speed circuitry.There will be short packets every millisecond, one could try to design something that ignores very short packets completely or at least looks at the "duty cycle" of the link and only light up the LED if a particular rate of transfer is detected.So not entirely trivial, butmaybedoable...Of course it's best to figure out how to use the USB chip's built-in activity indicator, most of them have such things.

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 16, 2024, 02:50:31 pm
content: If the USB activity can show up on a multimeter as ~1V then it can be used to light up an LED too.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 16, 2024, 05:30:39 pm
content: Why don't you try it in practice and see for yourself?Start with an analog comparator, say AP331 or LMV331 in SOT25/SOT23-5, with its VCC (pin 5) connected to USB +5V, GND (pin 2) to USB GND, output (pin 4) connected to a suitable current-limiting resistor and a LED cathode, the LED anode connected to USB +5V. For a typical red LED, 1kΩ should work well, limiting the current to about 3mA (which should still be quite visible) which both of these can sink on their output.This configuration means that whenever the positive input (pin 1) has a lower potential than the negative input (pin 3), the LED will light up. The current drawn from the inputs is extremely low, under half a microamp (150nA typical), so it shouldn't affect the USB data lines.So, you connect the negative input (pin 3) to one of the data lines, and the positive input to a voltage divider formed from two large-valued resistors.That is R1 is connected between USB +5V and positive input (pin 1), and R2 connected between positive input (pin 1) and GND.This means that whenever the data line (connected to negative input, pin 3) exceeds about 5V*R2/(R1+R2), the LED will light up.For 0.9V, you'll want R1 to be 4 to 5 times R2, and the values high enough to not waste too much current; say R1+R2 between 50kΩ and 1MΩ.For simplicity, I'd pick R2=100kΩ and R1=470kΩ, setting the threshold voltage to 0.79V – 0.96V, depending on the USB +5V voltage (which may vary between 4.5V and 5.5V).In all, you'd need the comparator, three resistors (1kΩ, 100kΩ, 470kΩ), and an ordinary LED.I do believe it would workafter a fashion, for low-speed and full-speed USB devices like mice and keyboards, but not for high-speed USB devices like memory sticks. The signaling level at high-speed is only 0.4V. You could compensate by changing R2=33kΩ, which would set the threshold to 0.29V – 0.36V depending on the USB +5V voltage.Your insistence, however, tells my spidey-senses that this is an assignment you have: to find a way to use a simple transistor circuit to detect USB 1.1/2.0 data transfers. If so, the assignment is in error, becauseit is the wrong way to do it. It is like using two nails connected to mains voltage to cook a sausage. It may technically work, but it isn't a sensible or safe way to cook a sausage at all. Yes, you can find devices online that do exactly this, but that is not a proof that it is sensible to do, at all. (If this is the case, whoever gave you the assignment has a specific circuit in mind, that they want you to discover. I have an inkling of what that circuit would be, but I am utterly disgusted at the idea.)Now, let's consider thepropersolution.Mine would be a Microchip USB2512B or USB2514B USB 2.0 hub chip, 24 MHz crystal, bunch of bypass capacitors, resistors (including strapping resistors making it bus-powered), only one downstream port, and the activity LED connected to SUSP_IND pin. You can find a full schematic of a four-port hub (without an activity LED, just a 100kΩ resistor R3 to ground) atSparkFun's Githubto use as a basis, but note that the 22Ω series resistors are not needed when using USB251xB. You can easily design the board at EasyEDA, and have it manufactured and assembled at JLCPCB, for very little money. I know, because I am only a hobbyist, and yet this would easily be within even my skills. I know enough that the crystal PCB design would be the "tricky" part, but using the SparkFun KiCad files as a basis should make that easy and straightforward.To save costs, I would leave out the connectors and the ESD protection, and instead use an USB A male - A female (USB 2.0 extension cable), cutting it in half, and solder the cables directly to the board. By my count, I'd need the USB251xB, a 24 MHz crystal and its two load capacitors, five 0.1µF = 100nF bypass capacitors, two 1µF bypass capacitors, a 3.3V regulator (500mA or more), six 100kΩ resistors, three 10kΩ resistors (for disabling the unused ports), a P-channel MOSFET for power control of the downstream USB 5V, and a red LED with a 1kΩ current-limiting resistor.This is the closest equivalent of what USB devices have, when they have an activity indicator. Here, we use an USB hub with such an indicator; normally, the indicator LED output is provided by the USB interface chip on the device itself. On microcontrollers with native USB interfaces (including old AVRs like ATmega32u4 and 90USB1280, cheap WCH CH55xG E8051-based MCUs, ARM Cortex-M ones, and so on), there is an interrupt related to USB suspend, so one can use whatever GPIO pin for such an activity LED.Why is the "transistor only" activity circuit wrong? Because the USB data pins' voltage levels do vary normally. Proper activity cannot be reliably detected in all situations from their instant voltage potentials only. Instead, thestate of the USB bus itselfshould be considered –– and that is exactly what the "suspend" state does: whenever there is no activity for 1 millisecond or longer, the bus is suspended. It does not affect the USB 5V supply, nor limit the current the device can draw from it, it is purely a logical state for the USB bus, with no active communications ongoing, and nothing to do with electrical power.So, if you insist on exploring the "transistor only" route, do remember that doing that in a real life product would/should get you fired. (And if it is an exercise your professor gave you, they should be fired too.) It is the equivalent of cooking sausages with nails connected to mains, and selling the sausages for others to eat. Doing it properly, with an electric grill or stovetop and pan, takes a small investment up front, but leads to a better overall result for everyone (and more profit if you do it longer than a single day). Don't be the guy selling iffy sausages.

author: tooki
author_rank: Super Contributor
timestamp: August 16, 2024, 10:27:37 pm
content: Quote from: prabhatkarpe4 on August 15, 2024, 09:51:06 amIt’s extremely rude to ask on a public forum for replies via a private channel. Fora work by letting others see the questions and answers.

author: amyk
author_rank: Super Contributor
timestamp: August 18, 2024, 02:45:38 am
content: Much like how the activity LEDs on NICs are driven by the software, those on USB devices will be driven by the firmware they contain. This of course means the indicator canlie, which is why I don't think it's right to be characterising the analog approach as "not a proper solution". It's easy to make software lie, but it's harder to make analog components behave differently only under very specific circumstances.

author: magic
author_rank: Super Contributor
timestamp: August 18, 2024, 04:59:11 am
content: This approach has its own pitfalls. If you observe a traffic on the bus, you don't know if it's data transfer to the card or data transfer from the card or simply somebody repeatedly querying the card reader for its USB descriptors. And if you aren't careful, you could perhaps make your indicator sensitive not to an idle line, but some other condition like USB suspend. Then the user disables power management for any reason and suddenly it looks like the device is 100% utilized all the time.I'm not saying that this is the case here, but it might be. I'm too lazy to look up the low level details of USB 2.0 physical layer, and a big problem is that OP is too lazy as well.

author: radiolistener
author_rank: Super Contributor
timestamp: August 19, 2024, 06:43:32 am
content: usually it is connected to GPIO and controlled from driver code on PC.

author: magic
author_rank: Super Contributor
timestamp: August 19, 2024, 08:03:56 am
content: No, it's controlled by firmware on the card reader chip.Virtually all of them implement standard USB Mass Storage class, so they look like pendrives basically and use no special drivers. Storage Class has no concept of blinking LEDs, this is done by the device itself on its own.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 19, 2024, 08:58:40 am
content: Quote from: magic on August 18, 2024, 04:59:11 amUSB suspend is much more reliable indicator of "no action" than the USB data lines not having any activity.All the card readers and USB storage sticks I have do use USB suspend for the activity indicator: whenever the USB device interface is suspended, the LED is OFF, and ON otherwise. Remember, it has nothing to do withpowerand everything with active messaging between the device and the host. You can easily check this for yourself in Linux if you suspect otherwise.

author: magic
author_rank: Super Contributor
timestamp: August 19, 2024, 07:40:49 pm
content: All my card readers and pendrives which have LEDs (that's exactly one reader and one pendrive) behave differently: they light up when connected, don't go out on suspend, blink slowly on data transfer.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 20, 2024, 12:23:31 am
content: Interesting!I do absolutely agree to the LED blinking being controlled by the firmware; that was never in question.In the USB 2.0 era,USB224xwas a pretty typical USB media controller (USB to SD/SDHC/Transflash, MMC, etc.). It has internal flash memory for configuration – including the USB vendor and product identifiers and such –, and a dedicated LED pin capable of sourcing or sinking 12mA. There are three configuration bytes related to LEDs: blink interval (LED_BLK_INT, high bit sets idle state, and the rest the blink interval in units of 50ms), blink after address (LED_BLK_DUR, number of seconds blinking after access), and one attribute byte (ATT_HLB) which selects the LED mode (polarity and whether the LED only indicates activity or combined media inserted + activity).If we look at sayArduino AVR core USBCore.cpp:ISR(USB_GEN_vect)(i.e. the USB interrupt routine run on USB interrupt on AVRs with native USB interface, for example ATmega32u4), the above functionality would be very easy to replicate. As it only supports full speed (12 Mbits/s), the SOF interrupt occurs once every millisecond (when not suspended), WAKEUPI whenever there is USB messages or data transferred, and SUSPI when the controller can be suspended. (At 480 Mbit/s high-speed, SOF would occur at 125µs intervals.) I would use one of the timers and a timer interrupt for the blink interval (at half the interval, toggling the LED at 50% duty cycle), simply because it would be the simplest and easiest way to do it. Essentially, it is just a bit of logic on to of the suspend/wakeup state, plus the "blink afterwards forNseconds".Thus, on some devices, like the card readers and memory sticks I have (but not the ones magic has), and on many USB hub chips like MicrochipUSB251xB, the firmware uses the suspend/wakeup state directly. (Even the hub chips havesomefirmware, although it typically is in ROM and not changeable, with just some configuration data in Flash.) On the others, and on microcontrollers with native USB interfaces, the firmware can implement more complex indicator patterns on top of the suspend/wakeup status, and of course actual data transfers (specifically on the bulk endpoints).One important detail not yet discussed: The USB storage device or card reader does not know the state of the filesystem at all on any point, because it is all controlled by the host operating system. To the device, it is all just unorganised data. Thus, it is impossible to make a reliable indicator on the USB device that would say whether it is safe to detach the device, without interaction with the operating system! On certain common filesystems like FAT and exFAT itmightbe doable in theory, but technically, it is not possible without help from the OS. Fortunately, current operating systems try quite hard to flush modified data to any and all removable filesystems without leaving the removable device idle for more than a fraction of a second, so in practice, it tends to not be a problem: when the activity ceases for at least a second or two, all changesoughtto have been written to the device.

author: amyk
author_rank: Super Contributor
timestamp: August 20, 2024, 02:33:42 am
content: Quote from: Nominal Animal on August 20, 2024, 12:23:31 amI have some old USB drives whose activity light is programmed to stay blinking for ~5s after the last write received on the USB bus - during which it buffers the data and doesn't actually write to flash until almost near the end of that interval, saving the wear of unnecesary erase and write cycles (e.g. if some application decides to do lots of tiny writes over a short time, instead of one big write.) I noticed this because a single sector read causes a brief flash of the LED, while a single sector write makes it stay blinking for 5s. There are also a few large capacitors visible through the transparent case, which I suspect may be to flush the data to flash upon unexpected power loss. Of course these are not very high capacity (the biggest is only 512MB) but they were made at a time when companies cared more about making a good product over absolute profit (SLC flash rated for more TBW than some modern small QLC SSDs, and even after which it'll still retain data for 10 years.)

author: radiolistener
author_rank: Super Contributor
timestamp: August 20, 2024, 11:20:20 am
content: Quote from: magic on August 19, 2024, 08:03:56 amYes, it is possible that it can be controlled with firmware on MCU side and the driver code on PC side don't involved in LED control. But I remember some driver code which controls GPIO LED from driver side... But it also possible that the code that I remember was for Ethernet LED's, unfortunately I don't remember details. I remember it because it allows to implement user defined function for the LED on the driver code from PC side.

author: prabhatkarpe4
author_rank: Contributor
timestamp: August 20, 2024, 11:48:17 am
content: Why don't you share a schematic for this?I need to make this happen using a MOSFET. Is it possible?

author: tooki
author_rank: Super Contributor
timestamp: August 20, 2024, 05:56:01 pm
content: Quote from: prabhatkarpe4 on August 20, 2024, 11:48:17 amIt sounds to me like you don't even understand the discussion that's going on, because if you did, you wouldn't have asked. You've been told repeatedly that it can't be done.Why is it you "need" to make this happen with a MOSFET? Is it a school homework assignment?

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 21, 2024, 04:24:22 am
content: Quote from: radiolistener on August 20, 2024, 11:20:20 amEven in that case, the drivercommunicates with the device firmwareto change the LED. That is, there is no way for the host to control the LED directly, only via the device firmware. Some firmware can simply offer the option for the host to modify the LED states via some kind of control messages, that's all.Compare to for example keyboards, and their Caps Lock and Num Lock LEDs. While the keyboard is in control of these LEDs, it does convey their state changes to the host, and both PS/2 and USB HID have controls so that the host can change the LED state (which naturally also affects the logical Caps Lock/Num Lock states). For USB HID, seeUSB HID Usage Tables(PDF v1.5), LED Page (0x08) for further details.For Ethernet (over USB), see Communications Device Class (CDC, PDF v1.2) Ethernet Control Model (ECM) protocol (currently in ECM120.pdf in the previous ZIP archive). If I recall correctly, it does not have any activity LED controls at all (so those would have to be driver-specific extensions), and the LEDs are fully controlled by the device firmware.Quote from: prabhatkarpe4 on August 20, 2024, 11:48:17 amFor the USB2512B/USB2514B hub based approach via EasyEDA (for manufacturing and assembly at JLCPCB, or PCBWay or similar services), I could; it's just that you don't seem to be genuinely interested in the topic, and only interested in achieving some specific goal which has little or nothing to do with electronics.Like tooki above, I suspect this is purely an assignment you cannot or do not want to do yourself, and are looking for others to do it for you. If you admitted to it, we could help youlearnhow to do it yourself, but we'll never ever do it for you.Quote from: prabhatkarpe4 on August 20, 2024, 11:48:17 amOnly in a half-assed stupid way that only works in specific circumstances, by picking a MOSFET (or a set of MOSFETs for a slightly better but still fakey design) whose gate threshold voltage VGS(th)matches your needs; noting that it isn't actually a threshold per se, but a curve.

author: radiolistener
author_rank: Super Contributor
timestamp: August 21, 2024, 06:37:01 am
content: Quote from: Nominal Animal on August 21, 2024, 04:24:22 amThis is obvious, because LED is connected to MCU. But the main sense here is which code controls the LED state. When LED state is controlled by driver code from PC side, MCU firmware don't control the LED, it just get state from the driver and put it to GPIO.Quote from: Nominal Animal on August 21, 2024, 04:24:22 amAs I remember, for ethernet PHY you can control LED function with configuration and control registers which is available through MDIO bus. It can be configured to disable LED at all, blink automatically or can be controlled directly with register bit states depends on selected mode.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 21, 2024, 07:30:58 am
content: Quote from: radiolistener on August 21, 2024, 06:37:01 amNo, really. The"But the main sense here is which code controls the LED state"is wrong approach in the context of this thread.It is a significant distinction, if we consider the entire model here. (So, please, let's not start discussing what "control" might actually mean to different people.)You see, to allow a host device to control the LED, the firmware must offer a way for the host to control the LED state. The host cannot "take" control over the LED without explicit co-operation from the firmware. The firmware cannot just hand over the LED state to the host, and instead must implement the interface the host can use to set the LED state. For every LED state change the host wants, the firmware must actually perform the change. See?If we then limit to USB, we can clearly check the standards to see that there are no such interfaces for ordinary USB deviceactivity LEDs; definitely not for USB Mass Storage (which includes both memory sticks and media converters). There are for keyboard LEDs, but even those are mostly handled by the keyboard itself, with host only in very specific circumstances, like boot, telling the keyboard to set them to a specific state.Quote from: radiolistener on August 21, 2024, 06:37:01 amNot for USB devices, which is what this thread is about. Please do not expand the topic toallethernet devices or non-USB IC's. (I, too, probably should not have even mentioned PS/2 either, and kept to USB only. Apologies.)The OP is already on a bad track, so it is best to avoid adding to their confusion. In particular, I'm worried they might now be searching for USB MDIO, arriving at TIUSB-2-MDIO, and wondering how they might apply that to solve their problem. They cannot; it is irrelevant to USB, as USB-2-MDIO is just an application one can use with certain microcontrollers to program TI Ethernet PHYs that will be connected to some microcontroller, without having to implement that programming on the microcontroller the PHY will be used with.I don't mean you'rewrongper se, mind you. TheTeensy 4.1development boards I have, do have aTI DP83825i10/100 Ethernet PHY, which does implement the standard LED controls you mentioned (see 7.6.25 on page 62 on the TI DP83825i datasheet). But all that is via the MDIO bus, connecting the PHY to a microcontroller, and has nothing to do with USB. Strictly speaking, though, even here the PHY firmware is in control of the LED state, and only exposes an interface –– the 16-bit LEDCR register at offset 0x18 that a host can read and write, via the MDIO bus –– to change the LED behaviour and state.I understand your idea of focusing on which code decides on the policy of how and when a LED is lit, but it is not appropriate in the context of this thread. Here, the discussion is about detectingactivityand showing activity (or idleness) using a LED. In practice, this always happens at the firmware level on the device. Some devices do expose an interface for the host to control the LED state, but it is limited to specific devices, and very uncommon over USB. Trying to detect activity by examining the USB 2.0 D+ and D- voltages is a crude hack that has a lot of gotchas, including low-speed and full-speed (1 Mbit/s and 12 Mbit/s) having different voltage levels to high-speed (480 Mbit/s). My entire point in this thread has been touse the information the device firmware gives you, instead of trying to do it at some other level of complexity; and it is also the reason for my pushback here, to try and push OP to the right track. Definitely no offense or snarkiness or anything like that meant; and in another context, I'd be happy to discuss various systems programming aspects of LED activity controls as implemented in many Linux-based appliances like routers and NASes –– one of my hobbies is to add nontechnical-end-user friendly displays and indicators to such.

author: radiolistener
author_rank: Super Contributor
timestamp: August 24, 2024, 11:45:41 am
content: Quote from: Nominal Animal on August 21, 2024, 07:30:58 amRaspberry Pi 4 has sdcard controller and green activity LED.The LED is not linked to sdcard controller, it is controlled by software driver on CPU and shows sdcard activity in that way.So, I would not say that it always happens at the firmware level of device controller.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2024, 12:30:08 pm
content: Quote from: radiolistener on August 24, 2024, 11:45:41 am1. That controller has no firmware of its own, unless you consider the kernel driver that. This is common for SDIO devices, including separate chips implementing SD/SDIO/MMC host controllers.2. The SD/SDIO controller on Pi 4 is an integrated peripheral on the Broadcom BCM2711 SoC, and not an USB device. It is essentially the same as similar peripherals common on many microcontrollers.I'm not saying there are no devices that are connected via various buses whose activity LED is controlled by a host; there are, just not USB devices. I am talking about USB devices, because those are the only ones relevant to this discussion. With USB devices, the activity LED is always controlled by the device firmware. That firmware might expose some interface, for example via USB control messages (to endpoint 0), for the host to tell the firmware what state the LED should have, but it is always the USB device firmware that is in control of it: for the LED state to change, the firmware has to perform an action.I don't understand why you insist on confusing the topic by bringing up unrelated devices, as if they somehow magically refute the above.

author: radiolistener
author_rank: Super Contributor
timestamp: August 24, 2024, 03:44:04 pm
content: Quote from: Nominal Animal on August 24, 2024, 12:30:08 pmI remember some USB devices, which LED are controlled by software on PC. They use USB-serial controller inside and as I remember the LED is connected to RTS line which is not used for communication, just to control LED state from PC software side.Quote from: Nominal Animal on August 24, 2024, 12:30:08 pmI also don't understand why do you insist thatallUSB devices have the LED controlled by the controller program and not the host program?Sometimes there is no controller and no firmware at all on USB device, it can be implemented as hardware design for FPGA and don't know how to control the LED, it just loads the word received from the host into GPIO register and that's it. And actual control is performed by software on the host.For example: USB PHY => FPGA => LED on GPIOWhere is firmware and controller here? And who controls the LED state on FPGA GPIO?To be clear: I don't deny that the LED can be controlled by a controller itself, I just saying that this is not the single way how LED can be controlled.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2024, 04:30:44 pm
content: Quote from: radiolistener on August 24, 2024, 03:44:04 pmAgain, that is still controlled by the USB device firmware. The RTS line is not controlled by the host, but by the USB serial device firmware, which allows the host to set that pin state via an USB CDC control message; specifically SetControlLineState (SET_CONTROL_LINE_STATE) message, whose 16-bit value contains the DTR state in the least significant bit, and RTS state in the next bit.The driver does not control the LED state directly. It is the standard USB CDC firmware on the device that responds to the standard SetControlLineState requests by the driver, to set the output signals DTR and RTS to the states the host desires.This is not quibbling. Yes, you can argue that it is the driver that decides what state the LED (or RTS pin state) should have, and that is true. That is just not relevant here. For every state change, it is the USB device firmware that responds to the SetControlLineState request from the host driver, to actually change the state. If the firmware was buggy, there is nothing the host could do to force the LED or RTS pin state to change.There are many microcontrollers with native USB interfaces that can implement that exact same USB CDC interface, including old AVRs like ATmega32u4 and AT90USB1286. Their firmware can implement an activity LED that flickers whenever there is data flowing, but otherwise follows the RTS state, for compatibility with the device you mention. This is at the root of why I claim such activity indicators are controlled by the USB device firmware, and never by the host: the host cannot "grab" control of the LED state or anything else, it can only send control commands/requests that the device firmware acts upon.To draw a direct line from this to the question posed in the thread title: the activity LED is controlled by the firmware on the USB card reader device. Neither USB card readers nor USB mass storage devices have a standard interface for the host to control an activity LED. While the host computer (filesystem driver, specifically) certainly knows when it is communicating with an USB device, we have no standardized interfaces to connect that information to an activity indicator, not even in Linux. So, to add such an indicator to an existing device or a device being designed, the sensible point is at the device firmware or USB interface chip; and lacking that, adding an USB hub with the activity indicator to show when data is flowing between the device and the host through the hub.Imagining ways of having some kind of an activity LED on an USB device that is not controlled by the USB device but by the host is just wrong. They all boil down to control messages from host to device, so cannot solve the problem at hand. At best, discussing such muddles the topic. At worst, it is trolling, just to confuse anyone reading this thread and wanting to find out how such indicator LEDs are implemented in practice. (For USB devices, if you want the host to be able to control a LED, you have to provide an USB control message interface for it. Using USB CDC or HID, there are suitable ones that could be useful, depending on exactly what you need. It is even possible for a single USB device to provide more than one logical device, for example a keyboard device, a mouse device, a touchpad device, and an USB serial (CDC ACM) device. For USB gamepads using native USB HID interface, I like using the USB serial for controlling what keys each gamepad button produces, so that at runtime, I can reconfigure the gamepad for whatever games I want to play.)

author: radiolistener
author_rank: Super Contributor
timestamp: August 24, 2024, 04:44:58 pm
content: Quote from: Nominal Animal on August 24, 2024, 04:30:44 pmI suspect there is no firmware in USB-serial converter, it can be implemented as hardware logic circuit.For example, you can send packet to USB end point and the first bit of each packet will be loaded to GPIO register on FPGA. There is no firmware and no controller, just dumb digital logic circuit with state machine. It just get data from USB packet and put it to GPIO. USB PHY don't know about the LED and FPGA don't know about the LED. Only software on PC side know that specific GPIO of FPGA is connected to the LED and can change its state. So where is firmware controlled LED in this case?Quote from: Nominal Animal on August 24, 2024, 04:30:44 pmThe driver can control LED state directly through USB interface. Why not? I done it many times.If you control the LED with button, it don't means that the LED is controlled by wire. Just because wire is dumb and can't control LED state without external command from the button, it just transfers the command. The same USB bus just transfers the command from software driver on the host. USB is just a channel to transfer some data.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 24, 2024, 05:26:31 pm
content: Quote from: radiolistener on August 24, 2024, 04:44:58 pmNo, it cannot. The simple reason is the complexity of device enumeration, a required step before any data can be transferred between USB standards compliant devices and host.No, USB devices cannot bepassivelike the example you described, because they have to respond to queries from the host before the host can send any data. USB essentially requires a rather complex state machine to work; much more so if you support USB 2.0 High Speed or USB 3 or later SuperSpeed modes.I think you really, really need to go look at theUSB standardsto understand exactly how USB communications work, before you start claiming idiotic things that if you knew the basics of the standard you'd immediately know would not work in practice at all.This has become too ridiculous of a "discussion" to participate any further; it is as if you simply refuse to listen, and spout garbage because you don't want to admit you know nothing of USB.

author: magic
author_rank: Super Contributor
timestamp: August 24, 2024, 05:50:49 pm
content: LOL

author: magic
author_rank: Super Contributor
timestamp: August 24, 2024, 05:55:28 pm
content: Quote from: Nominal Animal on August 24, 2024, 05:26:31 pmTechnically, it should be possible. There is nothing magical about finite state machines or sending canned responses to a dozen predefined descriptor requests. I doubt anyone is doing it this way when an off the shelf MCU core with ROM is just as good and very cheap.editProject idea: build a working USB device out of 74 logic

author: radiolistener
author_rank: Super Contributor
timestamp: August 24, 2024, 06:34:22 pm
content: Quote from: Nominal Animal on August 24, 2024, 05:26:31 pmI'm using FPGA device which processes all USB and Ethernet requests and sends responses with state machine in verilog. It processing requests and keep continuous realtime stream transfer to PC (and it allows to request second realtime stream through another USB endpoint). There is no firmware and no controller. All is done in state machine on verilog, it's not very simple, but at the same time not so hard.For Ethernet it even doing much more, because it implements full UDP stack, include ARP, DHCP and even ICMP protocol handling. All this is done in state machine. No firmware, no controller. And relatively simple.So, I surprised why you think that this is impossible?On the contrary I would say that it will be hard to implement with MCU, because it needs to handle data at very high speed. Simple MCU is unable to send realtime continuous 1 Gbps stream and at the same time handle all requests and send responses.Quote from: magic on August 24, 2024, 05:55:28 pmyes, it is more simple to do slow protocols handlilng on MCU, for example ARP, DHCP, ICMP is ideal for MCU implementation. But if you need to send high speed stream, it requires very fast MCU with communication interfaces which allows to transfer data from FPGA to MCU and back. It add delays, bottlenecks and eats FPGA resources. So, it's more easy to implement it on FPGA with state machine. Yes it will be equals to a large circuit on 74 logic, but since FPGA has enough elements you can use it and there is nothing complicated.You can fit full state machine for UDP stack with ARP, DHCP, ICMP handnling into 2-4 kLE and even less with optimizations. So you can use chip with just 5-10 kLE for this. For example10CL025with 25 kLE can fit into a small USB stick, I have devboard with it and it's size is the same as STM32 bluepill...I don't think that using 4 of 25 kLE is a stopper to implement all this in state machine... This is just 16% of chip resources.There is better way than connecting FPGA to MCU, you can implement your own MCU core in verilog with instruction set optimized for your tasks. But from my point of view, it makes project more complicated and eats more resources than implementing it as state machine.

author: amyk
author_rank: Super Contributor
timestamp: August 25, 2024, 08:14:06 pm
content: Quote from: Nominal Animal on August 24, 2024, 05:26:31 pmNever heard of the infamous FTDI USB-serial converters? The real ones are indeed hard-wired state machines, and many fakes and compatibles use a mask-programmed MCU instead:https://zeptobars.com/en/read/FTDI-FT232RL-real-vs-fake-supereal%20this%20deep-downQuote from: Nominal Animal on August 24, 2024, 05:26:31 pmMaybe you should listen to your own advice.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 26, 2024, 01:37:44 am
content: This last part of the discussion becomes ridiculous as it's clearly just about playing with words. From his replies, which are usually detailed enough not to leave much to interpretation, Nominal was merely pointing out that implementing USB was involved enough that it would require more than just simple logic, which some seem to believe.Now obviously everything can be implemented with FSMs, and FSMs do not need a complete CPU to be implemented. Or general-purpose CPU, I would say. Define what you mean by CPU otherwise, if you remove the "general-purpose" qualifier.Possibly the slightly unfortunate word in Nominal's post(s) was to mention the need for "firmware", which, again, define what "firmware" is - circles back to the above. But probably still a bit unfortunate as it would elicit in most people's mind the idea that it runs on a full-blown CPU.And yes, many USB device interface chips implement what's needed of the USB protocol purely in "hardware" (so from some RTL) and not with a CPU core in the chip. And yes that's just a bunch of FSMs.Not surprised if some vendors of such chips would OTOH implement it using a CPU core of some kind, although I personally don't have evidence for that nor a particular vendor in mind. But if they do this, and place the firmware in some small embedded Flash area (or more likely, OTP, cheaper), that would allow fixing bugs/adding features without having to respin new silicon, which also has its benefits.

author: magic
author_rank: Super Contributor
timestamp: August 26, 2024, 05:27:42 am
content: Quote from: amyk on August 25, 2024, 08:14:06 pmHmm, looks like you are right.Note, however, that the EEPROM appears to be about 1.5Kbits rather than 1K. What are they hiding?(Maybe it isn't enough space for firmware implementing USB state machines on any reasonably general-purpose core.)Quote from: magic on August 24, 2024, 05:55:28 pmI thought about feasibility of that for a few minutes and concluded that USB would be a little annoying. Just at the lowest layers, the whole bit stuffing and two different CRCs would consume a bunch of chips to merely send/receive the raw bitstream on the wire.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 26, 2024, 09:19:03 am
content: Quote from: amyk on August 25, 2024, 08:14:06 pmHard-wired state machine ≠ hardware logic circuit.Define those terms any way you like, but in the context of this discussion, the former requires an IC with the complexity of a microcontroller or an FPGA, and the latter refers to a circuit a hobbyist could put together from standard jelly-bean logic, inferring from the suggested solution related to that post.Fact is, the USB state machine iscomplex. Just look at the image of the genuine FT232RL after etching at Zeptobars: there are thousands of logic gates in it. No matter how you put it, it is not reasonable to call it "hardware logic circuit"; it is integrated logic implementing a rather complex state machine.Quote from: amyk on August 25, 2024, 08:14:06 pmPerhaps you should re-read this thread, and consider whether your "post" is useful to anyone, or are just continuing a play on words because you don't like the facts I'm offering.Quote from: magic on August 24, 2024, 05:55:28 pmTechnically, it should be possible to create an USB controller out of bacteria. However, when you go ask an EE if they're willing to design one for you, they'll laugh you out of the room, or quote a price in the tens of millions. I wonder why is that?I guess they don't know their field, right?We all know the reason isfeasibility. There are no USB to serial converters made out of discrete parts, because it is not feasible: you'd need a crapton of chips, while a single integrated chip in the USD 0.10 - 10.00 range will do the job, depending on the exact type of USB interface you need.The EEPROM/Flash in FTDI USB to Serial chips is to store the configuration information used by the state machine to enumerate the device, plus to configure the endpoints and pin functionality on some of the converters. That alone should tell you the complexity of the state machine; it is just not something you create out of discrete logic, a "hard-wired logic circuit", as is implied by the context of reply #31.Ifyou, magic and amyk, want to interpret terms differently than the context they were used in implies, feel free: but I consider that language wankery, and an utterly stupid pastime.

author: radiolistener
author_rank: Super Contributor
timestamp: August 26, 2024, 11:21:51 am
content: Quote from: magic on August 26, 2024, 05:27:42 amIt uses EEPROM to store USB device descriptors and configuration bits which can be customized by user.Quote from: Nominal Animal on August 26, 2024, 09:19:03 amAM signal modulation also complex. But it doesn't means that it cannot be done without MCU and firmware...It was processed in pure analog circuits for many years even before first CPU/MCU was invented.The same with USB, you can implement it in firmware code for MCU or you can implement it in hardware circuit which don't have CPU/MCU at all and don't have firmware. So, its just incorrect to say that USB logic is always implemented in MCU firmware.But with this terminology we have deviated from the essence. And the essence is who issues the commands to turn on or off the LED. It can be done on any side - from host software, from MCU firmware or from hardware circuit.So, the statement that the LED is always controlled by MCU firmware is broken and incorrect at least in two planes: 1) USB device may not have MCU firmware at all; and 2) The LED may be controlled by host software and USB device may even don't know about the LED, for example it may just map some bit in the packet to corresponding GPIO and that's it.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 26, 2024, 12:51:59 pm
content: Quote from: radiolistener on August 26, 2024, 11:21:51 amFortunately, that's not what I said, nor what I meant. I never even implied that a "MCU" is required for USB.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 thebehaviour, using an abstract programming language.If you disagree with the term, that's fine; English is a wonky language, and not everybody agrees. I base my use of "firmware" on the first use case of the definition atwikipedia, thefirmware wikipedia article, and the definitions ofsoftwareandprogramming language. To me, an ASIC is the compiled result of a programming language (Verilog or VHDL, typically), and thus clearly "firmware".Quote from: radiolistener on August 26, 2024, 11:21:51 amNot in this thread. "Who issues the commands" is irrelevant, because it cannot be tapped into using simple logic or simple circuits.What matters is "Who drives the LED and why". Becausethatis something we can then use, something we can apply to solve the problem at hand: how to implement an activity LED.If we all were to follow your definition of the essence, the answer would be along the lines of "we need to listen to that which issues the commands", which is neither useful nor feasible in practice.If we follow my definition of the essence, we find that we need to either tap into the USB device IC, or we need to add an USB single-port hub between the host and the device, which provides us the activity information.All through this thread, I've been emphasizing that we need to focus on the limited problem set at hand. You've constantly tried to expand it into non-USB devices and generalities. While that in itself is fine, discussing such in this thread will lead OP and others unfamiliar with USB as a bus and interfacing with it, utterly astray.Thatis the reason I object to that.My purpose here is to help those who read this thread with the intent of understanding of how to implement USB activity LEDs, or monitoring USB bus activity; not to quibble about what is theoretically possible (but utterly infeasible in practice), or what happens with other buses.

author: radiolistener
author_rank: Super Contributor
timestamp: August 26, 2024, 01:17:16 pm
content: Quote from: Nominal Animal on August 26, 2024, 12:51:59 pmNo. Programmable logic and behaviour implemented in an FPGA is namedgateware.Thefirmwareterm is used for MCU code.And I don't think that USB IC uses gateware. The gateware may be used at early stage of design for debugging on FPGA, then its converted to specific technology node. But I'm not familiar with die design process, so not sure how this transform is done.Quote from: Nominal Animal on August 26, 2024, 12:51:59 pmNo, there is fundamental difference betweenfirmwareandgateware.Firmwareis machine code for MCU which is usual for programmers who is familiar with classic programming.Whilegatewareis a logic implemented with configurable digital logic gates.Languages for gateware define digital circuits instead of machine code like it happens in language for firmware. And this is fundamental difference. This is why programmers who know how to program in classic programming language but don't familiar with verilog, usually unable to understand how verilog code works, just because they are used how the classic code linked with machine code (firmware) and have no idea what is digital circuit (gateware).Metastability issues which is usual for gateware, but just doesn't exists in firmware is example of such fundamental difference.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 26, 2024, 02:39:59 pm
content: Quote from: radiolistener on August 26, 2024, 01:17:16 pmThat's the first time I've heard the term.There are exactly 27 posts here at EEVBlog forums that mention the term; and 44% of those are your posts (or the match is in text quoted from your post). A couple are just in snippets of code or logs, as part of a filename path.So, forgive me if I don't use the terms you do, those being rather rarely used here, and me not familiar with FPGA development anyway. (I actually don't like jargon much anyway, even in software development or computational materials physics, my "strongest" fields). I see evenwiktionary has a definition, so I guess it is widely used in some circles. If I had known the term, then I would have used "firmware or gateware", and not "firmware". Maybe I was careless, sorry. :'(Like I said, I'm not interested in playing with or arguing about the word definitions. I've explained the context and meaning I've used them. It isyourproblem if you choose to ignore that and apply your own internal definitions instead, and then wonder why others argue with you. Useful and worthwhile communication is an interaction, not a power game or force feeding operation. Language is complex and muddy; it is much more useful to try and concentrate on the ideas and concepts being conveyed, than on words being used ignoring the context. (It's still better than concentrating onwhosays instead ofwhatis being said, though; that being way too common in Western countries today.)As an example, talk aboutvolumewith a DJ, in a hair salon, with a visual artist, or with a scientist. They all define the term in completely different, usually incompatible ways. I do not mind. I prefer to use it in the context, and define the term (even temporarily, for the duration of a single discussion) whenever necessary. I've even discussed the difference between the visual art definition and physical definition with both scientists and artists, simultaneously, because conveying the message and the idea is more important to me than quibbling about the exact definition of a term.

author: radiolistener
author_rank: Super Contributor
timestamp: August 26, 2024, 03:08:15 pm
content: Quote from: Nominal Animal on August 26, 2024, 02:39:59 pmThis is not my term. I'm sure almost anyone who familiar with FPGA development know it very well.But it appears that FPGA development is not popular subject on this forum, so it's not surprise that there is not so much information about it here.This is not surprising, because gateware development is not as popular as software development and there is much less information on this topic, as well as specialists.if you don't believe me, just look for example on CERN site:https://indico.cern.ch/event/1337180/contributions/5629282/attachments/2882918/5051661/ISOTDAQ2024_Advanced_FPGA_Design.pdfQuoteSee page 13 for difference between software/firmware (programming) and gateware design. You are not the first to be surprised by this difference, almost any programmer who has encountered FPGA discovers that there is another world...When you are familiar with classic software/firmware programming it is very difficult to understand the essence of gateware design. That's why there are few programmers who is able to understand Verilog/VHDL.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 26, 2024, 04:03:15 pm
content: Quote from: radiolistener on August 26, 2024, 03:08:15 pmSure –– I did show that it is already defined at e.g. Wiktionary, so it is definitely a known term ––, but outside FPGA developers, it is not a well-known term. Be assured, I do know it now, and won't confuse you or others familiar with FPGA development by mixing the terms.Quote from: radiolistener on August 26, 2024, 03:08:15 pmThat is a rather simplistic/problematic/exaggerated view of programming by Manoel Barros Marin of International School of Trigger and Data Acquisition. (BTW, I've worked for a couple of CERN research partner organizations for a bit, having had a CERN user account and email address for a few years, if that sort of stuff matters to you.)That definition of "programming" does not match reality, you see.It would be more accurate and useful to distinguish betweenimperative programmingand saydeclarative programming. Mind you, even the Wikipedia article oncomputer programmingmakes a similar error (without any references), by talking about "step by step instructions". Such instructions are specific to imperative programming.An example of purely declarative programming is theOpenSCADdeclarative programming language for describing 3Dconstructive solid geometry, often used to describe parametrized objects like gears and such for 3D printing. In particular, it is not executed step by step, but all at once. (To implement animation, the same program is evaluated for each frame, but with different values of built-in variables related to "time".)A third, very useful category of programming isfunctional programming, which evolved fromlambda calculus. It is neither imperative or declarative, exactly; but it is closer to declarative, as it essentially describes the mapping of inputs to outputs using functions (using themathematics definition of a function). With functional programming, even the actual order of operations a computer will perform is utterly unknown to the programmer. It is definitely nothing "step by step".Quote from: radiolistener on August 26, 2024, 03:08:15 pmThere are many worlds beyond imperative programming, which is often the only world most programmers know.I am well aware of the approaches behind Verilog and VHDL, and I can somewhat read Verilog already (although I don't think I've written a line of Verilog yet). (For example, I fully understand the difference between<=and=assignment operators. In Verilog, their effects are quite different from each other.)I just do not consider it different from other forms of "programming"; only different from "imperative programming". To me, it is a fourth class, similar to functional programming in that it is not imperative, is not exactly declarative but close ("declarativestyle", like functional programming); but instead of mapping inputs to outputs using functions, Verilog and VHDL use a more verbose human-readable (non-mathematician readable) form, and terms from electronics (likewirefor example).Considering it completely separate is just tribalist self-aggrandizement; like those who use jargon to bolster their self-image, instead of explaining the terms they use so everybody understands the message. It is concentrating on theappearancesandseparation, instead of focusing on the useful bits.Separating Verilog and VHDL fromimperative programmingis very useful and informative, but there are other forms of programming like functional and declarative programming that are similarly different from imperative programming too, and yet are still considered as part of "programming" nonetheless.

author: radiolistener
author_rank: Super Contributor
timestamp: August 26, 2024, 04:41:01 pm
content: Quote from: Nominal Animal on August 26, 2024, 04:03:15 pmNo. I know many declarative programming languages (like Prolog, Lisp, SQL, XSLT, etc.) and many imperative programming languages (like C#, C/C++, JS, ASM, etc). And understand the difference between them. But I'm talking about different thing.There is a fundamental difference between a programming language for computers (CPU/MCU) and a hardware description language (HDL). The first one is used to write code that is compiled or interpreted into machine code, which is executed by a CPU or MCU. The second one is used to describe digital circuits, including logic gates and their connections. It is incorrect to categorize both as the same type of language just because they both use the word 'language'. Programming languages and hardware description languages serve different purposes and define fundamentally different concepts.To be clear, it's like compare programming language with chemical formula language. These are fundamentally different concepts.Quote from: Nominal Animal on August 26, 2024, 04:03:15 pmPerhaps you only think that you can read verilog code. Even if you understand what means logic operation and what is the difference between <= and =, it still not enough to well understand how verilog code works... Its more easy to understand if you familiar with designing digital circuit schematics, because this is exactly what verilog describes...For comparison any programming language (imperative or declarative, procedural, object oriented, functional, lambda, closures, etc) describesmachine code. And here is fundamental difference with HDL, because it describesdigital circuit, but NOT machine code...

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 26, 2024, 05:20:12 pm
content: Quote from: radiolistener on August 26, 2024, 04:41:01 pmSo, what do you call OpenSCAD or functional programming, then? Not programming?At its very core, how much does it actually matter if the programming language leads to machine code executed by a processor, to a description used to configure an FPGA, or to a description of manufacturing an ASIC?Outside the epoxy-encapsulated circuitry, the observable inputs and outputs behave the exact same way, regardless of the physical implementation (MCU, FPGA, ASIC).You claim it is incorrect to categorize such programming under the same term, because the physical implementation differs. I disagree, because the physical implementation is just not relevant to most use cases. We already agreed that "step by step" is incorrect by definition, because it would exclude functional programming.We do not actually care whether a USB-to-serial converter is an ASIC, an FPGA, or an MCU; we care that it performsaccording to the programmed rules. For USB controllers in particular, that is a rather complex state machine. (Complex as in having many parts. Those parts are individually straightforward, so it is not problematic, just a lot of serious but not-too-difficult work to implement.)I wonder how you'd describe Nadav Rotem's graduate research project, which transpiled C to Verilog for synthesis using LLVM. (SeeRotem-CToVerilog.pdf.) Rememver, Verilog and VHDL are just one approach tologic synthesis. There is absolutely nothing that says that HDLs are the best or the only way to do logic synthesis. There is no technological reason why you could not synthesize C source code (that limits itself to binary inputs and outputs instead of streams) into logic for an FPGA or ASIC. The only reason it is not done in practice, is that it requires a compiler/transpiler that is more work to create than its worth. (Even Nadav Rotem omitted recursion and some imperative control flow constructs.)Thus, because of the above, and especially because transpilers exist between Verilog/VHDL and other programming languages, I claim your (and Manuel Barros Marin's) definition of "programming" and "programming language" as excluding logic synthesis is in fundamental error.If we cannot even agree to definitions of terms for the sake of discussion, how can we interact in a mutually beneficial manner? I suspect it is neither possible, nor useful to try any further, sorry.

author: radiolistener
author_rank: Super Contributor
timestamp: August 26, 2024, 05:39:16 pm
content: Quote from: Nominal Animal on August 26, 2024, 05:20:12 pmI would say this is a kind of software to generate emulators for C code in verilog. Because there is no equivalence between machine code and digital circuit. But you can emulate C code with circuit and vice versa - emulate digital circuit with C code...That tool may be helpful if you don't know verilog and want to generate verilog code which will emulate some C code. But this code will not be effective, it's like running Linux inside virtual machine on Windows... It will works, but not the same effective as Linux running on hardware.

author: xvr
author_rank: Frequent Contributor
timestamp: August 27, 2024, 11:23:37 pm
content: "Hardware Description Language" and "General purpose programming language" are not question of languages themself, but type of its usage. When you writes computer program you describe it in terms of algorithms and sequential execution of them. HDL 'program' describes hardware structure. There is no sequence execution - all performed absolutely in parallel manner.But languages themself could be arbitrary. You can write general purpose program in Verilog or VHDL. Moreover, you will write it when you run your schematic in simulator. You use sequential program to describe test suite. Both Verilog and VHDL has a big part of language that can't be used for RTL description, and it sole purpose in writing sequential tests as in general purpose language. Moreover, when you run such test all your RTL code will be run as general purpose program - it will not be converted into RTL.Another example of HDL - SystemC. This is a HDL language used to create hardware, but internally this is just library and set of macros for generic C++. And any SystemC RTL definition is a valid C++ program. You can synthesize RTL from it or compile and run as C++ program.And the last one - HLS synthesizer in Vivado suite (Xilinx/AMD development system for its FPGA) takes C (or even C++) function and synthesize RTL from it. So arbitrary C/C++ syntheses is not just an academical research, but production grade technology for now.

author: magic
author_rank: Super Contributor
timestamp: August 28, 2024, 05:36:05 am
content: Not gonna participate in a dumb flamewar, butQuote from: Nominal Animal on August 26, 2024, 12:51:59 pmI think most people have a slightly different concept of what "firmware" is

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 28, 2024, 09:44:12 am
content: Quote from: magic on August 28, 2024, 05:36:05 amIf 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 flamewariswhat 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?

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 11:21:14 am
content: Quote from: Nominal Animal on August 28, 2024, 09:44:12 amClassic "firmware" means MCU code which is stored in device read-only memory and implements the main function of the device.Here is definitionfrom dictionary:QuoteBut 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: August 28, 2024, 11:37:04 am
content: Quote from: radiolistener on August 28, 2024, 11:21:14 amI 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 11:46:34 am
content: Quote from: pcprogrammer on August 28, 2024, 11:37:04 amYes, 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: August 28, 2024, 11:57:52 am
content: Quote from: radiolistener on August 28, 2024, 11:46:34 amNope. 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 12:22:29 pm
content: Quote from: pcprogrammer on August 28, 2024, 11:57:52 amIt 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.Quote from: pcprogrammer on August 28, 2024, 11:57:52 amYes, 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 01:11:20 pm
content: Quote from: pcprogrammer on August 28, 2024, 11:57:52 amNo, 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 01:41:57 pm
content: To be short,firmwareis a program for MCU.Gatewareis a configuration bitstream for FPGA.And now I think it's pretty clear that these things are very different.

author: magic
author_rank: Super Contributor
timestamp: August 28, 2024, 04:40:47 pm
content: Quote from: Nominal Animal on August 28, 2024, 09:44:12 amIt'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.Quote from: Nominal Animal on August 28, 2024, 09:44:12 amYou 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.

author: tooki
author_rank: Super Contributor
timestamp: August 28, 2024, 08:25:09 pm
content: Quote from: radiolistener on August 28, 2024, 01:41:57 pmWeeeeeellll……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.)

author: tooki
author_rank: Super Contributor
timestamp: August 28, 2024, 08:52:40 pm
content: Quote from: radiolistener on August 28, 2024, 12:22:29 pmWhile I understand yourlogicin wanting to say that everything done in an FPGA is “emulation”, in that it isn’t hard-wired to do something, that isnothow the term emulation is used in either the electronics or computing worlds. In computing, FPGAs are typicallycontrasted withemulation. 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 youemulatesomething, you don’tbecomeit. So when you emulate one CPU on another CPU in software, the host CPU does things, but it doesn’tbecomethe emulated CPU. In contrast, when an FPGA loads its bitstream containing the CPU core, that part of the FPGA effectivelybecomesthat CPU. Until another bitstream is loaded, those logic cellsarethat 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.Quote from: radiolistener on August 28, 2024, 12:22:29 pm”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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 08:55:42 pm
content: Quote from: tooki on August 28, 2024, 08:25:09 pmGreat explanationQuote from: tooki on August 28, 2024, 08:25:09 pmYes, 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.Quote from: tooki on August 28, 2024, 08:52:40 pmNo. 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.

author: tooki
author_rank: Super Contributor
timestamp: August 28, 2024, 09:06:10 pm
content: Quote from: radiolistener on August 28, 2024, 08:55:42 pmAre yousureyou 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 bitstreambecomesfirmware or software as such!

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 09:21:18 pm
content: Quote from: tooki on August 28, 2024, 09:06:10 pmYes, 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.Quote from: tooki on August 28, 2024, 09:06:10 pmYes, 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...Quote from: tooki on August 28, 2024, 09:06:10 pmYes, 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.

author: tooki
author_rank: Super Contributor
timestamp: August 28, 2024, 09:21:56 pm
content: Quote from: radiolistener on August 28, 2024, 08:55:42 pmPreface 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_prototypingHistorically, it meant in-circuit emulators like the one described in the attached PDF.Those existedentirelybecause of debugging. If you didn’t need debugging, you’d just insert the standard chip!Quote from: radiolistener on August 28, 2024, 08:55:42 pmA 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.

author: tooki
author_rank: Super Contributor
timestamp: August 28, 2024, 09:34:53 pm
content: Quote from: radiolistener on August 28, 2024, 09:21:18 pmOK. 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 thatmostfirmware runs on MCUs andmostsoftware-that-isn’t-firmware runs on CPUs.Quote from: radiolistener on August 28, 2024, 09:21:18 pmI didn’t say anything about firmware or software resources stored within an FPGA bitstream.What I said is:Quote from: tooki on August 28, 2024, 08:25:09 pmThe 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).

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 09:38:19 pm
content: Quote from: tooki on August 28, 2024, 09:21:56 pmNo 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.Quote from: tooki on August 28, 2024, 09:34:53 pmIt 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.

author: tooki
author_rank: Super Contributor
timestamp: August 28, 2024, 10:34:25 pm
content: Quote from: radiolistener on August 28, 2024, 09:38:19 pmAgain, not “emulation”. You’re just going to have to accept that FPGAs are notcalledemulation, 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.