Automotive Chip Shortage is as much about the "type of chips" as it is about overall capacity

[igormp]

5 minutes ago, Dracarris said:

You are way off. Even doing simple calculations takes 100s or 1000s of cycles. Even achieving 5us of precision with a 50MHz clock is very challenging, unless you literally run exactly one task/thread that is not interrupted by anything, which is basically impossible since it needs to handle at least one bus in order to know what to do. Achieving real-time, guaranteed execution on an MCU even at ms granularity is a very challenging task.

Eh, fair enough. I never worked with critical real time scenarios, only those with requirements around the ms range, which was not that challenging as you say (not a walk through the park either, but far from challenging).

 

2 minutes ago, leadeater said:

Thanks, really good explanation. Is there just a single timer for this and things are referenced off the waveform timing or are there multiple timers?

Timers are peripherals, usually a µC will have many of those, some user programmable, others used for other peripherals.

[Dracarris]

2 minutes ago, leadeater said:

Thanks, really good explanation. Is there just a single timer for this and things are referenced off the waveform timing or are there multiple timers?

Well, I am no ECU expert but generally there tend to be multiple timers in an MCU with each having different capabilities and usually multiple channels. You can do very complex things with them, they can e.g., be linked together or triggered through edges appearing on certain I/O pins.

 

Here is for example the block diagram of one of the 4-channel main timers in a STM32F0 MCU, a rather entry-level MCU with up to 48 MHz of clock speed.

 

My guess is that the exact implementation varies a lot from one manufacturer to the next.

[leadeater]

1 minute ago, igormp said:

Timers are peripherals, usually a µC will have many of those, some user programmable, others used for other peripherals.

Yea I was just having a look on Mouser at timers, feel kinda dumb I forgot about these basic timers since I've done a fair bit of electronics in the past lol. Oh well. I was wondering if a single timer is used for all the spark timing or if multiple. Rather late here so thinking is hard.

[RedRound2]

1 hour ago, CarlBar said:

So what exactly was your point. Because at this point i have absolutely no clue whatsoever what point your trying to make here. I'm genuinely completely and utterly confused.

 

The whole thing me and @leadeater are discussing is about the specifics of the the hardware, not the software. Having great software means nothing if your hardware is unstable in the operating environment it has to exist in, because at that point it will start outputting garbage data. 

Simple. I said the software that goes into these ECUs are the kind of software that can run on and Arduino. So given a new processor node, it shouldnt be too hard to rewrite the same damn code (if required) onto the never node/processor.

 

I dotn know why leadeaer went bat shit crazy about arduino and envrionement

1 hour ago, leadeater said:

Well there is your problem with is entire conversation from the start then. I in fact have. The problem is you still think a processor (these are not just processors but ok) can't just be updated but that itself demonstrates a fundamental lack of understanding of how ECUs are actually built.

Apart from claiming the above continously, you havent demonstrated on proved to me why ECUs are complex and hard. Does it contain AI? It was developed in the late 80s and has been refined over the years. You still fail to show how these devices are very complicated

 

Also, ECU was only part of the conversation. What about infortainment? Does that also need some rocket sceince level validation because the music you play might go out of tone?

Quote

You claimed that the testing for it isn't complex and hard yet it is, I've given you one industry standard all vehicle parts suppliers must adhere to as a business to even be allowed to be put in to any car at all. This requires consistent auditing to prove they are meeting the quality control standards required of them, so that includes auditing the test and compliance reports for all parts.

Those tests are for the hundreds of other things in a car as well. Not just ECUs and again from all the reading I've done all they mentioned about electronic equipments are specs, not validation and features. Specs come from factory. And specs like temperature, shock resistance

Quote

As for parts that go anywhere near engines, engine control and fuel systems then they will be certified and tested to ISO 8846, will not be the only one and I'm not expert but I'm also not the one claiming and assuming this stuff is simple to do. On the basis that the vehicle industry is very heavily regulated I assert that it is unlikely.

Again, ISO 8846 is a spec, not a validation. I can order a PCB from any reputable PCB manufacture that adheres to that spec. It's not anything to do with validation. Is there a spec where it says that a new chip needs to be run a minimum of 9600 hours (~4 years, assuming only working hours and days) without any errors? If you show me that, then I'll be proven wrong. All the others stuff you linked are just you trying to deflect

