Are Logic Circuits Still Used or Micros

[bostonman]

I'm uncertain if this question belongs in the Microprocessor section, but it's somewhat simple.

At an old job we had timing circuits that used regular logic gates and flip-flops. Eventually the newer designs incorporated FPGAs and I no longer saw logic circuits. My last few jobs seem to always use micros (i.e. software) to handle the logic now.

Are logic gates being phased out and replaced with micros to save room and money?

[themadhippy]

no,the logic gates just got smaller and loads of em fit in the thing we call a micro.

[bostonman]

Does this mean the days of seeing an array of logic gates and flip flops are ending?

If more logic is being placed into what we call a micro, that means the code will now be dealing with the logic making it harder to repair electronics, correct?

[pcprogrammer]

no,the logic gates just got smaller and loads of em fit in the thing we call a micro.

That is just mean 

It is also what sits at the heart of FPGA's for that matter, but there will always be room for standard logic IC's. Sometimes you just need to invert a signal and with the availability of single gates it is probably cheaper than using a microcontroller. Or you need to shift between voltage levels. Logic IC's come to the rescue.

Does this mean the days of seeing an array of logic gates and flip flops are ending?

If more logic is being placed into what we call a micro, that means the code will now be dealing with the logic making it harder to repair electronics, correct?

Not at all. FPGA's have there niche, as well as logic IC's.

Sure a lot of things can be done with microcontrollers, but there are speed limits.

Edit:

Electronics getting smaller and smaller is what makes repairs more difficult. This is just a continuing line, like TV's used to be based on valves, then transistors, then dedicated IC's, also making it harder to fix a TV, unless a part could be sourced.

With microcontrollers it is the same, but you also need the firmware, which might be more difficult.

[Benta]

I use a lot of standard logic ICs, both for logic, but especially for timing. Mostly 74AC or 74HC, but sometimes also 4xxx series.
CPLD/FPGAs could do it as well, but the problem is that their power consumption is horrendous. The lowest power CPLDs I've managed to find burn 100+ mA, where my standard logic will need less than 5 mA.

[bostonman]

I should clarify "logic" being more at the level of AND, OR, and basic flip flops.

Absolutely correct that sometimes a simple circuit will require a few gates, so a micro (or FPGA) would be a waste of money.

As mentioned, I've seen a shift where it's been years since any circuits at a company I've worked for use logic gates. It makes sense because the things some of the micros use in existing circuits I'm working with would take an array of gates to perform, so I get it, but scary because A: I don't know how to program these micros and B: it's another step towards being unable to repair our own electronics.

[mikeselectricstuff]

Does this mean the days of seeing an array of logic gates and flip flops are ending?

If more logic is being placed into what we call a micro, that means the code will now be dealing with the logic making it harder to repair electronics, correct?

But fewer parts also make things more reliable so less likely to need repair.

[IanB]

In my first job, we had some logic implemented with pneumatic logic gates. It made sense because it was in an environment unfriendly to electronics, there was no need for an electrical power supply, the compressed air to run it was already available in the industrial setting, and the state of the logic was easily observed.

Those conditions that applied then would likely still apply today.

[T3sl4co1l]

Glue logic isn't going anywhere.  There's just less of it used in any given place, compared to the bad old days when you needed, say, whole cards of the damned stuff to accomplish much of anything.

Give or take, if you need more than two or three chips to do the job -- just toss it in a micro, or FPGA.  Occasionally you find an ASIC which does the function as well -- more and more highly-specialized chips appear on the market, day by day.

It's rare that it's economical or otherwise worthwhile to build even a fairly modest function out of hardware logic, let alone because, if you need to make changes coming up to or following release, you're SOL with hardware, but firmware can be updated.

Mind, it may cost more to write that firmware.  If you're doing a few-off sort of thing, and the application is well defined, the break-even point might be more like dozens of chips worth of logic.

Which one, MCU or FPGA, depends on how fast and accurately (mainly in terms of timing) you need the result.  FPGAs are excellent for electronic interfaces and high bandwidth systems; it's nigh impossible to interface even a high-performance MCU to something like a vintage PC or console bus, but trivial for an FPGA.  (Some MCUs do in fact include bus interface hardware, or complex timers, SPI or other peripherals which can be used in these ways.  Some even include whole state machines, like RP2040's PIO.  Or specialized devices with very high granularity per pin or group, like XCore.)  For everything else, the grade of MCU dictates how much processing and bandwidth can be done, within a modest (often poorly defined, due to inconsistent timings: execution path variation, cache stalling, interrupt overhead, etc.) time frame, say µs to ms, and up.  Top-of-the-line CPUs (ARM64, amd64, RISC-V, etc., with zillions of extensions each, and often paired with even more impressive vector-data and array-CPU style GPUs) offer many GFLOPS of performance, even just as a starting point, let alone with all the cores brought to bear (TFLOPS are available!).

I use a lot of standard logic ICs, both for logic, but especially for timing. Mostly 74AC or 74HC, but sometimes also 4xxx series.
CPLD/FPGAs could do it as well, but the problem is that their power consumption is horrendous. The lowest power CPLDs I've managed to find burn 100+ mA, where my standard logic will need less than 5 mA.

