Cloud native EDA tools & pre-optimized hardware platforms
Rupal Gandhi, Technical Marketing Manager, Synopsys
Automotive OEMs are building advanced driver assistance systems (ADAS) to improve safety. ADAS systems must meet stringent performance, power and cost requirements, so the system-on-chips (SoCs) that make up ADAS and passenger safety systems integrate advanced protocols and are built on leading edge FinFET process technologies. Designers of this new class of ADAS SoCs are challenged to meet ISO 26262 functional safety requirements while shortening design and maturation cycles. In addition, ADAS SoCs are evolving from being distributed in electronic control units (ECUs) around a vehicle, to being consolidated in centralized domain controller modules. Domain controllers can be used for connectivity, comfort or powertrain domain as shown in Figure 1. Consolidating functionality into domain controllers has led to previously distributed functions being merged into a larger gate count, high-performance centralized SoCs that must support different types of serial and parallel interfaces. With a possible single point of catastrophic failure due to external aggressors such as electrostatic discharge (ESD), designers are carefully selecting IO libraries that meet or exceed the SoC’s required functional safety, reliability and quality metrics.
Figure 1: Automotive systems are transforming from distributed ECUs to centralized domain controllers, putting more demands on a single point of potential failure
General-purpose IO (GPIO) and Specialty IOs (I2C, I3C, LVDS) are an essential part of centralized domain controllers as they provide a standard interface between chips. The IO library is placed as a ring around the SoC, enabling power and signal connections to the board and providing critical protection to the SoC against electrical disturbances such as ESD events or latch up. Figure 2 shows a common domain controller case study where the CPU interfaces with digital sensors via I2C, and analog sensors via GPIO.
Figure 2: Domain controllers use a variety of IOs to communicate between sensors and chips
This article describes the use of GPIOs in automotive applications and how automotive-qualified GPIO solutions can help designers accelerate time-to-market and reduce risk.
The ESD qualification for GPIOs includes Human Body Model (HBM) > 2KV, Charge Discharge Management (CDM) >5A and Latch up (+-100mA). All three must comply with AEC-A100-002-REV-E, which is done in accordance with the ANSI/ESDA/JEDEC JS-001 specification. To comply, HBM needs to meet stress levels of 500V, 1kV and 2kV without skipping. In addition, designers perform Pass/Fail testing before and after ESD at room and hot temperature. The tests carry out a full check of the device specification, including complete DC parametric and function testing, so total test coverage is important. To ensure latch up compliance, designers perform AEC qualification testing at the maximum ambient operation temperature.
To pass this suite of thorough tests, the SoC’s GPIO library needs to support ESD structures to manage different scenarios between core and supply voltage. For example:
In the event of an ESD strike, the ESD diode would turn on and create a low impedance path that limits the peak voltage and current by diverting the current flow to ground, thereby protecting the SoC. To protect from ESD breakdown, the GPIO needs to be equipped with special ESD clamps, such as shown in Figure 3. Figure 3 shows the ESD protection scheme for automotive-grade GPIOs. The GPIOs include a conventional RC-trigger clamp and an N-diode between Pad and Ground to support negative zap ESD. The back-to-back diode supports cross-domain ESD. In addition to GPIOs, this ESD protection scheme can be used for specialty IOs such as I2C, I3C and LVDS.
Figure 3: ESD protection scheme for automotive-grade GPIO IP
At system level, to mitigate ESD risk, SoC designers may use additional techniques such as including bypass capacitors, common mode filters, ferrite beads and/or isolation resistors.
The Automotive Electronics Council (AEC) defines reliability tests of automotive ICs in the AEC-Q100 specification. AEC-Q100 defines failure mechanism-based stress test qualification. For SoCs, it defines the minimum stress-test-driven qualification requirements and references test conditions for qualification.
To meet the AEC-Q100 standard and adhere to the functional safety needs of the specific application, automotive SoC teams have to design to a certain temperature grade. Grade 0 is the most stringent standard and specifies an ambient temperature range from -40ºC to +150ºC. SoCs required to reach Grade 0 must integrate IO libraries that have been characterized across this broad temperature range with sufficient design margin to offer low defective parts per million (DPPM) reliability.
In addition to AEC-Q100, some foundries require the IP to meet their own acceptance standards, which specifies requirements for validation and qualification of parts based on statistical analysis of a minimum number of samples across multiple process splits. Based on the foundry’s recommendation for a particular process, IP vendors may enhance their automotive grade GPIOs through techniques such as five sigma design margins with Monte Carlo simulation in design for variation across process, voltage and temperature.
Failure Mode and Effects Analysis (FMEA) further complicate safety certification. The Synopsys DesignWare® IP portfolio with safety packages is ASIL B ISO 26262 certified and designed for use in safety-critical applications while meeting AEC-Q100 requirements. DesignWare GPIO IP safety packages include failure modes effects and diagnostics analysis (FMEDA) reports, safety manuals, and certification reports to accelerate safety assessments and help reach customer target ASILs. These reports provide evidence of meeting higher safety requirements with lower risk of violation for systematic fault of the hardware elements.
Synopsys DesignWare General-Purpose IO and Specialty IO (I2C, I3C and LVDS) IP contain all the functions and cell types needed for designers to create complete IO pad rings for automotive SoCs in either wire bond or flip-chip packaging. Designers prefer Synopsys IO libraries because:
Automotive trends are driving toward developing centralized domain controllers featuring complex ADAS processors that perform multiple functions and interface with a variety of different inputs. To support automotive inputs while protecting passenger safety, IO libraries must protect the domain controller SoCs from aggressors such as ESD. To meet stringent ESD targets and automotive requirements, IP vendors must employ special IO design techniques. Standards such as AEC-Q100 and JEDEC mandate additional IO design and test requirements. Synopsys DesignWare General Purpose IO and Specialty IO (I2C, I3C and LVDS) are well suited to meet these requirements while meeting functional safety, reliability and quality standards, helping designers accelerate time-to-market and reduce risk.