Quote

How about instead you explain how and why you think it is such a simple process to test and certify these devices? You've claimed that it's not hard, shouldn't take long so lets hear what you think the process is.

I dont understand why you need to test engine fuel injection system and timing on a new platform for more than week 24/7 tbh. Or same thing with ABS, transmission control. All of them together with integration tests, a year seems plentiful

1 hour ago, Tenelia said:

if that's the case, 4 years of testing might mean it'd be better for them to prep for something like 7nm, since the rest of the industry would have moved on by then... Right? That'd make it more worthwhile once automakers are ready for production.

I'm not entirely sure what you are trying to say here. But yes, 4 years its frankly sounding more and more stupid as the conversation goes on

[igormp]

5 minutes ago, leadeater said:

Yea I was just having a look on Mouser at timers, feel kinda dumb I forgot about these basic timers since I've done a fair bit of electronics in the past lol. Oh well. I was wondering if a single timer is used for all the spark timing or if multiple. Rather late here so thinking is hard.

I'd say it depends on the implementation, I can see it being done both ways.

[igormp]

1 minute ago, RedRound2 said:

Does it contain some fourier transforms or imaginary number calculations

That's actually pretty common when dealing with signals and systems, specially when dealing with wireless stuff.

I don't get why you are downplaying embedded development this much. I worked on the automotive area before jumping into data, and I guarantee you that developing for a constrained device is way harder than training and deploying ML models.

2 minutes ago, RedRound2 said:

What about infortainment? Does that also need some rocket sceince level validation because the music you play might go out of tone?

The infotainment is the piece that's usually updated every year on cars, they really don't care much about this part lol

[CarlBar]

53 minutes ago, igormp said:

Fixed function hardware is expensive, microcontrollers are cheap. I guess those "dynamic outputs" you mean are just regular analog signals from some sensors, those still need to be read by a microcontroller and sent to the bus.

 

What i mean, (to pick an example i recently read somthing about), fuel flow adjustment to keep the combustion good relies on sensors in the exhaust system. Depending on what readings where and how far off, (and what direction off), they where from ideal it adjusts fuel flow. There's no need to do that in software, it's common to all engines uses the same basic desired result from them all. You just need the sensor outputs in one side, and an output on the other that can handle a value other than on and off, (be that an analog signal or a digital data stream).

 

Fixed function hardware is, (or should), only be expensive if it's somthing that you have to make up for each model of car/engine. If it's somthing that can work across a variety of engines and cars without modification, (or with one or two constants that vary from use-case to use-case. And that can be handled via inputs for those values), it should be cheaper as there's less "silicon" and no software to develop as such.

[RedRound2]

1 hour ago, igormp said:

It does, but it's more related to logistics and business contracts. Again, why would you waste your time testing for a silly small microcontroller (out of 100s) inside a car when you can just revamp most of the platform in the next gen?

Exactly the point. They're sticking to older nodes for cost reasons. They might also just stockpile all of it and keep using the same

1 hour ago, igormp said:

Why should it not be? When you're dealing with something in such scale, spending 6 months more of dev time is worth it when you can shave a couple cents on a microcontroller that will be bought by the millions.

 

Also, most simpler microcontrollers don't even make sense to use a RTOS to begin with. Take for example the rpm sensor or the actuator from an ABS, it's something simple that even an arduino could do, as you said.

 

I can't find a proper source, but I guess this gives a glimpse on the whole idea: https://semiengineering.com/bare-metal-programming/

That makes sense. But it should also be easy enough to write the code, because if it wasn't it wouldnt be written on bare metal for maintainability.

1 hour ago, igormp said:

Some ECUs are new, sure, but remember that there are hundreds of those, and there's no reason to get an all powerful SoC for the ABS system I mentioned above, those are still made with simpler microcontrollers, and those are old and simple because there's no reason to update them.

 

Anyway, tesla did update ~19 of their microcontrollers to avoid the issue some manufacturers are facing:

https://electrek.co/2021/05/03/how-tesla-pivoted-avoid-global-chip-shortage/

https://insideevs.com/news/522749/tesla-replaced-semiconductors-with-microcontrollers/

