EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: profdc9 on March 11, 2021, 04:14:28 am
-
As most of you probably know, we are in the midst of a semiconductor shortage due to a number of factors, only some of which relate to the worldwide epidemic.
https://www.washingtonpost.com/technology/2021/03/01/semiconductor-shortage-halts-auto-factories/ (https://www.washingtonpost.com/technology/2021/03/01/semiconductor-shortage-halts-auto-factories/)
In this article it says that:
Car manufacturers began using electronics to control automobiles in the 1970s, replacing older mechanical controls. Gradually, the number of tiny chips known as microcontrollers increased inside cars, powering a wide array of functions, from lights to engine cooling systems.
The 38 microcontrollers in an Audi Q7 come from eight companies, highlighting the complexity of auto supply chains, according to research firm IHS Markit.
Yet because TSMC manufactures nearly three-quarters of all auto microcontrollers, any capacity crunch at the company has ripple effects through the entire auto industry.
Cars are now awesomely complex machines. That there are 38 microcontrollers is not surprising, and the article doesn't say how many of these are the same or difference microcontrollers, only that eight companies provide the microcontrollers necessary to complete an Audi Q7. Furthermore, in the USA auto assembly plants are idle because the silicon is not available to complete the cars.
I guess the question is: do we really need so many specialized parts from so many manufacturers? Of course, this was easier when there were fewer choices available, for example the 8051 was the workhorse of the 1980s. I am not suggesting that we all return to using the 8051 as the lowest common denominator. But aren't microcontrollers supposed to be more general purpose devices with lots of peripherals so that they can be customized for different applications? There doesn't seem to be any attention paid to engineering for resilience or longevity. Perhaps that is because the consumer market can or will not bear those costs.
Like for example, consider a boost converter like the MT3608. There are many similar devices with the same pinout such as HM1549. XR3403, etc. This would suggest that a design with a MT3608 could be robustly supported with substitutes. I realize that the requirements for the automotive industry are much more stringent than a consumer-level Chinese generic boost converter. But is every boost converter really so different that there can't be a few generic types that are commonly used? Just at Texas Instruments alone they list 185 boost converter ICs with integrated switches!
https://www.ti.com/power-management/non-isolated-dc-dc-switching-regulators/step-up-boost/boost-converters-integrated-switch/products.html (https://www.ti.com/power-management/non-isolated-dc-dc-switching-regulators/step-up-boost/boost-converters-integrated-switch/products.html)
It may be a bit unfair to target TI as they also have many legacy products from National Semiconductor and others, and I think it is great that they support so many products. And yes, power efficiency requirements keep increasing, boost converters have to adapt to new kinds of battery chemistries, etc. Still, if the one of the 185 boost converters TI sells is out of stock, and one didn't anticipate and stockpile, you could be SOL.
I don't have an answer for this but I think part of it could be fewer generic, configurable components that have, if possible, generic manufacturers. There used to be 74 TTL/CMOS chips, Z80 processors, op amps like the LM741/NE5532, power regulators such as the LM78xx, LM79xx, TL494, UC384x, standard transistors like the 2N2222, 2N3904, 2N5551, 2N7000, TIP41, TIP42, etc. If you used these parts you can find many sources. Now everyone has their own walled garden of proprietary components. It looks like it is only worth the Chinese semiconductor companies time to make compatible components (assuming they are sufficiently compatible) because they don't have to research new designs.
This problem has been ongoing for quite a while. Perhaps these manufacturers can get together and realize it is in no one's interest if demand falls because factories are idle waiting for parts.
-
The reason we have so many parts that are doing basically the same thing is the need to maintain the parts that are already designed into product, while still innovating.
Chip vendors would be excited to drop 90% of the parts they supply if customers were to move to the new and shiny thing the same year it is introduced. This is not happening though, some commercial products still use 20 year old parts, and manufactures have to ensure continuous supply.
In the old days you had many of fixed function devices. There is not a lot you can innovate on the 74xx logic. 8051 is an architecture, there are a ton of devices using it. Most of them are not compatible on a peripheral level.
In modern days manufacturers competing on shaving uA is current consumption. There is no way they can all come together and design a common architecture. That would be too rigid and hard to innovate, so it would be immediately followed by deviations.
-
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. They did know the parts needed to be made but no decent explanation as to what happened. I wonder if they were worthy of buying Freescale in the first place. Now the MCU's are all zero stock at any distributor and 52+week lead time.
It even was on Jim Cramer, Wall Street is getting annoyed their car stocks are sinking.
"NXP Is Causing 'the Biggest Problem' in Chip Shortage" and he mentioned trying to get the NXP CEO on his show for an interview but no success. I would say there's so many lawyers ready to sue them into oblivion, he would never say a peep.
People are buying semi's from the scalpers even paying 10X price just to keep car production going. The shortage seems to be getting worse from people panic buying.
I suspect geopolitics more than anything. Taiwan is constantly getting buzzed by the chinese military and may be letting the world know how important they are. Now it's water shortages for the fabs, in the news.
-
ST has the same issue with STM32 micro controllers. Lots of them are out of stock and the lead times are skyrocketing.
The whole covid thing probably shaken things up enough to cause a wildly unstable demand for chips, the chip vendors tried to rapidly adjust the production to meet it and got it really wrong. Until eventually warehouse stock of chips started running dry, costumers started to panic about chip availability, started buying up extra chips to make sure they don't run out, making the problem even worse. Ending up with a situation where fabs are still coming back up to speed but demand is at an all time high.
We also had to resort to buying overpriced chips from weird sources. Hopefully the fabs get up to speed soon and sort this out, but my guess is that this will take at least a few months to sort out.
-
How long does it take to switch a fab line to make an existing design? I mean, 52 weeks, that's insane!
-
Long lead time to distributors is partially because all the immediate supply is already assigned to direct customer. But also, it takes a few months to swap fabs. If you cram, you can do it faster, but the risks you take are also high. The actual making of the parts is fast, but characterizing and making sure that they still meet the spec takes time.
-
Yeah thing is those 52 weeks might include switching the fab line to a different chip a few times because they don't have 1 chip out of stock but possibly 100s of partnumbers and not enough fab lines to do them all. Then the big costumers that bought chips directly from the vendor via a big bucks contract might get the first chips that come off that line. Then once DigiKey gets its turn in line, but they might have already sold a bunch of chips to costumers that are backordered, so they will use the first chips they get to finish the backorders. And now finally you are next in line to actually buy a new chip by clicking buy now button on digikey.
-
The thing to understand about cars is that modern car makers produce very little of their car. The majority of it is built by OEMs.
Car makers are very good at packaging the whole system together, which includes systems design and test. And they're very good at making the bodies and the engines. But they're not too good at making radar modules, or ABS controllers. And this is why an Audi Q7 has 38 microcontrollers and quite probably a great deal of those are different, because Bosch makes the radar unit and Continental the ABS controller.
I think you could rationalise a great deal in a modern car but that would require the automakers to go back to producing most of their own kit and for whatever reason they don't want to do that.
Tesla is probably one of the few exceptions, although they still buy in a fair number of parts, I recall reading they have the highest percentage of in-house electronics so they make their own drive inverters, brake/steering controllers, infotainment, etc.
-
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.
-
It dos not matter of new MCU is compatible with the old one. Any substitution triggers a full round of tests for automotive stuff. And you need to make a call whether to just wait for the actual parts, or do the tests and qualify a new part. Those things may take the same amount of time.
-
New NXP supply contracts - they've tripled the MCU prices and added protective clauses :wtf:
NXP will not honour existing supply contracts, even those signed well before the pandemic. They knew the semi's had to be made and failed to manage that.
Ford, GM, Bosch, Continental - I could see them litigating NXP into oblivion. Now you have to play favorites with the limited supply out there.
It just seems like a mafia move because how does jacking up prices do anything within a true shortage?
I've read it's 5 years to build a new fab, from the financing to when product rolls out the doors. Biden's intentions are great but 2026 is long ways away.
-
Continuing
Anyone seen any NXP LPC2388FBD144 ICs? I need some just a few (5-10) but bugger me no one appears to have any. Or give lead time of a year or want you to buy a tray. Im just too small time for that
If anyone has seen any in the wild?
many thanks
-
Already been legal action taken against NXP (it didn't work).
https://www.detroitnews.com/story/business/autos/chrysler/2021/04/16/judge-denies-injunction-nxp-semiconductor-manufacturer-puts-jeep-grand-cherokee-production-jeopardy/7250809002/ (https://www.detroitnews.com/story/business/autos/chrysler/2021/04/16/judge-denies-injunction-nxp-semiconductor-manufacturer-puts-jeep-grand-cherokee-production-jeopardy/7250809002/)
NXP's chips are used in control boards that operate the interior plastics JVIS makes with buttons and nobs that control a vehicle's HVAC system, radio and other functions. The Texas freeze in February, the chipmaker said, cost NXP five weeks of production, and it lost or delayed 700,000 chips.
"While it might theoretically cure a work stoppage for JVIS, it will result in work stoppages potentially for others," Davis said of an injunction during a hearing on the case. "While JVIS says that these semiconductors have been diverted to others, essentially what it is asking since we know that there is a scarcity of these items that two the extent there are some available to others, JVIS says, 'No, give them to me.' Those companies undoubtedly need them just as much as JVIS does."
It's a fine mess, but from what floobydust has said above, NXP have clearly decided the way to decide who misses out is by jacking up the prices.
-
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.
-
New NXP supply contracts - they've tripled the MCU prices and added protective clauses :wtf:
NXP will not honour existing supply contracts, even those signed well before the pandemic. They knew the semi's had to be made and failed to manage that.
Ford, GM, Bosch, Continental - I could see them litigating NXP into oblivion. Now you have to play favorites with the limited supply out there.
It just seems like a mafia move because how does jacking up prices do anything within a true shortage?
IMO, I'd rather be able to buy parts at a higher price, than to not buy them at all. Isn't that just economic supply and demand? We've had prototypes scuppered by the literal inability to buy a part anywhere: if it had to be $25 a part instead of $10, well, at least we can budget for that. We cannot budget for 52 weeks lead time.
The alternative is you either wait for parts on long backorders at list price, or you go to the grey market and buy there at inflated price with no guarantee of quality or authenticity.
NXP is not alone in this. We were offered the privilege of paying Xilinx $5k USD to advance an order of Zynq FPGAs, and even then they would only guarantee delivery by March '22, barely better than Digi-Key's quote.
-
Continuing
Anyone seen any NXP LPC2388FBD144 ICs? I need some just a few (5-10) but bugger me no one appears to have any. Or give lead time of a year or want you to buy a tray. Im just too small time for that
If anyone has seen any in the wild?
many thanks
Ebay or winsource ($60 ea)
-
NXP certainly screwed up, they should not have bought Freescale without knowing how to manage and meet existing automotive contracts, draw-downs, in place well before the pandemic. They knew full well what IC's were needed.
Now everyone cries about the shortage but you have to ask, who is it that allowed the silicon to go elsewhere despite these obligations.
ST is aggressively marketing their automotive MCU's, as a replacement for NXP and I hear many engineers have had it with NXP and this fiasco and want to design them out. The crazy lead-times actually allow you to do a new board and firmware.
I'll check what the ST deliveries are like, but they are going after increasing market share in all this.
-
Thanks very much gents
I've been considering UTSource,,,,I've got mostly good parts from them indeed some very good...I mean how could you fake a LQFP144? Pretty sad when I have to pick thru the rubbish for parts to fix expensive equipment.
The question is is i used one and it was bad,,,,,,,urrrggghh they are not easy re-work...its more protecting the PCB pads,
Many thanks
-
This is the way of things when the world embraces just in time production. The assumption that everyone in the chain of supply/production can do their thing as needed and within a time frame.
-
This is the way of things when the world embraces just in time production. The assumption that everyone in the chain of supply/production can do their thing as needed and within a time frame.
Semiconductors are almost the opposite of JIT. Orders are made many months or years in advance with plans for capacity and expansion.
The problem is the big automakers use JIT, and that's not compatible with stopping production, cancelling orders and then coming back and expecting the supply to return, when that supply has been re-allocated to customers who will not cancel their orders.
-
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.
yep. Even individual sensors have a dedicated MCU (for diagnostic, linearization, protocol communication if it's SENT/LIN/CAN/...)
-
Yeah big automakers love Just In Time delivery.
But it makes sense for car assembly to work that way because the components of a car are so big and the volumes so large that they cant just buy 1/4 of a year worth of parts and keep them in a warehouse next to the factory. Things like car shells, body panels, seats, engines etc take up a lot of room to store and need to be moved around with forklifts. So it makes sense for a lot of these large bulky mechanical components of cars to arrive the same day they are needed and there suppliers understand the importance of keeping to schedule. But its still not like the guys at BMW will call up there supplier and say "Say we need 3000 more of those brake disks, can we get them by tomorrow morning?" They will definitely have the suppliers lines up in advance and confirm that they can supply the number of parts they need on the day they need them.
Chip manufacture is the exact opposite mode of operation. You can easily store 1 000 000 chips on a simple shelf while the production line setup for making one of these is significantly more involved than setting up the manufacture of a typical car part. Not only the making of the actual chip die but also the testing and binning processes that might come after it. Even something as simple as packaging chips can be a complex setup since it is all automated and there are so many chip packages it might have to work with. So it makes sense to set up a chip fab line to crank out a ton of that chip, put them in storage then set up the fab line for the next chip. So things are never made exactly to order. Once the warehouse runs out of a certain chip, it might take a while before that partnumber gets its turn on the production line, especially in these crazy times where the fab line might have a huge backlog of other work.
But really the state of the situation right now is a out of the ordinary event. Nobody would find it sensible to hold this much parts in stock.
-
New NXP supply contracts - they've tripled the MCU prices and added protective clauses :wtf:
NXP will not honour existing supply contracts, even those signed well before the pandemic. They knew the semi's had to be made and failed to manage that.
Nahh. It wil just blow over. TI did something similar a decade ago during the credit-crunch.
-
Chipageddon strikes: "Jaguar Land Rover to suspend [UK] output due to chip shortage" https://www.bbc.co.uk/news/business-56841946 (https://www.bbc.co.uk/news/business-56841946)
-
This is the way of things when the world embraces just in time production. The assumption that everyone in the chain of supply/production can do their thing as needed and within a time frame.
Semiconductors are almost the opposite of JIT. Orders are made many months or years in advance with plans for capacity and expansion.
The problem is the big automakers use JIT, and that's not compatible with stopping production, cancelling orders and then coming back and expecting the supply to return, when that supply has been re-allocated to customers who will not cancel their orders.
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.
-
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 :scared: .
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.
-
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.
-
Chipageddon strikes: "Jaguar Land Rover to suspend [UK] output due to chip shortage" https://www.bbc.co.uk/news/business-56841946 (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.
:-DD Well that's one way to solve supply issues.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (https://www.automotivelogistics.media/digital-technology/chips-will-require-changes-to-the-just-in-time-model/41726.article), 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.
-
Renesas (https://www.renesas.com/us/en) 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 (https://www.renesas.com/us/en/about/press-room/update-6-notice-regarding-semiconductor-manufacturing-factory-naka-factory-fire) - Notice Regarding the Semiconductor Manufacturing Factory (Naka Factory) Fire”. We also confirmed no casualties from this incident."