Automotive world: PowerPC vs ARM vs V850 vs SH

[dpk]

Hi,

I am trying to understand the reasons to select a particular CPU for automotive applications e.g. powertrain/safety etc..
As I can read PowerPC (e200z2/e200z4/e200z7..) are most widely in use whereas ARM has started picking up recently with its Cortex-R4F series..

Any idea where can I get more information about:
- features of an automotive CPU
- comparison b/w PowerPC vs ARM for automotive applications

With Thanks,
dpk

[Psi]

The temperature range is important.
The car could be below zero in some countries or above 60deg in midday sun.

Often you will see mcus for automotive applications which have extra features, like CAN bus drivers etc..

Most of the special design requirements for automotive devices is to do with the powersupply and spike protection.

[andersm]

SuperH is on the way out, and I believe Renesas are slowly trying to get rid of most of their enormous catalogue in favour of concentrating on their newest architectures (RX, RL78).

[gocemk]

Hi, i used to work in an auto service dealership for Mercedes-Benz, and VAG vehicles. From my experience Freescale dominated the automotive MCU market (at least for Europe) with their MPC55x series of microcontrollers (which uses 32bit Power PC) somewhere from 2007 up until 2008. Since that, it seems to me that Infineon is the new dominant MCU manufacturer for automotive applications with their 32bit Infineon TriCore MCU's.

You can find out more here:
Freescale : http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5554
Infineon: http://www.infineon.com/cms/en/product/microcontrollers/32-bit-tricore-tm-microcontrollers/channel.html?channel=ff80808112ab681d0112ab6b64b50805

[lapm]

The temperature range is important.
The car could be below zero in some countries or above 60deg in midday sun.

Often you will see mcus for automotive applications which have extra features, like CAN bus drivers etc..

Most of the special design requirements for automotive devices is to do with the powersupply and spike protection.

In here Finland its not totally unusual for winter temperature to be -30 Celsius or even worse time to time. During summer heat wave it can easy be +30 to +40 Celsius degrees out at sun. So that 70-80 Celsius degrees window for something that should work in car.

As Other has pointed, it depends where you live tho..

[nctnico]

Usually automotive parts are rated for operating (!) in temperatures from -40 to over 100 degrees C.

[dpk]

Thanks for all these comments..

Still my question about the choice of the processor for MCU is answered..PowerPC core (Freescale) was a dominant player which is seeing big competition from INfienion (Tricore processor) and Renesas (RX/V850 processors)..ARM is a latest entrant...
So what is inside these cores which make them different apart from the other peripherals (CAN, Ethernet, ADC etc ) in the MCU?

Temp range (-40C to 150C) is a big constraint but does it mean that ARM can't live upto that?

With Rgds,
dpk

[jmole]

Temp range (-40C to 150C) is a big constraint but does it mean that ARM can't live upto that?

ARM is an architecture, not a vendor. I'm sure someone out there makes an ARM thats rad-hard, for space applications, with a much wider temp range than that.

[Niklas]

Price
Every cent matters.

Architecture
New demands for safety as specified by IEC 26262. I have heard discussions about dual microcontrollers or combinations of microcontroller and FPGA.
Floating point might also have an upper hand as some companies prefer SI units over modified units with specified offsets and scaling to fit.
Advanced peripherals that offloads the CPU as a lot of code is generated from models in Matlab/Simulink etc

[Psi]

Temp range (-40C to 150C) is a big constraint but does it mean that ARM can't live upto that?

150C is quite high and limits your options.   A range of -40C  +105/125C is more normal for general automotive stuff.

If you intend on mounting the device in the engine bay, either hard up against the engine or bolted to it, then yeah, you will need some pretty high temp mcu.
I would avoid mounting stuff near the engine for that reason..

I don't think they're are any laws regarding what mcu specs you "must" use.  It's up to you what temp range you decide is necessary or your application.

You do need to keep in mind the rules if you choose to get your product certified to one of the automotive standards so you can display the compliance on the product.
For example, your product maybe fine with a normal -40C +85C mcu but the certification may say that all mcus have to be -40C +125C no exceptions.

[dpk]

Temp range (-40C to 150C) is a big constraint but does it mean that ARM can't live upto that?

ARM is an architecture, not a vendor. I'm sure someone out there makes an ARM thats rad-hard, for space applications, with a much wider temp range than that.