It was never about power. We could run the same systems in very old tech. Just that we dont need to keep spending money and resources that can better routed to better and newer things. Plus i'd assume it would be more efficient, but that might be miniscule

1 hour ago, igormp said:

Testing out 19 new systems is not an easy feat, and tesla is also not widely known for reliability anyway.

They are not known for relaibility in everything else of a car. Does Tesla's ECU break often? I doubt it. Acceleration, brakes, steering all works as you normally would

1 hour ago, igormp said:

There isn't a "main" software (well, maybe in teslas). It's more like a distributed mess akin to a large k8s deployment. Have a nice slide from a presentation from volvo:

Yeah, by main software i did mean in Teslas. And newer cars as well, that being changed into completely software driven.

Main point being hardware tests are pointless if software tests are ignored

1 hour ago, igormp said:

Eh, might be, but doing such testing and changing the whole production line and whatnot for a single chip sounds cumbersome. Better wait for the new platform anyway.

But given we've had good iPads from like 2012 and still crappy infortainments systems in 2021, they're really not upgrading anything through platform updates

1 hour ago, igormp said:

I'm not sure, but I believe tesla only has a single platform for each of their models, and maybe even some models even share the same platform (which is pretty much the same platform since the model was launched), so that's why they're eager to update small components instead of changing the whole platform (who knows when)

They are actually in the forefront of replacing legacy tech in cars. They switched from Lead acid to Lithium ion 12V battery in the new S and X. And Elon's been talking about changing their low voltage line to 48V for a while now

[RedRound2]

12 minutes ago, igormp said:

That's actually pretty common when dealing with signals and systems, specially when dealing with wireless stuff.

I know it's common in data fusion, signal filtering, wireless, etc. Does ECU do that? As far as my understanding it controls timings and gives signals when it needs to. Again, an Arduino level task

Quote

I don't get why you are downplaying embedded development this much. I worked on the automotive area before jumping into data, and I guarantee you that developing for a constrained device is way harder than training and deploying ML models.

I know first hand embedded systems is pretty difficult. Not downplaying embedded systems in any means, but the ECU functionaity is far from the most complicated systems. If you try to design entire car's intelligence on an embedded system, then this is a whole different story. But i dont think that what happens, bur rather have 100s of small very basic ECUs that all communicate to a main computer (atleast in modern higher end cars and Teslas)

Quote

The infotainment is the piece that's usually updated every year on cars, they really don't care much about this part lol

Exactly, they dont and it sucks. It's just so bad that it doesnt make sense.

[CarlBar]

8 minutes ago, RedRound2 said:

Simple. I said the software that goes into these ECUs are the kind of software that can run on and Arduino. So given a new processor node, it shouldnt be too hard to rewrite the same damn code (if required) onto the never node/processor.

 

I dotn know why leadeaer went bat shit crazy about arduino and envrionement

 

No rewrite will be happening most likely, they will be creating a new architecture using the same programming language. I get the feeling you don't understand the difference between logic layout, a programming language, and a transistor layout.

 

A programming language, or instruction set to get specific is how the fundamental logic is used and accessed by software.

 

The logic Layout or architecture is how all of the transistors are connected to create a functioning logical device. The form of this is constrained but not dictated by the instruction set. This is a theoretical construct only. So long as everything connected where it should be and nothing is connected where it shouldn't it can be laid out in the physical world in any way you please.

 

The transistor layout is how the transistors are positioned on a physichial piece of silicon and where the interconnects run in relation to each other to achieve all the connections, (and only those connections), specified in the logical layout.

 

 

 

The Instruction set likely won't change. the logical layout may change, (or it may remain the same), the transistor layout must change with a node change.

 

 

16 minutes ago, RedRound2 said:

I can order a PCB from any reputable PCB manufacture that adheres to that spec.

 

Not on the smaller nodes beings discussed you can't. No ones created one on hose nodes and done the validation to confirm it meets the specification yet. If you want on on a smaller node your going to have to pay some silicon manufacturer to create and validate it and that takes time.

 

[leadeater]

40 minutes ago, RedRound2 said:

Apart from claiming the above continously, you havent demonstrated on proved to me why ECUs are complex and hard. Does it contain AI? Does it contain ML? Does it contain some fourier transforms or imaginary number calculations with plotting techniques? It was developed in the late 80s and has been refined over the years. You still fail to show how these devices are very complicated

 

