Are Logic Circuits Still Used or Micros

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