Automotive Goes Dual-Core

Mathew Everett 18 Aug, 2006 at 10:42am ET Article published in Tech

Renesas Technology anticipates that its dual-core microcontroller (MCU) for automotive vehicles could hit the market by 2010 at the latest, and possibly as early as 2008. The new solution will help to enhance the functionality of electronic components that will be deployed within an increasingly complex driving environment.

The new dual-core MCU will be fabricated on 90nm process and will be available for the market during a 2008 to 2010 timeframe. Renesas emphasized that the number of MCUs required for automotive vehicles has been growing substantially. Taking a BMW as an example, the number of MCUs onboard has grown from 18 in 1999 to 40 in 2004.

Now Geeks with nice cars will be comparing Dual-Core chips for their airbags. I want to see these benchmarks…

Source: Digitimes

Comments

18 Aug 2006 ~ 11:12am primesuspect Great, so now instead of $600 to replace a failed ECM, it's going to cost $1200...
18 Aug 2006 ~ 12:52pm Sledgehammer70 Yup... got to love BMW and the Benz
18 Aug 2006 ~ 1:01pm DogSoldier Yes, but how fast will it Fold?!
18 Aug 2006 ~ 2:22pm Garg Governor-limited at 155 MPH, stateside
18 Aug 2006 ~ 4:44pm Sledgehammer70 Good idea Dog...

My car is running 64 instances of folding while I drive! what now sucker punk!
18 Aug 2006 ~ 9:58pm Daxx Well, I say overclock that sucker for an extra 50HP! Beats the heck outta slapping on the 25HP coffee can muffler mod...
19 Aug 2006 ~ 9:20am drasnor I don't think it's a good idea to build MCUs this way. The only reason you'd put another core on an MCU is to increase the load borne by individual MCUs. In doing so, you're running the same processing load on fewer, more powerful computers. While this would be great in a server room or at home, in automotive or aerospace applications you're putting too many eggs in one basket.

-drasnor
19 Aug 2006 ~ 12:34pm primesuspect Perhaps there will be a need for multiple processing within automotive apps by 2010, though.. The processing needed for things like hybrid engines, fuel management, adaptive braking, and in-cabin electronics is rapidly becoming more complicated.
19 Aug 2006 ~ 4:47pm drasnor I don't know... I guess where I'm going with this is that having discrete MCUs for each different task reduces the likelihood of a fault in one task affecting the performance of other tasks. Typically engineers use a different MCU for each different task, eg one for engine control, one for adaptive braking etc.

The intent behind producing a multi-core MCU is either you anticipate that your task has code that will execute well in parallel (unlikely) or you intend to combine multiple tasks on a single MCU. This introduces another set of challenges like the fact that all of a sudden you now need a task scheduler and a whole 'nother layer of support software. Keep in mind that a normal MCU doesn't have anything like an OS, it just grabs its single program from ROM and runs it without having to play nice with other applications on the same computer. The entire idea of multi-core MCUs strikes me as taking a special-purpose computer and giving it PC-like qualities and PC-like reliability. In a device that needs to work ALL the time you don't want to have to deal with software glitches.

-drasnor