AFAIK, CPLDs are obsolete -- give or take exact design and functionality, as there is a lot of overlap with FPGAs, but classics like MAX5k/7k were so ridiculously thirsty due to use of EEPROM programming.  Basically as I understand it, it's NMOS logic, where the logic functions are programmed in via floating gates.  There's no complementary EEPROM (or, it's not worth setting up complements and the programming logic to set them) so it's either off or sinking bias current.  In an E(E)PROM (chip, as such), you only get that current consumption during a read cycle, here it's 100% always-on; ridiculously inefficient.

Modern FPGAs do... other things; what, I'm not up to speed on, but an example is a Flash block off to the side, that's copied into SRAM automatically during startup (which does cost a few ms at power-on, which can be prohibitive in those weird applications when you really do need instant-on function).  AFAIK, external configuration Flash is still very common as well (the chip is read in via SPI or whatever, filling SRAM tables -- LUTs, logic arrays, etc.).

Tim

[pcprogrammer]

Modern FPGAs do... other things; what, I'm not up to speed on, but an example is a Flash block off to the side, that's copied into SRAM automatically during startup (which does cost a few ms at power-on, which can be prohibitive in those weird applications when you really do need instant-on function).  AFAIK, external configuration Flash is still very common as well (the chip is read in via SPI or whatever, filling SRAM tables -- LUTs, logic arrays, etc.).

Yep. Some do have internal flash memory for the configuration but external is most common. With large ones and predefined memory parts the configuration can be very large and take quite a while to load. Also depends on the default speed of the used interface. For most it is possible to do it with a CPU host based on serial or parallel to speed it up a bit, but still.

They are very versatile though.

[tooki]

Are logic gates being phased out and replaced with micros to save room and money?

Let’s take that and replace it with a modified question: Are discrete logic products being phased out?

No. The fact that TI and co continue to release new logic products (like tiny SMD packages containing a single logic gate) and even entirely new logic families (like TI did a few years ago) are a strong indicator that they’re not going away.

Now let’s address the question you probably meant: Are entire circuits made of discrete logic parts going away?

Yes, to a large degree. It’s easier and cheaper to use a MCU or FPGA (depending on the application) most of the time.


So how does one reconcile the seemingly-contradictory answers to these questions? T3sl4co1l already did: glue logic. We aren’t designing entire circuits around discrete logic much, but we use discrete logic to help out here and there. You might need a level shifter or line driver. Or you might need to perform a hardware-level logical operation on some signals (so that they cannot fail due to a software bug, or because they need to be much faster than an MCU, or because the output goes to an MCU pin that isn’t under software control, like a reset line or bootstrapping pin.)

[HwAoRrDk]

I can't speak for industry trends in general, but I was recently working on a design where I was needing some fairly simple gating/latching logic for power switching. I came up with a design using three 74-series logic ICs which would've done the job. But then I realised I can buy a cheap MCU that does it all for the cost of just one of the logic ICs. Sure I now have an extra assembly step of programming the MCU, but that's a trade-off I was willing to make.

[tggzzz]

Does this mean the days of seeing an array of logic gates and flip flops are ending?

No. Just look at distributor cataloges.

Interestingly, logic gates are being split out so there is just one in each package; e.g. see the 74LVC1G* devices. 1G implies 1 gate so a 74LVC1G04 contains a single inverter, or a '00 contains a single 2-input NAND gate.

If more logic is being placed into what we call a micro, that means the code will now be dealing with the logic making it harder to repair electronics, correct?

Yes.

[tggzzz]

In my first job, we had some logic implemented with pneumatic logic gates. It made sense because it was in an environment unfriendly to electronics, there was no need for an electrical power supply, the compressed air to run it was already available in the industrial setting, and the state of the logic was easily observed.

Those conditions that applied then would likely still apply today.

I was once asked whether to replace such (2000psi?) logic with a micro.

Given that the gas was propane on an unmanned offshore oil platform, it seemed to be a difficult proposition

[mikeselectricstuff]

Now let’s address the question you probably meant: Are entire circuits made of discrete logic parts going away?

Not just gone, but long gone, like 20+ years ago. Almost anything that needs more than a few 74 series packages will be simpler, cheaper & more flexible to do with an MCU

[tggzzz]

Now let’s address the question you probably meant:
...

Yes, answering a question is easy.

Asking the right question is more difficult - and more important.

Some of the people I've really respected have the knack of asking a simple question, the answer to which illuminates whole areas of the topic.

For software systems one such question is "what do you mean by identity?", or the very similar "what is the meaning of an address?".
For digital hardware systems, "what are the clock domain boundaries?".

[PCB.Wiz]

Are logic gates being phased out and replaced with micros to save room and money?

Broadly, yes.
Of course, it does need to 'save room and money' which means Logic Gates will never go away entirely.
If you pop over to lcsc and search MCU and Logic, you find higher stocks of logic, focused mainly on single gate parts, with 8 bit shift registers popular too, and analog switches.

I should clarify "logic" being more at the level of AND, OR, and basic flip flops.

Absolutely correct that sometimes a simple circuit will require a few gates, so a micro (or FPGA) would be a waste of money.

As mentioned, I've seen a shift where it's been years since any circuits at a company I've worked for use logic gates.
It makes sense because the things some of the micros use in existing circuits I'm working with would take an array of gates to perform, so I get it,
but scary because
A: I don't know how to program these micros and
B: it's another step towards being unable to repair our own electronics.

A: is easily solved. Learn how to program them
B: has been here a long time already, the very small parts are hard to identify and source.

[Siwastaja]

Large boards full of logic ICs, implementing complex functionality, are gone. Need for some relatively simple glue logic (orring many signals, muxing/demuxing, schmitt triggering, level conversion, bus isolation, ...) hasn't gone anywhere. This is often just 1-2 parts next to a microcontroller.

[artag]

If more logic is being placed into what we call a micro, that means the code will now be dealing with the logic making it harder to repair electronics, correct?

Most manufacturers only care about manufacturing costs, not repair costs.
For some high-value items, repair costs may be important. But repair costs with micros can also be lower - no need to troubleshoot a board full of logic, just replace a subassembly (might be a micro).
Repair costs for someone without access to company information and spares supplies are very unlikely to feature in any manufacturer's decisions.

[bostonman]

Thanks for the feedback and this confirms my observation.

A: is easily solved. Learn how to program them

You're absolutely correct. ST MCUs seem to be popular; unless I'm wrong. Maybe it's time I begin diving into these a bit to learn some of the basic structure.

Replacing an entire board dedicated to logic chips with an MCU makes sense, do get it and understand the cost/space savings. It just upsets me when I want to repair something and see a MCU or EEPROM because I know it can't be replaced if it's suspected bad.

[SiliconWizard]

It depends.

[T3sl4co1l]

MCUs are identifiable; there is a great diversity of them available, but many aren't beyond reach.  The main problem is lack of firmware, and most commercial products will set the lock bits that (nominally) prevent readout.  Even with readout, you only have a binary blob, no debug symbols; reverse engineering is a chore -- but still quite tractable with help of decompilation tools like Ghidra.

There are hackers working on many prominent commercial products; very hit-or-miss of course, mainly when poor behavior, locked or malfunctioning features inspire a user to engage at such length.  This includes unlocking readout, which is often an internal firmware check susceptible to power supply glitching, or with still more investigation, perhaps a zero-day can be found that allows reading out arbitrary memory and thus the entire firmware.  USB and network devices are staples of this, often USB by abusing the descriptor offset/length (it's just copying out some memory somewhere), network by abusing packet sizes, parsing, any manner of web server or other protocol, etc..

Tim

[Alex Eisenhut]

In my first job, we had some logic implemented with pneumatic logic gates. It made sense because it was in an environment unfriendly to electronics, there was no need for an electrical power supply, the compressed air to run it was already available in the industrial setting, and the state of the logic was easily observed.

Those conditions that applied then would likely still apply today.

Fluidics?

[Berni]

Replacing an entire board dedicated to logic chips with an MCU makes sense, do get it and understand the cost/space savings. It just upsets me when I want to repair something and see a MCU or EEPROM because I know it can't be replaced if it's suspected bad.

We already had this as far back as the 1980s. There is plenty of test equipment from that time that is full of EPROMs, ROMs, microprocessors etc.. And i had cases of them failing (tho the awesome people of this forum helped me find a binary image of the chip contents). The difference back then is that microprocessors were awfully expensive (since they were the latest and greatest in chip manufacturing technology) and so only expensive professional equipment could afford to use then inside their BOM.

So cheap consumer products had 2 options:
1) Dumb down the features of the product so much that it is viable to implement in a handful of standard chips.
2) Create a ASIC for the most complicated parts and make sure you are making a product with a large enough market to justify the price of developing the ASIC.