Also, ECU was only part of the conversation. What about infortainment? Does that also need some rocket sceince level validation because the music you play might go out of tone?

You are confusing the conversation again. You claimed the testing wasn't complicated, I said it most likely is because of the amount of tests that have to be carried out for each time in each condition. I'm in no way attempting to prove that an ECU itself is hard, the conversation is about the compliance and quality assurance testing.

 

If you take an ECU, isolate just the microprocessor on it and update it from 90nm to 28nm then because you have updated a part within the ECU you have to test the entire ECU again. Assuming that just because you only updated the microprocessor nothing should change and therefore no problems should exist in not the same thing as proving it which would need to do to comply with IATF 16949. You have to take this new ECU revision through all the testing and get it certified for use because it's a new revision.

 

You're conflating complexity of the software, or the design of the hardware, that runs on these ECUs with the complexity requirements of certifying the device. The process involved to prove something is reliable and functions as expected even in a basic system isn't quick. This is the reason car markers don't like to make new revisions of parts because it has to be tested and certified again which costs money, a large part of the cost is time.

 

40 minutes ago, RedRound2 said:

Again, ISO 8846 is a spec, not a validation.

You have to test a device/design to label is as ISO 88846 complaint. Are you being purposefully obtuse? Or do you think "trust me bro" is acceptable amount of testing?

 

Quote

Describes test methods and requirements for the design of electrical devices to be used on small craft so that they may be operated in an explosive atmosphere without igniting surrounding flammable gases.

The standard literally has test methods in it.

 

40 minutes ago, RedRound2 said:

I dont understand why you need to test engine fuel injection system and timing on a new platform for more than week 24/7 tbh. Or same thing with ABS, transmission control. All of them together with integration tests, a year seems plentiful

A week? Damn that's some faith in reliability confidence there. A new ECU revision would be certified with a year though yes, that is most likely true. That doesn't mean any of the car makers want to spend the money updating it in the first place though.

 

Anyway even something as basic as an EEPROM goes through around a million or more cumulative device hours of testing. This is of course done in parallel with multiple devices and groups being tested in different conditions, a single ECU isn't going to be tested for 121 years heh.

 

How else do you think MTBF is calculated? It's not just random guessing.

[leadeater]

28 minutes ago, RedRound2 said:

Simple. I said the software that goes into these ECUs are the kind of software that can run on and Arduino. So given a new processor node, it shouldnt be too hard to rewrite the same damn code (if required) onto the never node/processor.

 

I dotn know why leadeaer went bat shit crazy about arduino and envrionement

Because it's literally completely irrelevant if in the real world the Arduino starts outputting data values, after your error catching code!, completely out of wack because it's too cold or what ever. Why does this matter? Because the conversion was about testing the device! You know, so you know it's actually safe to put in the car and use it and it won't destroy the engine because it doesn't like Canadian winters or been driven through the desert for 6 hours.

 

We're talking about devices, this is what the topic is about, actual hardware and the process nodes used to make them. If you change the process node used then update the ECU design you then have to test it even if literally nothing else was changed. Something you seem fully unware of.

 

You're point about the software is actually irrelevant, why do you think I barely addressed it at all.

[igormp]

11 minutes ago, RedRound2 said:

That makes sense. But it should also be easy enough to write the code, because if it wasn't it wouldnt be written on bare metal for maintainability.

Maintainability is not a thing here. You write code once and it lives like that forever. Don't it of it as your regular web-dev job were you can iterate many times on and go full agile and whatnot, this is entirely different.

13 minutes ago, RedRound2 said:

Does Tesla's ECU break often? I doubt it. Acceleration, brakes, steering all works as you normally would

And those are the components that are likely done with the good old parts

14 minutes ago, RedRound2 said:

But given we've had good iPads from like 2012 and still crappy infortainments systems in 2021, they're really not upgrading anything through platform updates

A high end car usually has a nice infotainment system. And you still have modern tablets that perform worse than an iPad from 2012, there's not really much to talk about here.

 

8 minutes ago, RedRound2 said:

I know it's common in data fusion, signal filtering, wireless, etc. Does ECU do that? As far as my understanding it controls timings and gives signals when it needs to. Again, an Arduino level task

As you said yourself, ECU can stand for electronic control unit, which there are hundreds of those. While some do basically arduino level tasks, some do handle more fancy stuff.

12 minutes ago, RedRound2 said:

bur rather have 100s of small very basic ECUs that all communicate to a main computer (atleast in modern higher end cars and Teslas)

I guess you can imagine how hard is to have 100s of microservices under k8s and try to coordinate those. Now try to imagine the same thing, but in a scenario where you can't update the software at all, and you could kill a person if one single component misbehaves, saturates the communication bus and makes things go haywire.

14 minutes ago, RedRound2 said:

Exactly, they dont and it sucks. It's just so bad that it doesnt make sense.

You can always pay more and get some of the good stuff 

The infotainment in high end audis, and even some GM cars is pretty good IMO. The stellantis group used to have AWFUL infotainment systems (with shitty resistive touch screens even!!), but their latest revision are okaish.

 

[igormp]

1 minute ago, leadeater said:

If you change the process node used then update the ECU design you then have to test it even if literally nothing else was changed. Something you seem fully unware of.

And by "it" it's not only the ECU itself, but also how it behaves on the system with the other 100s of components.

[CarlBar]

1 minute ago, igormp said:

And by "it" it's not only the ECU itself, but also how it behaves on the system with the other 100s of components.

 

This too, even if you could get all of the ECU's a pre-made parts on the smaller nodes allready validated to spec, you also then have to validate that when all of them are assembled into a final combined configuration they remain in spec. This covers both interconnect issues, but also such seemingly trivial things as confirming that all of your mounting arrangements don't result in unexpected out of rnage temperature/vibration/shock load/other spec elements being outsides the rated specification.

 

Getting the individual components is just one part of the trouble.

[CarlBar]

17 minutes ago, igormp said:

Maintainability is not a thing here. You write code once and it lives like that forever. Don't it of it as your regular web-dev job were you can iterate many times on and go full agile and whatnot, this is entirely different.

 

Reminds me of a little rhyme i saw the other week in YouTube comment:

 

"99 little bugs in the code,

99 little bugs in the code.

Take one down,

patch it around,

117 little bugs in the code."

 

Not a situation you can afford in anything safety critical.

[GDRRiley]

3 hours ago, Kisai said:

 since the 80's, pretty much all cars have been "platform"'s, like Product X from GM, Product Y from Buick, Product Z from Cadillac, etc are exactly the same car other than the actual materials and engine choice. One classic example of this is the difference between a Lexus and a Toyota, where counterfeit Lexus LS/ES cars are literately just the Toyota Camry model rebadged (you can literately buy kits to do this.)

 

I’m well aware. My moms car a Chevy traverse, also gets badged as a GMC and a Buick. Same common issues and if you pulled the badges off you’d never know which was which externally. 

[RedRound2]

1 hour ago, CarlBar said:

No rewrite will be happening most likely, they will be creating a new architecture using the same programming language. I get the feeling you don't understand the difference between logic layout, a programming language, and a transistor layout.

 

A programming language, or instruction set to get specific is how the fundamental logic is used and accessed by software.

 

The logic Layout or architecture is how all of the transistors are connected to create a functioning logical device. The form of this is constrained but not dictated by the instruction set. This is a theoretical construct only. So long as everything connected where it should be and nothing is connected where it shouldn't it can be laid out in the physical world in any way you please.

 

The transistor layout is how the transistors are positioned on a physichial piece of silicon and where the interconnects run in relation to each other to achieve all the connections, (and only those connections), specified in the logical layout.

 

The Instruction set likely won't change. the logical layout may change, (or it may remain the same), the transistor layout must change with a node change.

 

Not on the smaller nodes beings discussed you can't. No ones created one on hose nodes and done the validation to confirm it meets the specification yet. If you want on on a smaller node your going to have to pay some silicon manufacturer to create and validate it and that takes time.

 

I'm sorry. Which car companies designs and makes custom silicon for bare metal programming?

 

All of these processors, nodes, architectures are all already produced by Nvidia, Texas Instruments, etc and companies like Bosch, continental also probably have complete ECUs with newer versions of chips as well. You could forgo Bosch for off shelf to reduce costs, but the chips are not custom made for each car.

 

