Data Converters For Automotive Applications

Sensor applications requiring data converters range from temperature sensors identifying different engine status to radar/LIDAR enabling Automotive Driver Assistance Systems (ADAS). Other applications involving data converters include wireless transceivers for communicating with other vehicles or with a fixed network. The data converter IP (analog-to-digital and digital-to-analog) provides an interface for multitude of analog sensors to automotive system-on-chips (SoCs). For ADAS, the electronic systems and their components, like SoC and IP, must deliver the utmost in reliability and safety, while enduring extreme temperature ranges and demonstrating longevity. Due to this reason, automotive electronic systems and their components must adhere to a set of stringent automotive standards for reliability and functional safety.

This article briefly describes the automotive reliability standard, and will focus on efficient and optimized procedures for meeting automotive requirements by judicious partitioning of the functional safety requirements between the IP, such as data converters, and the SoC functional blocks that include the IP.

Design for reliability
The Automotive Electronics Council (AEC) has developed a set of qualification standards for the automotive industry. The AEC-Q100 standard defines the required temperature grades that SoCs and their components like IP must support. Temperature grades range from grade 0 to grade 3, depending on the maximum ambient temperature in which the SoC or IP is expected to properly operate (see Table 1).

Table 1: Definition of ambient temperature grades 

For automotive SoC or IP circuit simulation, designers must translate ambient temperature into junction temperature. An accurate translation must consider the average activity in the SoC (the average power it dissipates) as well as the packaging thermal resistance, which measures its ability to remove thermal energy from the die and dissipate it in the environment (temperature difference between the die itself and the ambient). To measure the temperature effect on a device (SoC or IP), a temperature profile is designated to measure the expected time the SoC or IP is in operation at any given temperature range during its lifecycle.

Besides meeting temperature requirements, components must also meet the maximum failure rate. The failure rate is measured by defects parts per million (dppm) with a requirement of less than one dppm throughout the automotive product lifecycle of 15 years. The dppm considers the following key aspects:

• Design variability refers to the variation of certain manufacturing process characteristics leading to device mismatch. It affects the SoC both locally (random variations) and across the die (gradient effects). To meet the low failure rate, the Monte Carlo statistical simulation of the critical blocks analyzes the extremes of the mismatch distribution (e.g., up to 5*sigma).
• Transistor aging refers to the changes in the transistor characteristics that make up the SoC as a function of the time of operation and the conditions of operation during that time. It is the results such as HCI (Hot Carrier Injection), NBTI (Negative-Bias Temperature Instability), PBTI (Positive-Bias Temperature Instability), that vary the threshold voltage of the transistor as a function of the operating conditions during its lifecycle. It must consider the mission profile, the total number of Power On Hours (POH) expected for the transistor, and the low failure rate requirements for automotive applications. During the design phase, the target failure rate is met by running simulations including effects of aging during the equivalent POH at the defined temperature.
• Electromigration is the displacement of the conductor atoms in the interconnect wires and contacts when a significant current density is present, changing the resistivity of the interconnect trace (possibly event breaking it) and the timing characteristics of the circuit. Electromigration effects also depend on the temperature profile and the total number of POH expected for the SoC. Specific simulation models verify the absence of electromigration issues during the lifetime of the SoC.

In addition to the above, instantaneous operation at the expected maximum functional temperature must be guaranteed, even if the temperature profile indicates that the SoC or IP may operate at that temperature only for a small fraction of the total operating time. This requirement ensures that when the SoC or IP is operating at a maximum temperature it meets functional and performance specifications, while for example, no timing violations occur that could limit functionality.

Design for functional safety
ISO 26262 qualification applies to any automotive SoC or IP for safety-critical ADAS applications, and defines the functional safety of a SoC or IP within the targeted Automotive Safety Integrity Level (ASIL) from A (lower risk potential) to D (highest risk potential). SoCs or IP for automotive ADAS applications must implement safety features, in line with the intended ASIL. Key functional safety considerations for automotive IP include:

