Resilience of semiconductor supply chains

[hans]

The 38 microcontrollers in an Audi Q7 come from eight companies, highlighting the complexity of auto supply chains, according to research firm IHS Markit.

I think that must be 38 models of MCU. In a car as complex as a Q7 there should be a lot more MCUs than that. Even low end cars generally have more than 38 MCUs.

I agree. Many sensors can be digital nowadays and each have their own little microcontroller. NXP even makes Cortex-m0 (IIRC) chips that have integrated CAN transceivers. You can hook them straight up to the bus. They are small 48 pin devices, not intended for large ECU's.

How many sensors are there on a modern petrol or diesel engine again? How many cilinders does it have? (each coil may have a uC) What if you need hybrid systems? (charger, motor drive, battery, coupling to transmission systems, + more for redundancy). Mikeselectricstuff did a teardown of a headlamp unit of a BMW. Each headlight unit has a microcontroller .

38 models then starts makes sense.. it quickly adds up.  I would not be surprised in a Mercedes S or Q7 class vehicle, the qty of uCs in the interior already exceeds 38.

Could there be a model like is used for software development with long-term support releases and incremental improvement releases that retain compatibility with the long term support releases? 

For example, would it be possible to have it so that a microcontroller was engineered and steadily improved, but would retain compatibility with earlier models for the lifetime of a microcontroller family?  More advanced microcontrollers would act like earlier models unless their special instructions or registers were invoked to unlock the new behavior.  This is of course done in software, for example, 16-bit real mode on 32-bit and 64-bit Intel processors, for example.

Why can't there be generic pinouts for power converters, where some of the pins would be configured, for example grounded, for the basic model, and as improvements are made, the configurations pins would be changed to enable the new functionality.  Leaving such options in hardware might be a lifesaver at some point because one could substitute a newer part for an older one.

If manufacturers are so eager to have their customers adopt newer silicon, maybe doing it this way would encourage that.

I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4. You 'only' need to replace the board support package of your firmware, however, that is usually substantial effort, or not even possible if manufacturer A has an unique (patented) feature in their uC's. This is even less trivial for automotive or medical, which needs everything automotive certified, reviewed and commissioned..

In addition, the adoption of embedded systems is the race towards smaller designs, lower cost and often also time-to-market. A chip that has more features than necessary is excess luggage that will slow it down. Like @ataradov said; manufacturers are so occupied with low power consumption.

And then I think,  that manufacturers don't like making pin compatible products of their competitors. Namely that can work both ways: you may receive clients from your competitor, but if your company performs badly then chances are that you will directly lose clients. In other words: manufacturers like cash flow and protect it. Preferably you want to keep your clients in your self-designed product prison, often referred to as "the ecosystem". Once in, it must be very hard to break out, as that ensures that the cash flow stays with you. There is no 2nd supplier. There is no drop-in replacement from vendor A or C. Can anybody explain to me how that is an ecosystem? It's not like a bird only eat 1 type of seed. Then it really sounds more like a prison to me..

In similar terms, I really don't understand how manufacturers like Wurth or Samtec can make money. I think their 'ecosystem' are the niche industrial products and/or custom tailored products, which indeed have their place in the market. However, I have also received several consultants over the years and on each occasion they were asking about volume and if we used their connectors/passives. Well.. a 1k resistor stays 1k across all manufacturers. Same for an inductor, LED, pin header, etc. Half of those parts I don't even spec a MPN for. My assembler probably has their own stock.

Going back to the power consumption race of embedded systems: I've heard of a story in which a heart rate sensor for a popular brand smartwatch was redesigned. The digital processing was based on a 8-bit microcontroller design, however, the quiescent power consumption was far too high. They redesigned the firmware and ASIC implementation of said microarchitecture. They went as far as checking which instructions were not used by the firmware and removing those from the ASIC hardware. Those extra instructions may increase switching activity (=power consumption) with 0 extra functionality added. It can then make sense to strip half the ALU if you don't need those operations. In the story I've been told this was a PIC-based microcontroller. I'm not sure where this was produced, but if it was a licensed design then chances are it is also manufactured by Microchip or on the same technology fab/node. Since this was a very high volume product, that could easily add more supply chain pressure.

[nctnico]

I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4.