A lot of the validation test all you guys are talking about is done at the foundry itself. They dont exactly just take a knife, cut up the wafers and fedex overnight to the car manufacturing plant

1 hour ago, leadeater said:

You have to test a device/design to label is as ISO 88846 complaint. Are you being purposefully obtuse? Or do you think "trust me bro" is acceptable amount of testing?

The standard literally has test methods in it.

I'm just going to ignore whatever you wrote about the arduino-envrionement, because it's basically goes back to the same damn conversation that happened 3-4 replies back.

Does any of those test methods require 9600 hours to be logged. Those "tests" you refer to are more on the lines of operating the device in a flammable envrionemnt. Again these kind of hardening is done from the fab itself. The vehicle manufacture doesnt coat it with pixie dust to get it certified

1 hour ago, leadeater said:

A week? Damn that's some faith in reliability confidence there. A new ECU revision would be certified with a year though yes, that is most likely true. That doesn't mean any of the car makers want to spend the money updating it in the first place though.

So we're back to square 1 and my original conclusion of the topic. Nobody wants to spend money updating their chips. And that is why we are wasting resources that could be better directed and the reason we're stuck with decade old smartphone and tablet performance in cars. Because

 

if it aint broke dont fix it. And I still feel, if it wasn't for Tesla, we would have still had absolute garbage infotainment system in most cars

 

[RedRound2]

1 hour ago, igormp said:

Maintainability is not a thing here. You write code once and it lives like that forever. Don't it of it as your regular web-dev job were you can iterate many times on and go full agile and whatnot, this is entirely different.

But maintainability is required while updating systems and changing platforms. Or to add new features or data inputs or make things more efficient. We're all going through this with a lot of assumption that bare metal programming and hardware laying out transsitors is the case. It doesn't really make too much sense to go this route because car is not a super critical systgem where every micro second of efficiency matters

1 hour ago, igormp said:

And those are the components that are likely done with the good old parts

This is roundabout argument. You just said Teslas updated many of their ECUs to newer nodes and that's why it's not know for reliability. I pointed out that their reliability issues lies in other aspects of their cars. And then you're back saying that's they are relaible.

1 hour ago, igormp said:

A high end car usually has a nice infotainment system. And you still have modern tablets that perform worse than an iPad from 2012, there's not really much to talk about here.

Except it doesnt take a high end car to have good infotainment system. Give it to me as $329 upgrade on a $5000 car, I'll take it.

And besides, I did drive in E class Mercedes Benz recently. It's not super great and swiping the screen is just terrible. I think the screen is 30Hz. And that's considered fairly high end vehicle.

1 hour ago, igormp said:

As you said yourself, ECU can stand for electronic control unit, which there are hundreds of those. While some do basically arduino level tasks, some do handle more fancy stuff.

I guess you can imagine how hard is to have 100s of microservices under k8s and try to coordinate those. Now try to imagine the same thing, but in a scenario where you can't update the software at all, and you could kill a person if one single component misbehaves, saturates the communication bus and makes things go haywire.

You can always pay more and get some of the good stuff 

But the architecture, communication protocols and timings are set in stone. I never asked to revamp the entire CAN bus. Just to change their chips and program them to do the same exact thing as what the older one did before

1 hour ago, igormp said:

The infotainment in high end audis, and even some GM cars is pretty good IMO. The stellantis group used to have AWFUL infotainment systems (with shitty resistive touch screens even!!), but their latest revision are okaish.

The only one that impressed me recently was the Hummer EV one. That looked really cool.

[leadeater]

1 hour ago, RedRound2 said:

Again these kind of hardening is done from the fab itself. The vehicle manufacture doesnt coat it with pixie dust to get it certified

The processor isn't the problem, it's not the only thing that gets tested and certified. You think just because say TSMC makes a chip and packages in to an BGA device and gives it an operating range of -40C to 120C that the rest of the ECU doesn't need to be designed and capable of the same thing to? I'm trying really hard not to call your mental capacity in to question but you are making it very difficult.

 

If you change out the processor in the ECU you MUST do all this testing again. "I only node shrunk the design therefore I do not need to retest" <- not a thing.

 

