Microcontrollers and microprocessors have long been the natural choice to implement control functions in instrument clusters, door modules, and other control-based electronic control units (ECUs). Design experience and legacy code are two of the many reasons to use such devices time and time again.

The tendency is to build the software topology in logically partitioned function blocks that meet the ECU specification. But only when these function blocks are compiled and targeted at a single device will we see the real-time issues associated with sequential code. Even though these functions were built discretely, they will run sequentially based on a pre-defined prioritization structure.

You may not even see these timing issues immediately. Any interrupt collision issues will not be caught in simulation because the tendency is to only test what you know should work – and it is almost impossible to test for indeterminate states or real-time fault conditions. Any function that runs off of an interrupt can only really be tested after the system is built up and run in real time. At this point we can catch more of the errors, but only when the product hits the road will every conceivable interrupt state be tried and tested. We have to hope that these are not major failures and that they can be fixed with a software patch at the next scheduled vehicle service.

Function Interdependency
With programmable logic, you can build up a system in the same way as with a microprocessor or microcontroller — by implementing discrete functional blocks. But unlike micro code, these functions are totally independent: instantiated in hardware (as opposed to software), they will run in real time and are not susceptible to erroneous errors or interrupt states.

Each function will operate on its own and is guaranteed to run as described every time, under every condition. Another benefit is that you can simulate every state before building any hardware, so the risks of operations or tasks not functioning as required — or happening out of sequence — are dramatically reduced.

For example, when building an instrument cluster, you may need to display a "tell tale" based on the driver pushing a switch; respond to a CAN packet dictating the position of the tachometer; and handle an error message from the braking system that must be displayed urgently to alert the driver – all at the same time.

In software-based systems, these tasks run sequentially. You must give priority to the error message, but which task runs when and in what order depends on when the interrupt hits the micro.

In a PLD-based system, all of these functions are handled in parallel, displayed as soon as the message hits the device. The parallel processing available in FPGAs and CPLDs offers a great advantage in applications where instant, uninterrupted signals must be processed reliably.

Board-Level Functions
As designs become more complex, more peripheral functions are controlled by 8-bit microcontrollers – but they may not have sufficient I/O. There are a number of solutions to this issue, including stepping up to a more costly 16-bit microcontroller. Another is to partition the design over a low-cost 8-bit microcontroller and low-cost CPLD.

Here's a good example: a system has multiple ADC inputs used as data inputs to help control and position multiple stepper motors (such as in an instrument cluster) plus other I/O for LED control and switch inputs. The low-cost microcontroller is ideal for the sequential signal processing but has limited I/O to interface to off-chip devices.

The CPLD can interface to the microcontroller through a simple serial bus and provide low-cost inputs and outputs to the devices that need to be controlled. Although this approach may increase the board component count, the combined cost of an 8-bit microcontroller and CPLD is lower than that of a 16-bit microprocessor.

This approach also allows the board to be adapted to suit many customer configurations through the CPLD, providing the ability to interface to many different devices under control. The Xilinx® CoolRunner^TM-II family of CPLDs are not only easy to design with, but offer extremely low power consumption, thus eliminating the need to compromise power or performance. The low-cost XC9500XL devices are ideal if you require 5V-compatible I/O.

Figure 1 shows a typical example of where a CPLD can be used alongside a microcontroller, providing extra I/O to connect to multiple indicator LEDs and also provide I/O to control multiple motors. The CPLD in this example also provides simple PWM functions and ADC interfacing to aid with motor control, which can enable you to use a lower cost, basic microcontroller without PWMs.

Interfacing and Bridging
With the increasing number of bus protocols supported by ASSP and microcontroller vendors, interface translation is a growing problem that requires an inexpensive and easy solution. Offering the lowest cost method for translating one bus protocol into another, CPLD devices can support interface bridging applications, including voltage-level shifting (3.3V in to 1.8V out), bus translation applications (translating a proprietary language to an industry-standard language), serial-toparallel and parallel-to-serial bus conversions, and DDR memory interfacing. Figure 2 shows how CPLDs can be used to interface to high-speed memory and also shows an example of a CPLD level-shifting between different voltage levels.

CoolRunner-II CPLDs are ideal for DDR memory interfacing, as they include DualEDGE-triggered registers, a global clock divider, and voltage-referenced I/O standards including SSTL_2. These features provide the capability to interface between a microprocessor and high-speed memory devices such as DDR SDRAM. To make implementing this function easier, Xilinx offers a reference design and application note (XAPP384, "Interfacing to DDR SDRAM with CoolRunner-II CPLDs") for downloading at the Xilinx website (www.xilinx.com/literature/). This reference design is particularly useful if your chosen microprocessor does not support HSTL or SSTL memory interfaces.

Conclusion
Automotive design has always been a challenging environment when faced with small-form-factor ECU specifications, wide temperature ranges, high-quality and reliability requirements, and low cost points. Today's designs also need to be flexible, upgradeable, and easy to test fully. Programmable logic is a viable alternative to microprocessors and microcontrollers because they offer true design interdependency and parallel processing. CPLDs can be used to great effect where microcontrollers have run out of I/O or processing power, or simply for memory interfacing or voltage-level shifting.

Xilinx Automotive Devices Designing electronics systems for automobiles has always been challenging. With automotive electronics comprising as much as 90% of the functional innovation in new vehicles, it has become even more important to choose the right devices to meet temperature, quality, and technological requirements. The Xilinx Automotive (XA) range of FPGAs, CPLDs, and configuration devices not only offer the design flexibility and time-to-market advantage associated with programmable logic devices, but also meet the extended temperature requirements and quality standards required in today's automotive advanced electronics systems. The XA device range is offered in both the extended temperature Q-grade (-40ºC to +125ºC) and industrial I-grade (-40ºC to +85ºC) and is qualified to the industry-recognized AEC-Q100 standard (for more information, visit www.aecouncil.com). The XA range includes the lowest power CPLD devices available (CoolRunner-II CPLDs), the lowest cost FPGA (Spartan-3 devices), and Platform Flash configuration memory devices (Table 1). For more information, visit www.xilinx.com/automotive/.

Printable PDF version of this article with graphics.  (4/18/05) 195 KB