Auto Electronics

Right Sizing Embedded Processors

MCUs and DSPs need to meet the needs of today’s applications while providing a transition path for future performance.

For the PDF version of this article, click here.

Depending on the vehicle application, embedded systems typically use 8-bit, 16-bit and even 32-bit microcontrollers (MCUs). With their low cost and small footprint, 8-bit MCUs find use in many systems but are most popular as the main processor in security systems. The historical pinnacle for embedded performance has been powertrain. However, high-end infotainment systems require digital signal processor (DSP) and MCU performance beyond the highest-performing powertrain units. With growing system complexity, application-specific processors and development tools including reference designs have become key supplier differentiators. This report will explore the changes in the embedded computing and controlling needs in powertrain, infotainment, safety, security and body electronics.

The increasing complexity of individual automotive systems and the sharing of data and communications between systems have meant increased memory requirements and frequently one or more communications protocols in the MCUs and DSPs located in vehicles. One of the high-end luxury vehicles that pioneer advanced electronics can easily have more than 80 MCUs.

“On an average, you may be running somewhere between 25 to 35 micros in the average car,” said Willie Fitzgerald, director of automotive marketing, Microchip Technology. “It is a good chance that 40% to 50% will be eight bit, you probably have another 40-ish being 16 bit and the balance of 10% would be 32 bit.” The 32-bit units are the smallest portion but also the fastest growing. With the addition of more electronics and new architectures, 32-bit units are expanding from powertrain to body electronics to entertainment systems.

Some of the newest 32-bit MCUs designed for powertrain applications include Infineon's TC1766/96 that use 130 nm technology. The TriCore processor architecture combines the strengths of a MCU, a microprocessor (MPU) and a DSP in a single core.

Designed for engine and gearbox control systems in light vehicles, trucks and motorcycles, these MCUs manage functions that include injection, ignition, lambda control and exhaust gas recirculation. Targeted use of the TC1766 is to control four- to six-cylinder engines and the TC1796 for engines of six or more cylinders. Consequently, major differences between the two units include the appropriate clock frequency, the size of the embedded flash memory, and the set of peripherals for these applications. The TC1766 has clock rates of up to 80 MHz and comes with 1.5 MB of embedded flash memory. The TC1796 operates at clock rates of up to 150 MHz and has 2 MB of embedded flash memory. Communication capabilities of the TC1766 include:

  • a multiCAN module with four CAN nodes that have TTCAN functionality;
  • two micro-second bus interfaces (MSC) for port expansion to external power ASICs; and
  • two high-speed micro-link interfaces for serial interprocessor communication (MLI).

To address increasing customer needs in body electronics, NEC Electronics recently introduced its Fx3 series of 32-bit MCUs as well as Fx2 series of 8-bit MCUs. Based on a 0.15 µ process technology, the units have up to 1 MB of embedded flash memory optimized for automotive body and safety control applications. All 29 products support the CAN and LIN protocol. To provide an easy migration path, products in the Fx3 series of MCUs are pin compatible with the company's previous-generation Fx2 series of MCUs.

Connectivity in the vehicle is a specific driver for increasing the number of MCUs. The connectivity includes the CAN as the dominant vehicle bus with connectivity to lower-speed LIN bus and high-speed FlexRay and MOST networks. “As you have the expansion of processors in the various electronic modules throughout the car, they can't be independent,” said Microchip's Fitzgerald. “The value comes with them being able to be on a network to share the information that they are gathering and sharing it between various networks within the vehicle. The real power and benefits to the driving experience come from the ability to share that information.” Figure 1 shows the connectivity from the body electronics perspective.

Figure 2 shows an example of the MCUs in a gateway. Renesas high-performance 32-bit MCUs with built-in FlexRay IP device provide the gateway to a high-speed CAN network and operate three-phase motors using the FlexRay protocol.


One of the biggest changes that Microchip's Fitzgerald sees is in the body area. The use of LIN as a sub-network to some of the lower functioning systems such as window lift motors and mirrors started a few years ago and continues to gain momentum. The transition requires a LIN-CAN gateway to connect to the rest of the vehicle that operates on CAN. A gateway type of device that serves as the main controller in the door could provide the connection to CAN for the vehicle network but it would also communicate to other doors on LIN. “This could be a high-performance eight-bit,” said Fitzgerald. “It would be driven pretty much by the complexity of the systems and by the overall memory.”

In a four-door vehicle there could be four or five MCUs — one master and the rest slaves. Depending on how the system is architected, the MCU could control windows and door locks. In many cases, the windows are kept separate from the door locks to provide flexibility for various car models, so a four-door vehicle could have as many as seven MCUs.

In Europe, LIN is already in a wide range of vehicles. Where speed is not critical and a high level of safety is not required on the bus, LIN eliminates wiring. “You are even starting to see the SAE version, the 2602 coming out with some of the North American cars,” noted Fitzgerald. SAE J2602 is the North American version of LIN. Today, CAN is the dominant protocol but in the MY09 and MY10 vehicles, LIN could be a strong number two.

As shown in Figure 3, Renesas R8C/tiny series or the M16C/tiny series have 1 MB of memory space and a variety of peripherals that make them well suited for control in LIN nodes. The M16C/tiny provides a gateway MCU capability for the CAN to LIN transition.

Eight-bit systems are used extensively in security for keyless and passive entry systems. These can be 8-bit units either on the transmitter and the receiver side. However, when the receiver is used as a multifunction receiver for tire pressure monitoring system and the code requirements start to exceed 128 bit, a 16-bit MCU often is the choice. For users of Microchip's PICs, this is a rather simple transition since their architecture is software compatible.

In addition to LIN and remote keyless entry (RKE) systems, 8-bit MCU applications include sensor nodes where intelligence is required, electric park brake systems, reverse parking assist distance sensors, electrochromatic dimming mirrors, wiper controls, HVAC, glow plug controls in diesels, and lighting. Adaptive light positioning could use either 8-bit or 16-bit units, but more intelligent interior lighting levels, exterior daytime running lights, and LED lighting are all candidates for 8-bit MCUs.

Eight-bit MCUs continue to have new applications in vehicles especially as purely mechanical systems are converted to electronics. The entry point for this transition is usually an 8-bit MCU. Microchip's PIC10F family of six-pin microcontrollers, promoted as the world's smallest 8-bit MCU, has common vehicle applications as a mechanical switch replacement. As part of the long-term evolution, many of the initial applications take advantage of ongoing improvements in capability and stay with 8-bit units.

The block diagram in Figure 4 shows one of the members from Microchip's 14-pin family of MCUs, one of its most popular MCUs for vehicle applications. The family is used in airbag crash sensors, wiper systems, RKE systems and low-end motor control systems. However, even the six-pin MCUs include the same hardware except the EUSART with reduced program and RAM memory and reduced number of functions.


Perhaps one of the more radical design changes in advanced electronic systems is the use of field-programmable gate arrays (FPGAs) for production vehicles. FPGAs address 8-bit, 16-bit and even 32-bit applications, sometimes replacing and often working in conjunction with these MCUs. The areas where FPGAs are finding a new home in automotive applications include: infotainment/multimedia, driver assistance, voice recognition and re-configurable instrument clusters.

These are the newest of the new applications where customers have applications with a lot of consumer requirements, so there are shorter design cycles. “We have seen customers with 12 months or less design cycles for a telematics platform,” said Harvey Steele, director and general manager, automotive product line, Xilinx.

Using a standard hardware architecture and just putting a different density FPGA and a different bit-stream into the FPGA avoids changing the hardware architecture. This provides the capability to meet the short time-to-market, avoids the high development NRE costs for ASICs, and allows a customizable platform for several different customers. As noted in a recent SAE paper[1], the “emphasis on reducing the developments cycles to 12 to 24 months” and the capability of FPGAs that “resemble full system-on-a-chip (SoC) devices” has given FPGAs a new home in automotive applications.

The challenge for the automotive electronics designers requires looking at the system differently to take full advantage of the FPGA. “It really depends on the customer and how far down the learning curve they are with programmable logic,” said Steele. Historically, FPGAs were more expensive so their use was in the prototype vehicle prior to designing an ASIC. Over the last 10 years, the performance of FPGAs, in terms of functionality with embedded processors and DSP capability, I/O system, and more, has increased dramatically. Since FPGAs run in a 12-inch, 90 nm process, “the cost on a logic cell basis has gone down orders of magnitude,” said Steele. At the same time, with the need for high-end audio, multimedia, telematics platform, and image processing for driver assistance applications, the technical requirements have increased dramatically as well. There is a crossover point where it is more cost effective in many applications to go with an FPGA instead of an ASIC for volume production.

As noted by the authors of SAE 2006-01-368, “the cost advantages of an FPGA vs. an ASIC tip the scale, especially as process technology nodes decrease below 130 nm, where the mask costs alone can exceed one million dollars.”

“The FPGA is basically a programmable fabric,” noted Kevin Tanaka, worldwide automotive marketing and product planning manager at Xilinx. “We have a low-end FPGA where we can program in very very small state controllers. We can even program in 8-bit microcontrollers and 32-bit microprocessors to run on that fabric.” The higher-end Virtex FPGA has the PowerPC 405 that is hard embedded.

Xilinx MicroBlaze soft processor solution is implemented using general logic primitives rather than a hard dedicated block in the FPGA. The unit has a 32-bit Harvard RISC architecture with an instruction set optimized for embedded applications. As shown in Figure 5, the MicroBlaze is one of the computing cores in an FPGA designed for a rear seat entertainment system.

In some cases, the FPGA is used simply for logic functionality. In other cases, a MicroBlaze processor embedded in the FPGA takes part of the processing functionality off the board from an MCU. FPGAs also have built-in DSP functionality from hardware blocks. It is not uncommon in many applications to see an FPGA and a micro or an FPGA and DSP splitting the processing. A good example is lane departure warning. With the two camera inputs, multiple channels run through the FPGA that does much of the image preprocessing, filtering, etc. The processed data from those two channels is fed to a fixed point DSP to do the detailed calculations. Earlier systems may have used three DSPs to perform this function.

“The standard 32-bit core usually runs somewhere between 40 MHz and 80 MHz,” said Tanaka. The 32-bit soft core MicroBlaze is rated at 92 DMIPS at 100 MHz (at 90 nm process node). In addition to the 450 MHz PowerPC, the Virtex 4 in the automotive product family has 500 MHz extreme DSP slices on the same chip and provides 700+ DMIPS. High-end applications such as full gateways use the Virtex-4 since it performs like a high-speed router inside the vehicle. The FPGA could be used on production vehicles for gateways as soon as 2007.

Just having an automotive product is not sufficient to displace or even work hand in hand with industry veteran MCUs. Xilinx dedicated automotive product line, or XA, includes selected products with AEC-Q100 qualification at a family level. System architecture and solution teams have developed either internally or with automotive development partners the IP blocks to populate an FPGA with a number of system critical blocks for targeted systems. Table 1 shows examples of these IP elements in eight different areas.

Perhaps the best example of FPGA usage in a production vehicle is the 2006 Mercedes S-class that has as many as 11 Xilinx FPGAs if all the options are ordered. Table 2 shows the applications that include the digital video broadcast television (DVB-T) in Europe.


In addition to the growing use of DSPs and high-performance 32-bit MCUs, 8-bit MCUs continue to have a dominant place in vehicle electronics and have applications in some of the newest systems. Emerging applications for consumer electronics in vehicles and reduced time-to-market are making FPGAs another interesting choice for designers. “A definite trend on the embedded side is that you are going to see some of that functionality embedded into FPGAs,” said Xilinx' Steele. “Just purely due to performance,” added Tanaka.

Table 2. FPGA usage in the 2006 Mercedes S-class.
Rear Seat Entertainment 4 FPGA
DVB-T Reception 2 FPGA
Navigation System 1 FPGA
Short-Range Radar (Stop-and-Go System) 1 FPGA
Adaptive Cruise Control 1 FPGA
Night Vision 2 FPGA


  1. Michael Gabrick, Rick Nicholson, Frank Winters, Bruce Young and Jim Patton, “FPGA Considerations for Automotive Applications,” SAE 2006-01-0368.


Randy Frank is president of Randy Frank & Associates Ltd., a technical marketing consulting firm based in Scottsdale, AZ. He is an SAE and IEEE Fellow and has been involved in automotive electronics for more than 25 years. He can be reached at [email protected].

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.