You're literally not even in the right ballpark to where the issues is and what needs testing.

 

Of course the fab validated and bins their chips, that's also irrelevant to the testing of the ECU itself. Do you understand product testing at all? That would be relevant to the product design and parts selection.

 

Your argument is literally TSMC has validated the chip so the car doesn't need to be crash tested, yes this is an absurd point because so is yours.

 

1 hour ago, RedRound2 said:

I'm just going to ignore whatever you wrote about the arduino-envrionement, because it's basically goes back to the same damn conversation that happened 3-4 replies back.

So you basically accept you were wrong the entire time then. Thank you. Only took a damn page for you to get it.

 

1 hour ago, RedRound2 said:

Does any of those test methods require 9600 hours to be logged

Well if you had bothered to read what I wrote then you'd know even a basic EEPROM goes through a million hours of testing. So yes it would, a hell of a lot more than 9600 hours. Now before you get confused about how you can do a million hours of testing in a year read the post.

 

1 hour ago, RedRound2 said:

A lot of the validation test all you guys are talking about is done at the foundry itself

NO IT IS NOT! Absolutely, unequivocally zero of the testing I've ever talked about is done at the chip foundry, zero. Maybe if you had actually read what was being said this blindly obvious fact would have gone noticed. How many times do I need to say you can't just swap out the processor in the ECU and not fully test the entire product again?

 

Geez, why did I even bother 

 

"I just need to update the chip and slap it on the same ECU and not product test it because I'm just so smart", multi million dollar class action lawsuit payout because you have zero leg to stand.

[Dracarris]

1 hour ago, RedRound2 said:

I'm sorry. Which car companies designs and makes custom silicon for bare metal programming?

Custom silicon may be a bit far fetched but stuff like the obstacle detection (radar plus image processing) is at least with Mercedes done of FPGAs, admittedly not fully custom silicon.

[leadeater]

1 hour ago, RedRound2 said:

And I still feel, if it wasn't for Tesla, we would have still had absolute garbage infotainment system in most cars

Most likely but the chip shortage in the vehicle industry isn't about just the infotainment systems.

 

Quote

“Due to the global shortage of semiconductors impacting the global auto industry, we are making Active Fuel Management/Dynamic Fuel Management unavailable on certain 2021 model year full-size trucks," said Michelle Malcho, GM spokesperson, on Monday.

 

Quote

The Automatic Stop/Start feature will no longer be available on 2021 model year for the following vehicles equipped with 5.3-liter and 6.2-liter V8 engines mated to 10-speed transmissions:

• Chevrolet Tahoe and Suburban full-size SUVs
• GMC Yukon and Yukon XL full-size SUVs
• Cadillac Escalade and Escalade ESV full-size SUVs
• Chevrolet Silverado 1500 full-size light-duty pickup
• GMC Sierra 1500 full-size light-duty pickup

https://www.freep.com/story/money/cars/general-motors/2021/06/08/gm-pickups-suvs-chip-shortage/7601235002/

 

 

[CarlBar]

11 hours ago, RedRound2 said:

I'm sorry. Which car companies designs and makes custom silicon for bare metal programming?

 

Probably very few. But no one is using random off the shelf parts either. Someone, be that the foundry, the car manufacturer, or some middle man, (or more likely some combination of all 3), has to arrange to:

 

A) Have all the relevant components produced on the newer smaller node.

 

B) Have each individual component tested to meet the required automotive standards

 

C) Assemble the individual components into an ECU.

 

D) Re certify that the new form of ECU meets the specifications.

 

E) install it in a specific Model of Car you wish to sell.

 

F) Recertify that every aspect of the system remains in spec when operating on the specific model of vehicle.

 

 

Steps E and F have to be done with every new model of car regardless of anything else.

 

Steps A, B, C, and D only have to be done anytime any component in the ECU is changed.

 

 

Here's the catch, no one outside of the automotive industry uses automotive certified electronics. So no one is going to do steps Ab, B, C, or D unless there's a market for the final product. And automobile manufacturers haven't been interested in anything new for quite a while. So no one has gone out and done all this yet because it's expensive and there's no demand.

 

And there's no demand because doing all of that costs a lot and that means the ECU's produced with the smaller process are, (at least at first), going to cost more. And the Automotive manufacturers don't want to pay more if they can pay less.

 

 

