Make vs buy in automotive IP
Designing semiconductor IP isn’t easy. An IP block needs to be rigorously defined, designed and tested so that it can work, and be shown to work, in an arbitrary SoC environment. As process dimensions shrink, what was supposed to be a building-block approach to complex functional integration may also be complicated by process dependencies that affect the implementation the IP.
IP for use in automotive environments faces further challenges – meeting increasingly complex functionality and functional safety requirements, and achieving the quality and safety certifications necessary to allow its use.
Functional safety requirements
The automotive industry is increasingly being asked to meet the requirements of the ISO 26262 functional safety standard, which is meant to reduce the chances of unacceptable risk of physical injury or damage to the health of people, directly or indirectly. It isn’t mandatory, yet, but not using ISO 26262 could leave manufacturers open to legal challenges in the event of an accident.
The standard addresses hazards caused by systematic failures in hardware or software, and random hardware failures. Working with the standard means starting the design process by laying out a safety concept that defines what should happen in the event of specific faults or failures. This should be based on a prior risk analysis and a set of safety goals, each of which is then given a set of functional safety requirements. These requirements are then translated into technical safety requirements, which are used to inform the system’s architectural design, such as the hardware/software partitioning.
ISO 26262 includes the concept of an automotive safety integrity level (ASIL), which defines the necessary response to different risks, as measured by the severity of the risk, its likelihood, and its controllability. ASIL is specified in four levels, from least stringent at A to most stringent at D.
ISO 26262 allows for ASIL requirements to be decomposed into the SoC, so that functional safety goals can be assigned for each block. This helps SoC designers develop confidence that they can meet the most stringent ASIL D requirements for a specific application.
Creating ASIL-ready IP therefore means implementing a safety culture within your development organisation, ensuring that safety managers can define safety goals for the block and so build those goals into its requirements before the design process begins.
Verification is also a more complex process requiring, among other things, code coverage analysis and the use of a bottom-up fault modelling and effects analysis (FMEA) process that injects faults into the design to check their effect at the module level. The results of this fault modelling have to be passed up the verification and validation process to form part of a safety manual for the IP block.
Along with ensuring that an IP block has been developed with safety in mind, automotive IP providers also need to qualify the IP for use in real systems.
AEC – Q100 is a standard set of stress tests for qualifying automotive SoCs. Testing automotive IP to AEC – Q100 standard should cut the time and risk involved in qualifying an SoC using the IP to the standard.
Many of the tests apply to the IP when implemented, although a fault-simulation and test-grading requirement can apply to RTL IP.
Implemented IP has to pass tests of issues such as human-body and machine electrostatic discharge, latch-up, memory read/write speeds and data retention, early-life failure rates, and so on. These can be done at different temperatures, with the higher-temperature qualifications presenting a challenge for SoC designers working on advanced processes, in terms of potential issues such as electro-migration.
Testing IP to such rigorous standards is obviously the right thing to do, given the potential cost of failures. But it doesn’t come cheap – a suite of AEC – Q100 tests can cost up to several hundred thousand dollars, depending on the complexity of the block and the technology for which it is targeted.
Everyone documents their work, right? Well, yes and no – it depends on the culture and priorities of their team and company. In the automotive industry, quality is a priority and one way the industry supports this goal is by using the ISO/TS 16949 technical specification and quality-management standard to help identify risks in product-development processes.
To meet the standard, IP developers have to implement a specific set of policies, processes and resources. This is usually a four-phase process:
- In the definition stage, developers need to define the block requirements, determine the quality objectives and plan for deployment
- In the implementation phase, developers need to implement process controls and collect data
- In the analysis phase, developers have to analyse discrepancies and propose effective counter-measures
- In the standardisation phase, developers have to summarise their experience and standardize their procedures
The result of this process is the creation of a set of procedures that use documentation requirements to add rigour to the development process, a strategy that should lead to better quality design implementations.
More complex cores
Despite the fact that companies developing smartphone IP are interested in the automotive market as a new source of growth, automotive IP is not, in general, designed like IP for the general consumer market.
Take, for example, Synopsys’ ARC EM processor cores. These are optimised for ultra-low power consumption, have a three-stage pipeline and high-efficiency DSP, eight enhanced sleep modes, and options to add FPU, MPU, trace, and cache. This processor, in its various configurations, would suit a variety of general-purpose applications.
For automotive applications, however, Synopsys has defined a Safety Enhancement Package (SEP) to add to the block when it is being used in ISO 26262 compliant designs. The ARC EM SEP core adds hardware safety features such as parity and ECC support, a user-programmable watchdog timer, lock-step operation and monitoring, and a memory protection unit. The core comes with a Metaware compiler that has been certified to ASIL D, the most stringent level, for the development of ISO 26262 compliant software, and the related detailed safety documentation.
The combination of extra functional complexity and rigorous qualification procedures means it takes more time to bring automotive IP to market than normal.
Meeting the requirements of the automotive industry as an IP developer means developing a culture that respects safety thinking, accountability, standard testing requirements, qualification procedures, review processes and more. It also means developing a culture that lives these values in practice – one of our customers spent a week in our labs recently to satisfy itself that we are meeting the standards we claim to.
Synopsys has recognised the opportunity that the automotive market offers, and is developing a portfolio of IP to meet the ASIL B Ready requirements. First members of the family include DesignWare Ethernet AVB, LPDDR4, embedded memory IP, MIPI CSI-2 and DSI, HDMI, PCI Express, USB, and mobile storage.
The IP is delivered with safety packages including a complete set of ISO 26262 certified safety plans, manuals, guidelines, and safety reports such as FMEDA reports so designers can more easily show their automotive SoCs comply with the standard.
To develop this IP, Synopsys has had to invest heavily in understanding the needs of the market and developing the infrastructure, procedures, and relationships necessary to meet them. Companies that may not have the opportunity to amortise that effort across many uses may want to think long and hard about whether they should make or buy their automotive IP.
Find out more about Synopsys’ automotive IP at http://www.synopsys.com/IP/market-segments/automotive/Pages/default.aspx
Jai Durgam joined Synopsys in 2005 and is currently the Group Director of worldwide field applications for the Solutions Group, responsible for interface IP, processors, foundation IP and virtual prototyping products. Most recently, Jai has also been driving the automotive market strategy for Synopsys’ Solutions group. Prior to this role, Jai was the Senior Director for Synopsys’ Applications Consulting group in India. Jai has over 27 years of experience in semiconductor design and EDA industries and has held executive-level roles at Scintera Networks, Silicon Image and National Semiconductor. Jai has a Bachelor’s degree in Engineering from REC Tiruchi, India and a Master’s Degree in Computer Engineering from Oregon State University at Corvallis.