So the result is that the old products are either full of mostly analog circuitry (radios, TVs, toys..etc) or the product is based around a special ASIC that does everything (Calculators, digital watches..etc) and is often encapsulated under a black epoxy glob (since that's cheaper than a chip package)

In these modern times products have gotten so complex that it is infeasible to implement them with standard chips, while at the same time MCUs have gotten so cheap that they are viable for replacing even fairly simple analog circuitry.

Just look around you at various products and imagine implementing them without a MCU somewhere deep in there. Things like TVs, monitors, webcams, USB microphones, bluetooth speakers, wireless game controllers, modems, WiFi routers, induction cookers with capacitive buttons...etc

[bostonman]

Even with readout, you only have a binary blob, no debug symbols; reverse engineering is a chore

Reverse engineering probably isn't a necessity as obtaining the code to burn a new chip in order to replace a suspect failed chip. Maybe I'm wrong, but people are pushing for the "right to repair", however, electronics with programmed chips (whether an EEPROM, MCU, etc...) can't be repaired without obtaining a replacement from the company. In my limited experience, I've never had success purchasing a programmed component from a company. Most times the response I get is to send the unit back for evaluation/repair at a ridiculous cost, no response at all, or some generic response about the apologizing for issues I'm experiencing.

[T3sl4co1l]

Yup, replacement parts are one thing; though if they're obsolete, or customized (e.g. Apple's favorite "take an off the shelf part and increment the number"), you're still SOL, so it's not uncommon -- once thoroughly committed to repairing, modifying or otherwise servicing something -- to need REing.

Tim

[HwAoRrDk]

For repairability I'd say that worse than programmed parts like MCUs are custom parts. You can't buy them, you can't get information on them (datasheets, etc) - you're limited to harvesting donor parts from other units.

[tggzzz]

For repairability I'd say that worse than programmed parts like MCUs are custom parts. You can't buy them, you can't get information on them (datasheets, etc) - you're limited to harvesting donor parts from other units.

I did once manage to repair a blown resistor inside a Tektronix custom IC in a Tek485. Both ends of the resistor were accessible externally, so I simply soldered an SMD resistor nearby

I worked, but the 1ns risetime became 1.25ns

Another time the leads on an HP DIL IC. They had rusted, but I was able to carefully replace them with wire-wrap wire.

But those are definitely very much the exception, of course.

[bostonman]

As I stated, I do get the reason for using MCUs and EEPROMs as a way to reduce cost, size, and I guess reliability.

My initial question did give the wrong impression about whether basic logic gates are going obsolete. Many designs will need a single AND gate (just to use an example) rather than adding an entire MCU to handle a basic single function.

I was also unaware CPLDs aren't popular anymore. Many years ago I took a free day course sponsored by Xilinx as a way to get acquainted with FPGAs since the company I was at began using them in their designs. Around the same time I bought a CPLD and FPGA development board to tinker with (also was able to obtain a "copy" of Xilinx software). If I remember correctly, I played with the FPGA board mainly using the visual logic layout tool rather than learn VHDL. After getting an LED to light when I pushed a switch and getting the light to turn off when I pushed the switch (using an inverting buffer), I lost interest because I already knew digital logic gates, so working on more digital circuits wasn't necessarily an interest.

Either way, the part we agree with is that repairing electronics that have programmed based ICs isn't going to be easy. This forum is great for sharing information, but, if the chips are secured so the programs can't be extracted, even asking someone to extract the program from a working unit will be difficult.

Plus, in my opinion, if say an MCU is the culprit behind a failure, most likely it may be a common failure and the result will be a donor MCU from another unit will fail after time (whether the MCU itself is failing or something is causing it to get damaged).

[Benta]

