Are Logic Circuits Still Used or Micros

[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