General > General Technical Chat

Resilience of semiconductor supply chains

<< < (7/7)

hans:

--- Quote from: coppice on April 22, 2021, 05:58:07 pm ---
--- Quote from: hans on April 22, 2021, 01:18:17 pm ---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..

--- End quote ---
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.


--- End quote ---

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


--- Quote from: nctnico on April 22, 2021, 04:00:02 pm ---
--- Quote from: hans on April 22, 2021, 01:18:17 pm ---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.

--- End quote ---
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.

--- End quote ---
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.


--- Quote from: coppice on April 22, 2021, 01:09:49 pm ---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.

--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod