• • • TEST & MEASUREMENT • • •


Why verification of SoCs is critical in high integrity applications


By Enrique Martinez, Functional Safety manager and Mixed-Signal SoC Expert at EnSilica


High integrity/reliability electronic systems (hi-rel) refer to applications where failures are simply not an option


M


any of these applications are driven by a dedicated system-on-chip (SoC) which incorporate processing units, memory,


analog, RF, and more in devices containing millions of transistors and thousands of embedded code lines. Such high numbers are understandably daunting; how can be sure that nothing will go wrong? Some of the most infamous accidents in the


aviation or automotive fields have been attributed to bugs in vehicle control hardware or software. The Boeing 737 MAX incident led to pilots losing control of the aircraft due to a faulty sensor reading, causing two fatal crashes and grounding the 737 for more than a year while investigations took place. The Toyota “unintended acceleration” problem in 2009 led to numerous deaths and the emergency recall of around 10 million vehicles. Both incidents led to lengthy and expensive lawsuits against the involved companies. Design vulnerabilities have since come to light, which point to insufficient verification of the electronic systems involved. This sends a very clear message: we still have a lot of learning to do when it comes to the design and deployment of hi-rel electronic systems.


Some changes are required in


the development process Having a robust development process is a must when dealing with hi-rel systems. From top-level requirement specifications to detailed implementation, having a clean documentation management system with full traceability will ensure that any changes along the design cycle are properly monitored, analysed, and approved. The so-called V-Model, which splits the development process into design, implementation, and integration/testing, is commonly used to guide this process. But more can be done. A deep analysis of how things can fail, the


consequences, and remedies is absolutely necessary. This can be achieved by using standard techniques like the FMEA (Failure Mode Effects Analysis) and/or the FTA (Faults Tree Analysis). The relevant standards of these approaches require developers to provide objective evidence of the achieved level of safety through specific metrics, like unsafe FIT rates, the SPFM (Single Point of Failure Metrics), or SFF (Safe Fault Fraction). Several industry standards have already been


published around the concepts of reliability and functional safety with the purpose of ensuring that


22 ELECTRICAL ENGINEERING • OCTOBER 2024


compliant products will be safe. For instance, the automotive standards ISO 26262 and ISO/PAS 21448 (SOTIF) apply to most of the non- entertainment electronics present in car: engine control, braking (ABS), airbag, radar/lidar anti- collision systems, and especially to the newest generation of ADAS system. Industrial control systems must also follow the IEC 61508 standard when safety is critical, and robotic systems are particularly subject to an adapted standard: the ISO 13849. What do these standards have in common? The


need for a tight control of all the design and verification processes, the analysis of how things can fail, and the adoption of new approaches to the hardware and software development methodologies. With this in mind, the verification phase becomes a crucial milestone in achieving both reliability and functional safety.


The critical role of verification Verifying the correct behavior of a SoC against the specified safety or reliability requirements is probably the most critical step in the chip product life-cycle, and the previously mentioned standards dedicate entire sections to this topic. At either the


electricalengineeringmagazine.co.uk

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50