I agree..And here is why I am confused. Can any processor be used for safety criticial applications such as automotive safety/space etc? Or is there some features in the processor (very low interrupt latency/dual core lockstep execution/ecc checking for each instruction/data fetch) which makes it right choice?

[jmole]

I agree..And here is why I am confused. Can any processor be used for safety criticial applications such as automotive safety/space etc? Or is there some features in the processor (very low interrupt latency/dual core lockstep execution/ecc checking for each instruction/data fetch) which makes it right choice?

System architecture (rather than MCU architecture) is key. You have a processor that never ever fails? Great. How about when the OS gets a kernel panic?

Figure out what your system needs to do, then find the parts that fit the bill. If the parts don't exist, invent them, get someone else to invent them, or come up with a different solution.

[Psi]

I agree..And here is why I am confused. Can any processor be used for safety criticial applications such as automotive safety/space etc? Or is there some features in the processor (very low interrupt latency/dual core lockstep execution/ecc checking for each instruction/data fetch) which makes it right choice?

Are you thinking of the warnings you see in datasheets about the component being not suitable for safety/medical/life-support systems?
I don't think that applies to general automotive applications. Maybe the ABS controller?

As far as i know you can use any mcu you want, you're just limited by the rules of any certification you may want to get if any.
The car maker will have got the entire car certified to some standard in its stock condition but that doesn't mean you have to keep that standard for an aftermarket product you're making.

However i'm not an expert on this.
If your worried about the legal issues for automotive electronics and safety then you should probably talk to a lawyer/expert in that area.

[poorchava]

I agree..And here is why I am confused. Can any processor be used for safety criticial applications such as automotive safety/space etc? Or is there some features in the processor (very low interrupt latency/dual core lockstep execution/ecc checking for each instruction/data fetch) which makes it right choice?

Are you thinking of the warnings you see in datasheets about the component being not suitable for safety/medical/life-support systems?
I don't think that applies to general automotive applications. Maybe the ABS controller?

As far as i know you can use any mcu you want, you're just limited by the rules of any certification you may want to get if any.
The car maker will have got the entire car certified to some standard in its stock condition but that doesn't mean you have to keep that standard for an aftermarket product you're making.

However i'm not an expert on this.
If your worried about the legal issues for automotive electronics and safety then you should probably talk to a lawyer/expert in that area.

I'm dealing with that stuff on a daily basis in my normal job. What you typically require in Europe is automotive qualification as per AEC-Q100 grade 1 which is up to 125 deg. C. 

As for the life support clause in datasheets,  it does apply to all automotive stuff except for infotainment systems and the like. Power train, gearshift control,  braking systems -  they all fall under this. This is not a problem,  since you typically don't use a component without mutually signed quality agreement anyway. 

As for features which make one controller better than the other are failure prevention and containment features.  This would include all sorts of watchdogs,  flash error correction,  write protection mechanisms. 

[theoldwizard1]

I just bumped into the thread and I have to comment, mainly because I lived this in the late 90s early 2000s.

In extremely high volumes (automotive, cell phones) the chip company will likely customize thing to what you want/need.  Or you do like Apple and set up your own design house to make the custom bits that are important to your application.

Bottom line for any extremely high volume application is cost.  If the best engineering design does not fit the cost budget the engineers will just have to make the chosen solution work !

[Scrts]

Hi, i used to work in an auto service dealership for Mercedes-Benz, and VAG vehicles. From my experience Freescale dominated the automotive MCU market (at least for Europe) with their MPC55x series of microcontrollers (which uses 32bit Power PC) somewhere from 2007 up until 2008. Since that, it seems to me that Infineon is the new dominant MCU manufacturer for automotive applications with their 32bit Infineon TriCore MCU's.

You can find out more here:
Freescale : http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5554
Infineon: http://www.infineon.com/cms/en/product/microcontrollers/32-bit-tricore-tm-microcontrollers/channel.html?channel=ff80808112ab681d0112ab6b64b50805

Freescale and ST had a joint venture creating MPC5600 series microcontrollers. They both are same package and pin-to-pin compatible. At some point - they've divorced, so the software support behind them is different, however they are almost identical. Each supplier programmed some ID codes in the microcontroller in a certain way, so that the debugger won't recognize the competitor chip.