No. Not by a long shot. Actually, it is complete and utter BS. Embedded software is written in C nowadays which is portable by design. The processor doesn't matter at all. However, switching from an NXP MCU to an ST MCU will be a major pain in the ass. Where NXP has compatible peripherals across the entire range, you'll likely need ST's HAL instead of your own (portable) hardware driver layer. Even if the peripherals are somewhat functionally compatible at all. In the end you'll need to rewrite huge chunks of code either to follow the way ST's HAL works (think about process scheduling!) OR write a huge amount of code to support the various peripherals from ST.

[station240]

Chipageddon strikes: "Jaguar Land Rover to suspend [UK] output due to chip shortage" https://www.bbc.co.uk/news/business-56841946

From above BBC news article

On Wednesday, carmaker Stellantis, which owns the UK Vauxhall brand, said it would replace digital speedometers with more old-fashioned analogue ones in one of its Peugeot models, as the fallout continues.

Well that's one way to solve supply issues.

[coppice]

I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4. You 'only' need to replace the board support package of your firmware, however, that is usually substantial effort, or not even possible if manufacturer A has an unique (patented) feature in their uC's. This is even less trivial for automotive or medical, which needs everything automotive certified, reviewed and commissioned..

I assume you've never worked with an MCU. The thing that makes someone choose a particular MCU is very very seldom the CPU. The CPU is irrelevant in most cases. People write most code in C now, so a change of CPU usually just requires a recompile. Its the peripherals which make one MCU interesting over another in any particular case. Very few MCUs are designed to be general purpose. They are mostly designed with one or two particular applications in mind. If you don't work in those applications you won't spot this. When you do work in those applications you will quickly spot that the MCU was made to keep you happy. Peripheral code, apart from the most basic, is not portable. You will do some extensive recoding if you change them.

The above is really not understood by far too many people in positions of influence, who make a big deal about how wonderfully portable ARM cores can make MCU applications.

[Marco]

I know people in the automotive industry furious at NXP because they cannot fulfill orders for their 32bit MCU's - that were signed contracts well beyond a year in advance.

But what delivery delay are they experiencing? A couple month delivery delay is simply force majeure given disruptions due to severe weather and corona.

If those couple months of force majeure cripple them, that's on them ... shit can happen.

[hans]

I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4. You 'only' need to replace the board support package of your firmware, however, that is usually substantial effort, or not even possible if manufacturer A has an unique (patented) feature in their uC's. This is even less trivial for automotive or medical, which needs everything automotive certified, reviewed and commissioned..

I assume you've never worked with an MCU. The thing that makes someone choose a particular MCU is very very seldom the CPU. The CPU is irrelevant in most cases. People write most code in C now, so a change of CPU usually just requires a recompile. Its the peripherals which make one MCU interesting over another in any particular case. Very few MCUs are designed to be general purpose. They are mostly designed with one or two particular applications in mind. If you don't work in those applications you won't spot this. When you do work in those applications you will quickly spot that the MCU was made to keep you happy. Peripheral code, apart from the most basic, is not portable. You will do some extensive recoding if you change them.

The above is really not understood by far too many people in positions of influence, who make a big deal about how wonderfully portable ARM cores can make MCU applications.

There is no need to make such comments about the person. Anyway:

I think this is one of the major selling points of ARM eco-system; if you have coded your software algorithm to run a NXP Cortex-m4 chip, it will also work on a ST or Microchip Cortex-m4.

No. Not by a long shot. Actually, it is complete and utter BS. Embedded software is written in C nowadays which is portable by design. The processor doesn't matter at all. However, switching from an NXP MCU to an ST MCU will be a major pain in the ass. Where NXP has compatible peripherals across the entire range, you'll likely need ST's HAL instead of your own (portable) hardware driver layer. Even if the peripherals are somewhat functionally compatible at all. In the end you'll need to rewrite huge chunks of code either to follow the way ST's HAL works (think about process scheduling!) OR write a huge amount of code to support the various peripherals from ST.

I'm not talking about hardware peripherals in any of that part. Even more, the next sentence that is cut out of that citation, I explicitly state that porting BSP is a substantial effort, where 'only' is translation for: PITA.

Reread what I've said, closely. In the sentence both of you cited, I'm talking about software algorithms. In my book, an algorithm does not make a program or firmware. I'm taking the Cortex-m4 as a constant and changing the vendor; indicating that a software algorithm written for an m4 chip can be ported across multiple vendors. And although C is portable, it's span is not 100%. Some features are supported by C compilers, such as the transition between cortex- m0/m3 and conditional execution, which can be a huge win for tight conditional code. A FPU can also be a nice to have on a Cortex-m4 chip. However, a cortex-m4 chip also has SIMD, which is great if you need more throughput for integer number crunching, however, you need to manually use these instructions. Inline assembly and/or custom written algorithms in assembly for a particular CPU family then comes to my mind.

