Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Controls/MCUs
 
 
Controls/MCUs  

Questioning the need for proprietary flash in car MCUs

Posted: 13 May 2014     Print Version  Bookmark and Share

Keywords:Globalfoundries  MCU  non-volatile memory  SoC  NVM 

While the technology development for next-generation 40nm eFlash MCUs for the automotive industry is in progress (Infineon and Globalfoundries made an agreement last year), the 55nm platform is the available process technology for automotive chip vendors today.

As the technology moves down to the finer node, Colestock sees the 28nm process node becoming the "battleground." That might force automotive chip companies to give up proprietary embedded NVM technology.

Web-Feet Research analyst Niebel agrees. "Offering an embed NVM that scales below 28nm and uses low power would be a way for IDMs to give up their proprietary embedded Floating Gate (eFG) that cannot scale below 40-32nm," he said.

As potential candidates, he mentioned, "ReRAM, PCM, STT-MRAM and maybe eCT (embedded Charge Trap) are possibilities." In either way, "an already qualified automotive emNVM technology would be a great incentive for IDMs to give up their own emFG," Niebel added.

Objective Analysis' Handy added, "The only thing that would motivate an IDM to give up a proprietary technology on an automotive MCU in favour of something else would be if they could get the chip at a lower cost, including licensing fees."

History tells us that many automotive chip companies relied on their own flash technology and held it hostage to stay in the game. They wanted to continue their own R&D and perhaps even some production, in order to differentiate their products in the automotive market.

But the automotive industry is approaching to a new era. As car OEMs begin to integrate more advanced driver assistance systems (ADAS) features in their cars, they're demanding automotive chips with higher reliability.

Colestock observed that carmakers, in some cases, are planning to use "multiple cores" of a multicore processor in order to achieve redundancy. Instead of adding another processor to the system, car OEMs seem committed to running the same code on multiple cores in the same processor. That's a whole different use of multicore processors, compared to other industries. It makes even more critical for the multicore processor not to fail.

Reliability and safety standards imposed on automotive chips will only get tougher as the combined hardware and software as a whole, implemented on the embedded MCU/SoC, undergoes much greater scrutiny.

In nutshell, in a future of active ADAS relying on a car's ECU to make decisions (such as braking) and actually drive the car, the operative chip must be absolutely trustworthy.

Luca De Ambroggi, principal analyst for automotive semiconductor at IHS Technology, suspects that automotive chip vendors will soon find that it won't be enough to have their chips pass AEC-Q100 standards. Their chips will need to get certified on functional safety levels, demanded by ISO 26262, he noted.

Globalfoundries, which has a seat in the AEC-Q100 Technical Working Group and has been involved in the development of the qualification standards for a long time, is fully aware of the future suggested by the analyst.

Colestock said, "We're in the midst of figuring out how to translate the ISO 26262 functional safety standard for each party involved in the food chain." Those who offer foundry services, chips, modules and systems need to share the responsibility, while the industry has to sort out a way to verify and certify technologies/products offered at each level, in order to meet the ISO 26262 standard.

For the time being, Globalfoundries' newly announced platform is built on its 55nm low power process and AEC-Q100 Group D qualified.

The platform's automotive-specific flow is said to include defect detection, defect reduction and outlier controls to provide significant improvement in quality and reliability. The company said that the automotive platform supports the use of ARM core technology with a variety of standard cell and compilers, as well as IP blocks for GPIO, interface and oscillator functions.

- Junko Yoshida
  EE Times


 First Page Previous Page 1 • 2



Comment on "Questioning the need for proprietary..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top