11 hours ago, RedRound2 said:

But maintainability is required while updating systems and changing platforms.

 

And every time you change the code even slightly the whole thing has to be re-certified on every hardware and mounting configuration using it. So they update this stuff as infrequently as possibble. Because it's expensive and why spend money for no benefit.

[RedRound2]

19 hours ago, leadeater said:

The processor isn't the problem, it's not the only thing that gets tested and certified. You think just because say TSMC makes a chip and packages in to an BGA device and gives it an operating range of -40C to 120C that the rest of the ECU doesn't need to be designed and capable of the same thing to? I'm trying really hard not to call your mental capacity in to question but you are making it very difficult.

 

If you change out the processor in the ECU you MUST do all this testing again. "I only node shrunk the design therefore I do not need to retest" <- not a thing.

 

You're literally not even in the right ballpark to where the issues is and what needs testing.

 

Of course the fab validated and bins their chips, that's also irrelevant to the testing of the ECU itself. Do you understand product testing at all? That would be relevant to the product design and parts selection.

 

Your argument is literally TSMC has validated the chip so the car doesn't need to be crash tested, yes this is an absurd point because so is yours.

God, how are you so incapable of understanding anything in relation to the context. So you agree the that the processor and the PCB (likely the only new thing) from a purely node migration standpoint comes tested with temperatures. If the rest of the ECU remains the same, i dont see why extensive and thorough validation is required for the rest of the components. If an ECU is made of A, B, C and D, and only A is changed while evrything else remains the same, then just stress only A and do integration test with rest. How this logic goes over you head is beyond me.

Do you genuinly just waste your time retesting the same thing again and again? Either you have to be really incompetant at what you do, or you don't have the mental capacity to figure that much out

Quote

So you basically accept you were wrong the entire time then. Thank you. Only took a damn page for you to get it.

Nope, it is some kind of random ramblings that doesn't make any sense and connecting two things I never even connected. I even gave three four examples on how stupid your assertions were on my comparison with Arduino. I only used Arduino to prove a point that the whatever code you might have to rewrite for the new processor node, assuming it was bare metal code, would be relatively easy to do. When I purely talk about the basic computation power, and hence less code complexity of an ECU, you go talk about Arduino and it's envrionment ratings.

 

And on that topic, I see you basically left out literally everything else I reply to without acknowledging the fact that you assumed wrong.

Quote

Well if you had bothered to read what I wrote then you'd know even a basic EEPROM goes through a million hours of testing. So yes it would, a hell of a lot more than 9600 hours. Now before you get confused about how you can do a million hours of testing in a year read the post.

So does the auto manufacturere test EEPROM? Circles back to my first quote. Do you lack something? Fundamental functions of processor liek 1+1 are tested by foundries, not auto manufacturers

Quote

NO IT IS NOT! Absolutely, unequivocally zero of the testing I've ever talked about is done at the chip foundry, zero. Maybe if you had actually read what was being said this blindly obvious fact would have gone noticed. How many times do I need to say you can't just swap out the processor in the ECU and not fully test the entire product again?

 

Geez, why did I even bother 

 

"I just need to update the chip and slap it on the same ECU and not product test it because I'm just so smart", multi million dollar class action lawsuit payout because you have zero leg to stand.

Yeah I'm quite convinced that your reading comprehension is absolutely garbage. Validation *of automotive grade components*. The companies buy *automotive grade*. They dont buy hobby grade and convert it into *automotive grade*. 

 

At what point did I even say that TSMC does crash tests? I said specs like temperature, vibration, etc usually are rated from foundry, but somehow you extrapolate that into TSMC testing car crash tests.

 

And what point did I say no testing was required? Please be a little competant and answer that. I said a year of testing was more than enough for very basic modifications. Stop putting words in my mouth with your random delusions.

 

Honestly, all my conversations with you have been a huge colossal waste of time. You can't admit when you're wrong and you cling onto some random ideas you come up with in my head just because two disconnected words were in your field of vision

[CarlBar]

6 minutes ago, RedRound2 said:

i dont see why extensive and thorough validation is required for the rest of the components.

 

Because thats the legal requirement to meet the specification and other legal ohh ahh.