Designing semiconductor IP isn\u2019t 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.<\/p>\n
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.<\/p>\n
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\u2019t mandatory, yet, but not using ISO 26262 could leave manufacturers open to legal challenges in the event of an accident.<\/p>\n
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\u2019s architectural design, such as the hardware\/software partitioning.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
AEC – Q100<\/a> 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.<\/p>\n Many of the tests apply to the IP when implemented, although a fault-simulation and test-grading requirement can apply to RTL IP.<\/p>\n 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.<\/p>\n Testing IP to such rigorous standards is obviously the right thing to do, given the potential cost of failures. But it doesn\u2019t come cheap \u2013 a suite of AEC \u2013 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.<\/p>\n 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<\/a> technical specification and quality-management standard to help identify risks in product-development processes.<\/p>\n To meet the standard, IP developers have to implement a specific set of policies, processes and resources. This is usually a four-phase process:<\/p>\n 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.<\/p>\n 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.<\/p>\n Take, for example, Synopsys\u2019 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.<\/p>\n 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.<\/p>\n The combination of extra functional complexity and rigorous qualification procedures means it takes more time to bring automotive IP to market than normal.<\/p>\n 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.<\/p>\nBetter<\/strong> quality<\/strong><\/h2>\n
\n
More complex cores<\/strong><\/h2>\n
Culture<\/strong><\/h2>\n