Unlike what @copppice claims, some applications absolutely do make use in the amount of CPU horsepower available for an embedded application. If SIMD is giving the application it's final 20% throughput it needs, then that's great. There are many shades of gray between a 4MIPS PIC controller and a 2GHz dual-core Cortex-A9.

In addition, choosing between uA/MHz and throughput can introduce some complicated DSE if you need to optimize for energy efficiency. In rare counter intuitive cases (STM32L0 vs STM32L4 comes to mind), you may actually be better off with a more powerful processor.


@nctnico (below): I will stop commenting after this.
All I can say; you answered your own question. That is exactly my point. If your program is in C/C++ with proper compiler support, you're not core locked. If you are core locked, you're not vendor locked (atleast for ARM CPU's, hopefully soon also RISC V), in theory atleast.
ARM is indeed not somekind of holy grail CPU core that must always be used. However, I think we're in very different fields perhaps focusing on very different things. I'll leave it at that.

[nctnico]

Who cares about the CPU core where it comes to performance? Just get a different microcontroller with a powerful enough CPU core. There is no advantage to sticking to ARM. C is C and if you need performance it is just a matter of spending the money whether the CPU core is MIPS, PowerPC, 68k, whatever. There are optimised (assembler based) libraries available for all CPU cores. Again, your claim doesn't hold up.

[tom66]

Completely impossible to buy Zynq FPGAs now (at least in CLG400 packages.)  Unless you go greymarket.  So I won't be prototyping anything any time soon.

Regarding ARM, there are architectural differences which expose themselves through C.  In the scope project I use many of these tricks, like setting adjacent bits in registers, as ARM can do that with a rotated bit write/clear operation, so one instruction cycle on a register.  Same applies for other numerical operations; adding 1024 is cheap,  for instance, but adding 14,000 is not.   That's important for ISRs.  Then you have the behaviour of NEON - which although some compilers handle well, certain algorithms require careful optimisation.  So it's not true that you can exclusively port over these applications - you need to consider the architecture carefully.

You are confusing supply contracts with orders. Supply contracts, setting prices vs volumes and other parameters, are normally put in place well in advance. The orders, which actually pull in parts at production time, are a whole other thing. Both sides usually try to warn each other about about unexpected changes in demand or capacity, but both sides are also constantly trying to hedge their positions so they don't end up with a pile of stuff they can't use when sales don't follow expectations.

Maybe I didn't use the right term, but the rough idea is that BMW can call up their brake disc supplier can get 10,000 new brake discs in a month or two, as it doesn't take much to resume production.  But getting 10,000 new iMX8 processors for infotainment requires the pipeline to be set up just right and could require six months before the fab is ready to tape out a single part.  So of course when the automakers cancelled all the orders,  they were expecting that they could spin up straight away,  but they forgot that other people filled those slots that they needed.  They expect everyone to run on JIT,  but it doesn't work for semiconductors.  The average semiconductor vendor has about 2.5 months of stock on hand at any one point.  I doubt you could say that for most automotive providers.

[Marco]

Given that NXP isn't getting sued nor is giving any guidance on penalties or lawsuits, I think it's safe to say the problem is entirely with the car industry itself. Force majeure caused delays, car manufacturers had no safety margin for it. Contracting for delivery a year in advance with a boiler plate delivery contract is not securing supply ... if it's not your property in a warehouse, it's not secured.

The NXP CTO at least does seem willing to give interviews, though probably not with the average US media clown hunting for soundbites and controversy. There's nothing to be gained by talking with a hostile interviewer.

[floobydust]

Renesas seems to have an espionage problem or clowns working in the factory:

"UPDATE 7 - Notice Regarding the Semiconductor Manufacturing Factory (Naka Factory) Fire"
[...] today {April 22} confirmed the emission of smoke at 16:29 JST from the power panel of a Rail Guided Vehicle (RGV) located on the basement of the N3 Building (300mm line) of Naka Factory. The smoke was extinguished immediately by Renesas employees after it began. Following the confirmation of the site by the fire department and maintenance of the power panel, which was the cause of the smoke, production has been resumed as of 20:00 JST on the first floor and the second floor of the N3 Building. There are no impacts to the production and shipment outlook announced in “UPDATE 6 - Notice Regarding the Semiconductor Manufacturing Factory (Naka Factory) Fire”. We also confirmed no casualties from this incident."