High-Quality Automotive IC Design with IP Subsystems

By: Ralph Grundler, Product Marketing Manager, Synopsys; Antonio Salazar, Sr. Engineer, Synopsys

Although automotive electronic systems such as infotainment and motor control have met the requirements for stringent automotive standards, AEC Q100 and IATF 16949 (formally ISO/TS 16949,) advanced driver assistance systems (ADAS) is accelerating the adoption for functional safety standard ISO 26262. ADAS systems (Figure 1) are the basis for tomorrow’s autonomous driving vehicles and require these systems to communicate together while following a strict set of automotive standards. These automotive standards drive to augment safety, reliability and quality, while addressing several automotive specific requirements involving the different phases of the product’s lifecycle. 

Figure 1: Examples of ADAS systems 

Although these standards consider an automotive system as a whole, designers often need to consider the standards from a system-on-chip (SoC) perspective and the implications for lower hierarchical levels. When implementing IP subsystems into an SoC, designers require hierarchical traceability and interoperability. Working with an IP supplier who provides IP that a) complies with the applicable standards bodies, and b) meets the stringent automotive requirements, can greatly accelerate the IC’s time-to-market.

This article will describe automotive standards and requirements, from both a system and SoC level as well as implications for lower hierarchical levels. It will show what designers need to require of third-party IP providers, including safety processes and documentation. Finally, the article will describe how working with an IP supplier that provides IP that complies with the applicable standards and meets stringent automotive requirements, can build IP subsystems that enable faster time-to-market and higher quality.  

Automotive Functional Safety, Temperature & Quality Standards

While requiring safety standards for automotive applications is obvious, implementing such considerations into an electronic system, the IP, or IP subsystems within the SoC, is not straightforward. The first step in this process is understanding specifications. The main applicable specifications are ISO 26262 and ASIL levels, AEC Q100 reliability, and IATF 16949 quality.

• ISO 26262 & ASIL Certification: ISO 26262 is the functional safety standard that addresses possible hazards caused by malfunctioning behavior of electronic systems in automobiles. Automotive Safety Integrity Level (ASIL) defines one of four levels to specify the SoC’s ISO 26262 requirements and safety measures; the four safety levels are ASIL A, B, C and D, and Quality Management (QM) level (Figure 2). ASIL A represents the least stringent level of requirements and ASIL D represents the most stringent level. Typically, automotive applications that don’t have a direct impact on safety will require a QM level, while critical applications (e.g., braking and steering) will require ASIL D quality.

Figure 2: QM and four ASIL levels, showing the lowest to highest risk potential

• AEC Q100 Testing: AEC Q100 is based on IEC and JEDEC specifications which is extended for automotive applications. The AEC Q100 outlines the stress tests and reference test conditions for the qualification of automotive grade ASICs. One example is automotive temperature requirements that are in shown in Table 1.  ASICs made for consumer products typically are designed to operate from 0°C to 70°C and cannot be used in automotive applications. This specification serves to eliminate misunderstandings between manufacturers and purchasers, facilitate interchangeability, product improvement, environmental quality, and minimize product selection process.  Applying these tests to IP and IP Subsystems reduces the time to converge on the testing requirements when the chip arrives for testing. 

Table 1: Temperature ranges for AEC Q100 grades

• IATF 16949 Quality Management: This standard identifies risks in product development processes based on ISO 9001 but specifically for automobiles. Fully supporting IATF 16949 development requirements means implementing policies and processes, and assigning resources. IATF 16949 results in developing a safety culture in the company and producing quality metric documents such as Design Failure Mode and Effects Analysis (DFMEA).

Applying Requirements & Standards to IP Subsystems

When selecting IP or IP subsystems, automotive designers need to ensure that the provider has the necessary processes and infrastructure. While at the design level this might imply monitors, redundancy, or observability, the IP provider must have a “Safety & Quality Culture” to detect, manage and address possible hazards, and associated quality management systems that quantifies and qualifies errors, and standards of communication to minimize misinterpretations.

In the automotive system creation process, safety becomes part of everything and the ISO 26262 V lifecycle (Figure 3) emphasizes Management of Safety, Concept Phase, Development of Hardware and Software, Production, Supporting Processes and Analysis.

Figure 3: Functional safety processes and procedures

Although these standards consider an automotive system or component, their implications are felt at all levels of the design. Faults within an electronic design are commonly addressed by multiple strategies that consider detection, localization and recovery. Methodologies for designing, traceability, testability and redundancy identify and resolve fault scenarios. That said, the overall context is more involved: automotive electronics go beyond monitoring elements and recovery mechanisms. A holistic approach promotes predictability on the associated processes to ensure all stages of the product development follow a systematic approach.

While the standards are independent, they do reference each other and have some interdependencies.  For example, ISO 26262 references IATF 16949 as a quality management process.  Analysis done in IATF 16949 can be used as supporting documentation for ISO 26262 compliance by providing the evidence of quality management.  By implementing these processes as part of the development process, automotive IC designers and OEMs can more easily reach their safety goal. 

Working with an IP Supplier to Meet Standards with IP Subsystems

Designers of automotive ICs need to consider opposing forces during planning. In a “top down” view, designers must consider both SoC design elements and the safety documentation that will enable the automotive IC design to meet the automotive specifications. On the other hand, they must consider a “bottom up” approach to visualize how coverage closure can be achieved along with the required Failure Modes, Effects, and Diagnostic Analysis (FMEDA) reports, verification, etc. (Figure 4).

Figure 4: SoC development for automotive applications requires simultaneous “top down” and “bottom up” methodologies

In today’s electronics, IP subsystems play a significant and increasingly complex part of the design equation. While IP is continuously increasing in complexity due to the market’s demand for an ever-increasing number of features, their number per SoC also has been increasing.

To assist automotive IC designers, IP providers such as Synopsys actively collaborate with their customers to address more than just the simple IP blocks. By engaging at the subsystem level, all parties can consider hierarchical elements such as traceability and observability and understand complex scenarios such as clock domain crossing issues, reset domains, power management, testability, etc. In addition, the IP provider can offer options that will help the designer meet their safety goals.

Observability is a functional requirement of error recovery or reset to meet a design’s safety goals. By adding functionality such as debug, performance monitors, and watch dog timers in the IP subsystem, the SoC or the system software can decide on the best mediating action when a fault occurs that requires recovery to a safe state. Often this can enhance the possibility of graceful recovery or local reset where the rest of the system is not affected. Other opportunities to leverage observability are measuring performance or fine tuning performance to make sure the needs of the complete system are met either in different systems or different operating modes.

For automotive designs, documentation is critical. From safety documentation to test plans, checks for linting errors, Clock-Domain Crossing (CDC) and Reset Domain Crossing (RDC), thorough documentation helps ensure that the implementation is clear and more seamless. When running required checks on the final SoC, the SoC engineer has these documents as reference should any questions arise about the IP subsystem implementation.

When building IP subsystems for automotive applications, the IP provider will first want to fully understand the customer requirements to help assure that integration, testing, and integrity checks go smoothly all the way to tape out. Experts in the IP with a system understanding engage with customers at all technical levels to ensure their SoC requirements are met, and evaluate what is needed beyond documentation to reach the required levels of safety.