@bostonman
Let me give you an example (just a part) of one of my designs (see attachment).
It provides trigger signals for the main (mixed-signal) circuit.
It has to provide pulses with a +/-100 ns precision and response to inputs.
First there are two MMVs, which is an analog function, followed by a couple of counters, FFs, demultiplexer etc. In between gates to get it running.
It runs at around 1 MHz and consumes less than 2 mA current at a cost of perhaps $3 (I don't have the latest prices).

Aternative 1: programmable logic. And FPGA would be waaaay overkill, appropriate CPLDs consume over 100 mA (=new power supply = more costs). And how to make the precision MMVs?


Alternative 2: A microcontroller could do the job except it could never meet the 100 ns response rate needed.

If I had to do the design again today (it's around 10 years old), I'd do it exactly the same way.

Yes, standard logic is still needed, and a good way to go in many cases.

[JoeyG]

Micro's with logic blocks.

https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/core-independent-and-analog-peripherals/system-flexibility/configurable-logic-block

[bostonman]

If I had to do the design again today (it's around 10 years old), I'd do it exactly the same way.

That circuit looks great and reminds me of circuits at my old job.

[zilp]

Let me give you an example (just a part) of one of my designs (see attachment).

Are you aware that all the text in that schematic is doubled? Once in "CAD font" and once in some helvetica look-alike. Makes things kinda hard to read ...

(Also, apparently, Libreoffice was involved in producing that PDF?! I use KiCad's print function to print to PDF and haven't seen such behavior before ...)

[Benta]

Are you aware that all the text in that schematic is doubled? Once in "CAD font" and once in some helvetica look-alike. Makes things kinda hard to read ...
(Also, apparently, Libreoffice was involved in producing that PDF?! I use KiCad's print function to print to PDF and haven't seen such behavior before ...)

Ooops. Must have a problem with my PDF setup.
It's a page extracted from a multi-page project, and yes, I cut the page using LibreOffice. But not really an issue, it's not like it's going to be used by anyone, it's just an example.

[Gyro]

It's whatever gets the job done best, where best is the most relevant combination of...

1. BOM cost (at the relevant volume)
2. Board area
3. Ease of manufacture (at the expected volume), including things like programming requirements
4. Cost of manufacture
5. Speed requirements
6. Power limitations
7. Overall product cost implications
8. All the other things I've forgotten!

... Best will vary from product to product. You can't make sweeping statements like micro is better than logic.

[Doctorandus_P]

It's still "whatever fits the job best". The big PCB's full of TTL chips have not been made anymore after the '80-ies. There will still be a market for some "glue logic" in the foreseeable future. Especially for this there are the "single gate" logic chips.

It is also starting to become more common to see a bit of programmable logic inside of small microcontrollers for timing sensitive stuff that can't be done in software.

[zilp]

Ooops. Must have a problem with my PDF setup.
It's a page extracted from a multi-page project, and yes, I cut the page using LibreOffice. But not really an issue, it's not like it's going to be used by anyone, it's just an example.

Haha, IC. I guess pdfseparate (from poppler-utils) would probably be less likely to corrrupt document content ...

[zapta]

CPLD/FPGAs could do it as well, but the problem is that their power consumption is horrendous. The lowest power CPLDs I've managed to find burn 100+ mA, where my standard logic will need less than 5 mA.

For glue logic you may want to look at https://www.mouser.com/datasheet/2/698/REN_SLG46826_ds_3v18_DST_20230226-3075827.pdf , inexpensive, low power, and easy to program, including in-circuit.

[Benta]

For glue logic you may want to look at https://www.mouser.com/datasheet/2/698/REN_SLG46826_ds_3v18_DST_20230226-3075827.pdf , inexpensive, low power, and easy to program, including in-circuit.

Nice part. I like it.
But I wouldn't touch it with a 20-foot pole.

This has to do with the business model behind programmable devices:
They need a software infrastructure. And Renesas is not famous for that.

Looking at the "big two", Altera (Intel) and Xilinx (AMD) they are basically software sompanies.

I've seen too many semiconductor companies trying to make their own programmable stuff, and failing and obsoleting it, that I'll never fall into that trap again.

[bostonman]

How about FPGAs and CPLDs, are they used less often and replaced with micros?

I'm even uncertain whether CPLDs were popular when I was introduced to FPGAs and CPLDs.

[PCB.Wiz]

How about FPGAs and CPLDs, are they used less often and replaced with micros?

I'm even uncertain whether CPLDs were popular when I was introduced to FPGAs and CPLDs.

They all have segments.

CPLD have stagnated. With the exception of SiLego/ Renesas who make wide voltage, simpler CPLD/SPLD, there has been nothing significant new released, and some have gone EOL. (Philips/Xilinx cool runner )

Many MCU now include some config logic, and some FPGA have hard coded MCU,which blurs the lines more.

[bostonman]

My timeline knowledge of all these technologies is skewed.

Around 2001 the company I worked at designed a new board with FPGAs on it. The chips replaced older circuits of similar function that used family logic. My introduction was programming them, but I didn't know anything about them.

When I returned to school, the instructor pushed the class to order FPGA and CPLD evaluation boards. Eventually I obtained a copy of Xlinx and tinkered with some simple logic gate circuits. The circuits weren't as important as understanding how to go from a concept to the FPGA actually programmed. Don't believe I ever did anything with CPLDs though, however, FPGAs were always pushed as the better of the two. At this point I thought FPGAs (and CPLDs) were the future.

Microprocessors were (in my mind) chips that performed math functions and were the heart of the unit taking all the signals from the logic gates.

PICs were also introduced to me in the early 2000s, but I never did anything with them. In my mind these were good for hobby circuits, but not ideal for much else.

Now I'm seeing engineers and circuits that are doing everything in micros, so I'm thinking if I have a desire to learn any logic programming, it should be done with micros. As mentioned already, new circuits exist that will continue using logic gates, others will use PICs, etc... so it's all about size, design, cost, etc...

[Berni]

There is no clear line between a CPLD or FPGA really.

The main difference between them tended to be that CPLDs contain the configuration memory within the logic fabric. So they are meant to be programed once, then instantly on power on they start running the logic. But the more modern 'CPLD' chips are mostly just FPGAs that have some regular flash memory built into one corner of the die, so they boot just the same as a FPGA where on startup the configuration is loaded into the volatile logic fabric.

More modern chip fab processes make placing dense logic and flash memory on the same die harder as they are more optimized for that job, so that's likely why they have a separate area for flash. Or they just remove the flash memory all together and have you put a SPI flash chip next to your FPGA to boot from.

But FPGAs always were and will be for doing niche fast digital tasks. If the job can be done using a MCU it is better to use the MCU. They are simpler, cheaper and easier to develop for. The MCUs have peripherals to do the common tasks, they are also getting faster and faster so they can handle more demanding tasks that involve moving a lot of data. But the niche really fast high bandwidth stuff still needs the performance that only a FPGA or ASIC can provide.

[fourfathom]

Sometimes I will use a tiny single or dual-gate chip even when I have spare I/O on the board controller.  It's often easier or gives better signal integrity that running traces all the way across the PCB.  The same holds for a CPLD (haven't used one of those in a few decades), or an FPGA (do use those when speed requires one).  Use what you need to get the job done.

[Doctorandus_P]

PICs were also introduced to me in the early 2000s, but I never did anything with them. In my mind these were good for hobby circuits, but not ideal for much else.

That is a big misconception. For example PLC's have been microcontrollers with hardened I/O for 40+ years. Modern microcontrollers have more computing power than an 80486, and they do it on the size of a thumbnail and with a handful of milli Amperes.

Microcontrollers are very versatile. They can very easily control things like a washing machine or microwave oven. Do things like keyboard matrix scanning, controlling a display, timing, control some relays.

The cost of small uC's is also negligible. As mentioned earlier, the cost of a uC can be similar to a single TTL IC. The cost is not in the silicon, but in the packaging of the circuit (Stamping a frame for the pins, wire bonding, putting resin, testing, etc). Those steps are very similar regardless of what silicon you put in the IC.

The choice for using an FPGA or a uC is mostly determined by timing. If milliseconds or microseconds is "good enough", then a microcontroller probably works. If you need nanosecond timing, then you likely need an FPGA. (But sometimes you can do fancy programming in a microcontroller peripheral).

[tggzzz]

The choice for using an FPGA or a uC is mostly determined by timing. If milliseconds or microseconds is "good enough", then a microcontroller probably works. If you need nanosecond timing, then you likely need an FPGA. (But sometimes you can do fancy programming in a microcontroller peripheral).

I'll add that timing jitter and predictability are important.

There are many MCUs where "simple" i/o timing can be predicted, but it becomes less easy to guarantee timing when the MCU is doing multiple independent tasks simultaneously. Exception: if you are able to use an MCU that is much more "powerful" than "necessary".

FPGAs can avoid the problem by having many simple processes cooperating with each other; each process is implemented as an FSM. Such processes tend not to contain complex processing.

There is one MCU family which can have multiple complex processes cooperating with each other; each process is implemented as a single core running a single program. Timing and  communication with other processes and peripherals is based on well-designed hardware and complementary language features. (Basically C, minus the features that screw parallelism, plus a few simple concepts that were proven in the 80s and are continually reinvented)

That enables the toolchain (an Eclipse IDE plugin) to accurately predict the min/max program timing before execution. None of this "run, measure, hope you've bumbled across the worst case" crap 

[T3sl4co1l]

PICs were also introduced to me in the early 2000s, but I never did anything with them. In my mind these were good for hobby circuits, but not ideal for much else.

That is a big misconception. PLC's

Huh, did you read that as mixed-case PlC (lowercase L)? Not uppercase I?

I'll add that timing jitter and predictability are important.

There are many MCUs where "simple" i/o timing can be predicted, but it becomes less easy to guarantee timing when the MCU is doing multiple independent tasks simultaneously. Exception: if you are able to use an MCU that is much more "powerful" than "necessary".

Indeed, it's difficult to impossible to put most any MCU onto a vintage parallel bus that it isn't in direct control of; but it can be done, with some difficulty, with a sufficiently powerful platform.  Consider this, using an rPi board:



Even then, it's cheating a bit (relying on consistent timing between accesses, I think it was?).

Which, by extension -- it greatly helps if the timing can be consistent, so that CPU timing/polling loops can be calibrated (if really necessary), timing hardware can be used, buffering, etc.

Platforms with proper parallel/bus interfaces, or configurable hardware IO (rPi Pico PIO a fairly famous current example, though I don't know personally just how expressive it is), can do a lot better, though may still have the problem of overall latency: performing a combinatorial operation between consecutive bus accesses might be trivial from gates (or FPGA by extension), but extremely intensive / painstaking, or impossible outright for sufficiently low latency, if done through a CPU (unless the CPU happens to be very good at that exact type of operation i.e. only needs a few instructions to perform it).

The statistic that interrupt latency hasn't reduced much over the last couple decades is more or less the crux of it; it's better to pipeline and cache performance out of a system, and spread it taller and wider (more and more complex instructions, wider data paths, etc.), than to try and pursue absolute raw clock performance (Pentium 4 syndrome, for a historical example).  You can't make a 8051 run much more than some GHz even on the smallest transistors, but you can pack a hell of a lot more computation into the same clock cycles, and by doing it in far more interesting and effective ways than a kilo-core 8051 at the same clock speed could possibly provide.

Some MCUs do offer quite good interrupt latency, but care (optimization) must be used to preserve it; it's very easy to load up an ISR (let alone a callback...or several!) with crufty overhead, HAL boilerplate, etc., and end up worse than a well-tuned 8-bitter would've been.  (More or less thinking along the lines of Cortex-M cores here.) ...

There is one MCU family which can have multiple complex processes cooperating with each other; each process is implemented as a single core running a single program. Timing and  communication with other processes and peripherals is based on well-designed hardware and complementary language features. (Basically C, minus the features that screw parallelism, plus a few simple concepts that were proven in the 80s and are continually reinvented)

That enables the toolchain (an Eclipse IDE plugin) to accurately predict the min/max program timing before execution. None of this "run, measure, hope you've bumbled across the worst case" crap 

...XCORE being the standout exception, of course

Tim

[tggzzz]

I'll add that timing jitter and predictability are important.

There are many MCUs where "simple" i/o timing can be predicted, but it becomes less easy to guarantee timing when the MCU is doing multiple independent tasks simultaneously. Exception: if you are able to use an MCU that is much more "powerful" than "necessary".

Indeed, it's difficult to impossible to put most any MCU onto a vintage parallel bus that it isn't in direct control of; but it can be done, with some difficulty, with a sufficiently powerful platform.  Consider this, using an rPi board:

Yup, a classic case of gross over-provisioning. Technically unappealing, quite probably commercially appealing

One case where I have idly pondered (no more) using a simple 8-bit Arduino-class MCU is to replace unobtaniuim RAM, to keep a Tek 24x5 running. That RAM is a bit serial 42V(!) EAROM, not the infamous Dallas battery-backed RAM used in the 24x5A and 24x5B. It looks as if it would be possible to ignore the 42V stuff, and tap into the TTL logic on the other side of the level translators. With careful optimisation, bit-banging might just work

Fortunately those EAROMs don't the "Dallas problems", so I'll probably never have to find out.

Even then, it's cheating a bit (relying on consistent timing between accesses, I think it was?).

Which, by extension -- it greatly helps if the timing can be consistent, so that CPU timing/polling loops can be calibrated (if really necessary), timing hardware can be used, buffering, etc.

To get consistent timing, you have to avoid using interrupts and disable all the caches. That removes much of the average performance enhancements you not below.

I wonder whether caches are the source of the twinkling visible on the display?

Platforms with proper parallel/bus interfaces, or configurable hardware IO (rPi Pico PIO a fairly famous current example, though I don't know personally just how expressive it is), can do a lot better, though may still have the problem of overall latency: performing a combinatorial operation between consecutive bus accesses might be trivial from gates (or FPGA by extension), but extremely intensive / painstaking, or impossible outright for sufficiently low latency, if done through a CPU (unless the CPU happens to be very good at that exact type of operation i.e. only needs a few instructions to perform it).

They might or might not (neither do I have any direct experience), but they are a single-point solution. As with all such things:

• is the time/energy spent learning their foibles going to be useful in my future career? (Most things won't, e.g. the many computer languages that are trivial variations on each other)
• they will have brick walls, of course. Can you predict that the brick wall won't be a problem before starting the design?

The statistic that interrupt latency hasn't reduced much over the last couple decades is more or less the crux of it; it's better to pipeline and cache performance out of a system, and spread it taller and wider (more and more complex instructions, wider data paths, etc.), than to try and pursue absolute raw clock performance (Pentium 4 syndrome, for a historical example).  You can't make a 8051 run much more than some GHz even on the smallest transistors, but you can pack a hell of a lot more computation into the same clock cycles, and by doing it in far more interesting and effective ways than a kilo-core 8051 at the same clock speed could possibly provide.

Some MCUs do offer quite good interrupt latency, but care (optimization) must be used to preserve it; it's very easy to load up an ISR (let alone a callback...or several!) with crufty overhead, HAL boilerplate, etc., and end up worse than a well-tuned 8-bitter would've been.  (More or less thinking along the lines of Cortex-M cores here.) ...

Yup.

Interrupt latency is, of course, easy to avoid. All you have to do is avoid interrupts and have the processor sitting in a busyloop until there's something to do. 

There is one MCU family which can have multiple complex processes cooperating with each other; each process is implemented as a single core running a single program. Timing and  communication with other processes and peripherals is based on well-designed hardware and complementary language features. (Basically C, minus the features that screw parallelism, plus a few simple concepts that were proven in the 80s and are continually reinvented)

That enables the toolchain (an Eclipse IDE plugin) to accurately predict the min/max program timing before execution. None of this "run, measure, hope you've bumbled across the worst case" crap 

...XCORE being the standout exception, of course

Yup.

[radar_macgyver]

There are some extremely niche applications where one needs to implement purely combinatorial logic with a very predictable (within a few ns) prop delay. CPLDs can ensure that, FPGAs mostly cannot, unless one resorts to various tricks with constraints and even then there's a fair bit of part-to-part variability. This is so niche that I'm guessing not too many other folks will miss CPLDs. I might have to go back to discrete logic.

The same thing on a coarser time scale applies between FPGAs and micros.

[T3sl4co1l]

Speaking of CPLDs, the major difference AFAIK is about resource allocation/organization.  Think, multiple PLDs in one chip.  Big wide min/max-terms arrays, the usual flip-flops, cascade terms, and one or a couple outputs (complements, cascade, clocked, etc.).

Whereas FPGAs are, more or less the same per cell, except with a tiny LUT instead of an AND/OR array.  Often 4x4, simple RAM lookup, but bigger ones go 6x6 or more.  But rarely the, like, 12x7 or whatever array CPLDs may have.

PLDs in turn, I guess, arise from the input pins; you want to matrix all possible combinations, since it's a small chip, and you can offer some reasonably powerful functions that way.  So, kind of a lot of options, but feasible for just a single chip.  Then, suppose you put a few of them together, well, then you get a CPLD, right? etc.

FPGA interconnects I think tend to be more complex, including crossbar matrices and buffering, and just more routes to choose from, cells to place (including potentially routing through cells to reduce bus contention), etc., which is really where the timing comes in.  Compared to CPLDs, there's just less to route between dozens or hundreds of CPLD cells, vs. thousands in FPGA, but that really just means you have more responsibility to set timing constraints, and less freedom in them (fewer cells, and permutations thereof, in a critical path), but because FPGA cells are faster than PLDs per cell, it's about even either way.

Tim

[tggzzz]

There are some extremely niche applications where one needs to implement purely combinatorial logic with a very predictable (within a few ns) prop delay. CPLDs can ensure that, FPGAs mostly cannot, unless one resorts to various tricks with constraints and even then there's a fair bit of part-to-part variability. This is so niche that I'm guessing not too many other folks will miss CPLDs. I might have to go back to discrete logic.

The same thing on a coarser time scale applies between FPGAs and micros.

The continuum of time scales is, of course, the important point - and there is overlap between MCUs/FPGAs/CPLD/discrete logic.

The XMOS xCORE MCUs uniquely occupy a niche between MCUs and FPGAs, and retain the ease of programming of MCUs with the guaranteed timing of FPGAs.

With any logic, it is preferable to minimise timing dependencies and variations by implementing designs in the form of Moore FSMs. Where that isn't possible, Mealey FSMs can be used. Guaranteeing time relationships can be done by using pre-defined i/o structures, or adding timing constraints and/or nailing down gates into specific LUTs.

Having knowledge beyond any specific technology allows the engineer to choose the appropriate combination of techniques. But you know that

[mikeselectricstuff]

Some MCUs do offer quite good interrupt latency, but care (optimization) must be used to preserve it; it's very easy to load up an ISR (let alone a callback...or several!) with crufty overhead, HAL boilerplate, etc., and end up worse than a well-tuned 8-bitter would've been.  (More or less thinking along the lines of Cortex-M cores here.) ...

ARM has got worse - pre Cortex they had FIQs with a dedicated bank of 8 or so registers, so you could get in and out vary fast, and have dedicated persistant pointers. This was intended a soft DMA replacement, and has roots back to the old 6502 BBC micro where they used NMI interrupts to transfer data from disk and network peripherals. 

Interrupt latency is, of course, easy to avoid. All you have to do is avoid interrupts and have the processor sitting in a busyloop until there's something to do. 

that's very processor dependent - in some cases (e.g. PIC8) an interrupt will have lower, or at least lower maximum, latency than a polling loop. 

[Doctorandus_P]

There was a short period in history where bit banging (low-speed 1.5Mbit/s) USB was a useful thing, and even bit banging 10Mbps Ethernet has been done. But it puts severe limitations on "other things" you want to do with such a system.  These days there are plenty of uC's with build in peripherals for USB or Ethernet. I still use my AVR programmers with the Thomas Fischl library based USBasp software, Analyzing that software may also be a good approach when wanting to learn about low-level USB signaling. (I even got useful data from the USD10 Logic Analyzer and Sigrok / Pulseview for 1.5Mbps USB). But this is mostly a passed by milestone because of the wide availability of uC's with USB or Ethernet.

Recently I put an STM32 on a Logic Analyser and measured the timing between "end of serial communication" and release of the RS485 enable line. I was very surprised that it was some 500ns or so on a 100MHz processor (WeAct Black pill STM32F411CEU6). There were no other ISR's or DMA, and in the assembly generated by GCC, there were at most a few instructions in between. I guess it has something to do with caching, pipeling and synchronization between different clock domains. Such microcontollers also use "flash acelleraotors", which for example reads 128 bits from Flash memory in parallel, and then puts the bytes in the order the processor wants them. There is some weird bit shuffling under the hood, and you don't get the timing you would expect if your experience is based on 20 year old 8-bitters.

Another trend is that multi core processors are getting more common. All the bigger ARM's (used in Linux / Android devices) seem to have smaller processors for house keeping. The Beaglebone (Ti Sittara) has two built in PRU's, which can do things like EtherCAT, which requires very low latency modification of Ethernet packets as they stream by. The Propellor chip is a classic. ESP32 has variants with multiple processor cores, and the RP2040 also has two cores. With a multi core uC, I guess you could one core to bit banging or other low level low latency tasks, while the other does the more computationally based things that disrupt timing (ISR's DMA, task switching, etc).

[tggzzz]

There was a short period in history where bit banging (low-speed 1.5Mbit/s) USB was a useful thing, and even bit banging 10Mbps Ethernet has been done. But it puts severe limitations on "other things" you want to do with such a system. 

I have MCUs that bit-bang high speed USB 2.0; including a debugger, that takes only half the device.  The other half can be used for "applications" with guaranteed timings. Simultaneously, of course. Whether that is a good use of silicon is a separate question. The key point is it is possible.

That MCU can also bit-bang 100Mb/s ethernet. With an MCU that is double the size of the ones I have (available at Digikey!), you could bit-bang both USB and ethernet simultaneously, and still have half the device for your hard realtime application.

Impressive, and it illustrates what can be done if you are prepared to ditch the 1970/80s concept of a microprocessor.

Another trend is that multi core processors are getting more common. All the bigger ARM's (used in Linux / Android devices) seem to have smaller processors for house keeping. The Beaglebone (Ti Sittara) has two built in PRU's, which can do things like EtherCAT, which requires very low latency modification of Ethernet packets as they stream by. The Propellor chip is a classic. ESP32 has variants with multiple processor cores, and the RP2040 also has two cores. With a multi core uC, I guess you could one core to bit banging or other low level low latency tasks, while the other does the more computationally based things that disrupt timing (ISR's DMA, task switching, etc).

Multicore is (finally) the future, due to the stagnation of Dennard scaling. The only problem is programming the damn things. Fortunately techniques and solutions were developed in the 70s and 80s. While there is one commercial solution available, we need more. We also need universities to move beyond teaching undergrads 1970s languages and concepts.

The propeller chip is too weird for my tastes. I like being able to programme in xC - i.e. C minus the mis-features that are traditionally problematic with parallel processing, and plus features that make comms and timed i/o trivial.

[Terry Bites]

A state machine is best implemented in a micro or fpga. But so so boring!
For a simple state machine you may get a speed improvement with discrete logic.
Discrete logic is alive and well.

There are mixed signal interfaces that operate independently of a micro. They can have very low latencies that no micro can compete with.
Glue logic still has a future. The number of available logic parts increases year on year, that tells you something.
You can also use it as a sacrificial buffer against the outside world.
 It might just save your expensive FPGA project from total destruction. A toasted line driver will be a few bucks not a few thousand.
Line and bus drivers and coms interfaces will keep the discrete market going for the foreseeable future.

Dont underestimate the legacy spares and repairs market for transport, aerospace, industrial, ITM and medical etc . Original traceable parts are a must.

[tggzzz]

A state machine is best implemented in a micro or fpga. But so so boring!
For a simple state machine you may get a speed improvement with discrete logic.
Discrete logic is alive and well.

Discrete logic is alive and well, but an FSM is best implemented in the appropriate technology.

I've commercially implemented application level soft real-time FSMs in Java. The entire telecoms messaging systems are defined in terms of FSMs, and nowadays are implemented in software.

Despite it not being obvious, many modern application level frameworks almost require applications using them to be written as FSMs. I'm not sure why it isn't obvious, but it is probably a marketing decision based on the observation that universities churn out softies that think "aren't FSMs something to do with parsers?".

[Njk]

What about a really low power design like watch, speedometer, timer, thermometer, pressure gauge, etc. that is powered by a single alkaline button cell. People are buying that products so the demand is strong and currently an ultra-low-power 4-bit RISC MCUs are available from at least 5 big vendors. But historically, that devices were introduced almost simultaneously with the first MCUs. Definitely they were a custom sets of CMOS gates rather than a processor structures. I don't think mass replacing them with an MCU would result in technical or economic advantage. More transistors, more leakage points

[tggzzz]

What about a really low power design like watch, speedometer, timer, thermometer, pressure gauge, etc. that is powered by a single alkaline button cell.

Hearing aids powered by Zn air cells.

[Tation]

What about a really low power design like watch, speedometer, timer, thermometer, pressure gauge, etc. that is powered by a single alkaline button cell. People are buying that products so the demand is strong and currently an ultra-low-power 4-bit RISC MCUs are available from at least 5 big vendors. But historically, that devices were introduced almost simultaneously with the first MCUs. Definitely they were a custom sets of CMOS gates rather than a processor structures. I don't think mass replacing them with an MCU would result in technical or economic advantage. More transistors, more leakage points

The datasheet of such AS-500 device states a power consumption, in their deepest sleep mode, of 12 uA. There are plenty of 32 bit MCUs, even equipped with FPU, with power consumptions in deep sleep with RTC lower than that by an order of magnitude. Of course, from such 12 uA one must substract consumption from other ICs in the AS500, but 12 uA is, now, not a problem for a modern, low-power, MCU.

[Njk]

The datasheet of such AS-500 device states a power consumption, in their deepest sleep mode, of 12 uA.

I'm not aware of any public data sheet for Assize AS-500 with that specification. If you were able to get it, please share. And I'm not sure about 12 uA. According to my measurement, the minimum operational voltage is 1.2 V (looks like there is a charge pump) and the SR44 button cell I bought more than a year ago is still working. It must be 1.2 uA, not higher. BTW, that correlates with the standby current for a typical 4-bit MCU http://www.tenx.com.tw/product_detail.aspx?ProductID=110, which seems adequate (no FPU is needed)

[Tation]

According to my measurement, the minimum operational voltage is 1.2 V (looks like there is a charge pump) and the SR44 button cell I bought more than a year ago is still working. It must be 1.2 uA, not higher. BTW, that correlates with the standby current for a typical 4-bit MCU http://www.tenx.com.tw/product_detail.aspx?ProductID=110, which seems adequate (no FPU is needed)

From such TM8720 (4 bit, 700 kHz, 2048 B ROM, 32 B RAM) datasheet (-20 ºC ~ 70 ºC, 1.5 V):

• 2 μA typ. HALT mode with 32K oscillator
• 1 μA max. STOP mode

From ST datasheet for STM32L432KC (32 bit, Cortex-M4, SP FPU, 80 MHz, 256 KiB Flash, 64 KiB RAM) (@85 ºC, 3 V):

• 1.1 μA typ. Shutdown mode with RTC and 32 kHz oscillator (can wake from 5 I/O pins, RTC or reset

In deep sleep mode almost all chip is powered down, so not leaking, thus leakage current is not decisive. Cost, area, package, suitability, ability to work from 1.5 V coin cells (such ST part needs a 3 V cell) maybe, but not leakage current.

[PCB.Wiz]

There is one MCU family which can have multiple complex processes cooperating with each other; each process is implemented as a single core running a single program. Timing and  communication with other processes and peripherals is based on well-designed hardware and complementary language features. (Basically C, minus the features that screw parallelism, plus a few simple concepts that were proven in the 80s and are continually reinvented)

That enables the toolchain (an Eclipse IDE plugin) to accurately predict the min/max program timing before execution. None of this "run, measure, hope you've bumbled across the worst case" crap 

...XCORE being the standout exception, of course

.. and Parallax 8 Core parts P1 and P2.
None of those multi-core MCUs are low cost, or low pin counts, but they certainly can do deterministic hard real time stuff.
The P2 has DACs and Timer peripherals on every one of its 64 IO pins.

Sub $1 MCUs now have > 100MHz PLLs for better timing granularity.

[PCB.Wiz]

...
Recently I put an STM32 on a Logic Analyser and measured the timing between "end of serial communication" and release of the RS485 enable line. I was very surprised that it was some 500ns or so on a 100MHz processor (WeAct Black pill STM32F411CEU6). There were no other ISR's or DMA, and in the assembly generated by GCC, there were at most a few instructions in between. I guess it has something to do with caching, pipeling and synchronization between different clock domains.

It's surprising how badly some systems manage RS485 tristate.
TI's has parts with disable monostables, that avoid the need for a third control line, to try to side step this.
I've seen some circuits run RS485 in 'open drain' mode, and others uses a lazy PNP as a disable, which gives a poor man's monostable delay.

Yes, even USB-UARTs can show signs of timing wrinkles in the signal chains, from too many FIFOs etc.
I've measured some with a fixed IIRC 200ns stretch on every STOP pulse and others that have jitter on the STOP pulse width.

The UART operation tolerates that, but if you wanted to do additional features like calibrate or time using the comms link, that's not as easy as it used to be.
Other issues with these 'stretched-STOP' UARTS is checking baud rates with a frequency counter, is no longer simple, and you have not tested your system at a true sustained maximum baud speed.
A change to a 'better' uart, might fail.

[tggzzz]

There is one MCU family which can have multiple complex processes cooperating with each other; each process is implemented as a single core running a single program. Timing and  communication with other processes and peripherals is based on well-designed hardware and complementary language features. (Basically C, minus the features that screw parallelism, plus a few simple concepts that were proven in the 80s and are continually reinvented)

That enables the toolchain (an Eclipse IDE plugin) to accurately predict the min/max program timing before execution. None of this "run, measure, hope you've bumbled across the worst case" crap 

...XCORE being the standout exception, of course

.. and Parallax 8 Core parts P1 and P2.
None of those multi-core MCUs are low cost, or low pin counts, but they certainly can do deterministic hard real time stuff.
The P2 has DACs and Timer peripherals on every one of its 64 IO pins.

I looked at Parallax Propellors a few years ago, and software/programming was the weak point. That's traditional Parallel software concepts are woefully underdeveloped compared with parallel hardware concepts.

At a very quick glance, that still seems to be the case. You program in conventional languages (mostly interpreted?!) or assembler, and we all know how poor those are for multithread/core hardware. The IDE doesn't indicate timings.

The impressive thing about the XMOS stuff is how cleanly and completely the hardware and software concepts are co-designed and tied together both theoretically and practically. Perhaps that's not surprising, since Prof David May first started doing that commercially in the early 1980s.

Corrections with pointers are welcomed. We need more than just the XMOS.

[ArdWar]

It's surprising how badly some systems manage RS485 tristate.
TI's has parts with disable monostables, that avoid the need for a third control line, to try to side step this.
I've seen some circuits run RS485 in 'open drain' mode, and others uses a lazy PNP as a disable, which gives a poor man's monostable delay.

At this point I just assume no one bother properly terminating RS485 anymore.

[Njk]

In deep sleep mode almost all chip is powered down, so not leaking, thus leakage current is not decisive. Cost, area, package, suitability, ability to work from 1.5 V coin cells (such ST part needs a 3 V cell) maybe, but not leakage current.

That's a theory. The reality may be different. The device I'd mentioned costs $3 and it does exactly what I want. With a more powerful HW, there would be WLANs, IP, GPS, NOAA receiver, flashlight, etc., resulting in another gadget for brainwashed kids, where the micro-power requirement is effectively diluted because there is a beefy battery anyway. If it's not a selling point, no one will seriously take care.
At the early LTE times, I was involved in design of a smart phone. So I'm aware of the enormous complexity. It takes a half of business day just to build all the SW from sources. It's a collective effort, multiple separate teams at different locations. Usually, it's much simple to implement a quick and dirty workaround locally than to attempt to identify who's responsible and to convince him to fix the problem (even if everyone is of good will). Especially when you're on a schedule. It's a hopeless situation already.

But it's hard to fool the mother nature. We're in 21-st century, not in 19-th. The question of the century is how to produce less and consume less. It's a fraud to waste the raw materials and energy for fabrication of an overkill hardware for simple applications. To stop the fraudsters is a mandatory item of every great plan.