• Can the IP detect, report and self-correct a fault? Making use of functionality such as Error Correcting Code (ECC) checking, majority voting, some forms of local redundancy, etc. can help detect and correct faults
• Can the IP detect a fault and report it in an acceptably short time to enable other levels of the system to execute safety measures in time?
• Can external measures be put in place to protect the system at a level above the IP?

Functional safety aspects for data converters
A data converter implements low level functionality, such as interfacing with an analog sensor with the single purpose of converting an analog signal, to its digital representation for processing in other SoC blocks. Automotive radar, LiDAR, and cameras are examples of analog sensors that require an ADC interface. Since the analog signal generated on the sensor is unknown and does not carry any protocol or error correction information, then traditional protocol-level fault detection and correction mechanisms are not applicable. The analog-to-digital converter (ADC) does not have processing capabilities or knowledge of the signal dynamics to determine if that signal is corrupted or not. Self-testing of the ADC may not apply because it often interrupts the normal operation of the ADC to run foreground tests. For such low-level functional blocks, automotive safety aspects must be addressed in alternative ways. Characterization and production testing can identify potential faults, impacting the product functionality and performance. Functional faults, described by fault models such as Single-point fault, Latent-fault, etc., introduced by manufacturing defects, can be identified using Automatic Test Pattern Generation (ATPG) test methods with high coverage. For data converters tests, such as sweep of a ramp input signal, for complete range checking during characterization, and the use of pure sinusoidal input signals for fast operational check in production test, can help identify fails on analog blocks with high coverage.

Operational fails that affect the ADC but are triggered only in normal operations can be efficiently detected and reacted to at the system level with the assistance of test features implemented in the ADC:

• Detection of output stuck fault conditions (if output word is fixed at a constant level)
• Detection of long latency fault condition (for triggered conversions)
• Detection of incomplete calibration fault condition (for calibrated converters)
• Detection of incorrect conversion of known input voltages (using dedicated input channels in an input multiplexer (MUX) to provide fixed input levels for test), as shown in Figure 1.

Figure 1: Measuring known voltage with MUX to detect failures

To meet automotive functional safety requirements, the described methods mentioned above may be insufficient to achieve high coverage and should be complemented with the application of additional external functional safety measures. The external functional safety measures identify and address the ADC’s safety risk at the system level without impacting the overall system safety. One such external functional safety measure for ADCs, while identifying operational fails, is functional redundancy. Functional redundancy constantly checks the output consistency of two signal paths running in parallel. If inconsistency is detected, then the system knows that there is a fail and should act upon that fail to eliminate functional safety concerns. In Figure 2, two data converters are used for functional redundancy. The same sensor output signal is processed through two independent converters; the system checks the results for consistency.

Any of these implementations improve system-wide functional safety coverage, even when it may not be desirable or efficient to implement these measures internally to individual blocks such as the ADC. In the three examples shown, redundancy extends from the ADC to the sensor. Extending redundancy extends the reach of the external safety measures to all redundant blocks, reducing requirements for internal functional safety measures for the individual blocks at the expense of duplicating these blocks.

Figure 2: Functional redundancy for identifying operational fails in the ADC

Conclusion
To meet the reliability and functional safety requirements of automotive ADAS applications, IP and SoC designers must meet all mandated automotive requirements as defined by AEC-Q100 and ISO 26262 standards. A good understanding of such requirements and how to efficiently implement them in the SoC enables integrators to break down the challenges into manageable pieces while leveraging the characteristics (and qualifications) of the integrated IP to achieve automotive qualification and accelerate SoC-level certification. Alternative ways of achieving functional safety goals while using functional blocks such as data converters, where implementation of internal safety features may be impossible or undesirable, help achieve SoC-level functional safety goals. For more details, read the Data Converter IP for Automotive SoCs white paper.