草榴社区 Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
With the rise of advanced driver assistance systems (ADAS) and autonomous driving features comes an increased need to ensure that all elements of the car – from software to hardware – will work as intended and in a safe manner. That’s why the development of increasingly complex automotive designs for functions to avoid roadway obstructions, brake when needed, and self-park is guided by stringent functional safety standards such as ISO 26262.
Driving safety, security, reliability, and quality in software-defined vehicles is a massive undertaking, traditionally involving time-consuming, manual efforts. Design houses need a way to simplify and streamline the implementation, verification, and validation of their systems. Traceability — confirming that implementation and verification have satisfied requirements — is also essential for safety-critical systems.
In this blog post, I’ll share news about a new automated capability, a part of 草榴社区’ safety-aware solution for random hardware faults, which eases ISO 26262 compliance.
What Makes ISO 26262 Compliance So Challenging?
ISO 26262 mandates a functional safety development process applicable to all stages of the automotive safety lifecycle, such as during development, production release, and decommissioning. The standard ensures that safety is considered from the very start. Automotive OEMs and suppliers must develop, follow, and document their processes to have their devices qualified for use in road vehicles. The standard is guided by a risk classification system—automotive safety integrity levels (ASILs) that establish safety requirements based on the probability and acceptability of harm―to mitigate risk for automotive systems or elements of the system. Meeting ASIL standards reduces the risks that stem from electrical and electronic (E/E) systems.
One of the big challenges to achieving ISO 26262 compliance is the exhaustive documentation and supporting evidence required to demonstrate that safety goals have been met. At the development phase to prevent systematic faults, engineers must use robust software tools that do not introduce design bugs and that do not fail to report design bugs. Random faults must also be addressed. Manufacturing teams must ensure there are zero defects in the part and that, in operation, safety mechanisms will trigger in the presence of faulty behavior and be effective in reaching a safe state.
In a traditional flow, engineers would manually insert some hardware safety mechanisms into the register-transfer level (RTL). After implementation and verification, they would provide documentation to prove that the safety goals have been achieved. They might use spreadsheets to track the hundreds or thousands of requirements. For designs with a lot of redundancy—a common scenario for safety-critical applications like automotive—this amounts to a substantial amount of manual effort with the potential for human error. Teams are often spread across different geographies, which further complicates the workflow.
As an example, consider a dual-core lock-step (DCLS) system, a common hardware safety mechanism. The DCLS provides a fault-tolerant, redundant system consisting of two independent processors that run the same set of operations and a comparator logic to check that the outputs of the processors are the same. While the two processors are functionally equivalent, they must be physically separated, avoid routing overlap, and have independent clock trees to ensure that a transient fault will not cause a failure in both processors at the same time. Duplicating the original logic element often involves hand coding the RTL and scripting to ensure that the synthesis tool does not optimize out the redundancy. Additional scripting is typically needed in the implementation phase to ensure that the standard cells and routing are separated; implementation engineers essentially must guide tools and flows for functional safety. Meanwhile, verification tools have typically been unaware of the intent of functional safety mechanisms inserted or not yet inserted into RTL.
Automotive designs may have multiple DCLS systems, and there may be as many as tens of thousands of other safety mechanisms such as triple mode redundancy (TMR) registers and error correction code. Imagine all of the hand coding and scripting required to ensure the thousands of instantiations required to satisfy functional safety requirements!
Automating Safety Mechanism Implementation to Meet Requirements Faster
Designers have shared some common asks in their quest to comply with functional safety requirements as quickly and safely as possible:
- An automated, flexible requirements management and documentation process, with closed-loop traceability, to reduce the number of verification and validation reviews
- An easier way to identify where safety mechanisms have been applied and that they have been applied correctly, and that structures are adequately protected, to ease traceability
- An end-to-end flow to efficiently validate that safety requirements are met during implementation, design reviews, and verification and validation steps to provide coherency and consistency
- Easy and efficient design re-use across modules in IP and across IP blocks in an SoC to speed up the process
草榴社区 has automated the process of implementing and verifying functional safety mechanisms via our newly launched safety specification format (SSF) for ASIL D-compliant SoC designs. SSF describes safety intent, such as hardware safety mechanisms and their attributes, through a common interface across different tools in 草榴社区’ Safety-Aware Solution. After being manually or automatically generated, SSF can be used in RTL generation, analysis and verification tools, and digital design tools, to ensure that safety requirements are met at every phase of the design cycle.
草榴社区’ Safety-Aware Solution includes 草榴社区 VC Functional Safety (FuSa) Manager, a scalable and automated solution for Failure Modes and Effect Analysis (FMEA) and unified fault campaign management with comprehensive fault injection and simulation to produce reliable metrics for Failure Modes, Effects and Diagnostic Analysis (FMEDA). The flow encompasses solutions spanning architecture to RTL to gate-level netlist and follows these steps:
- RTL generation: Automatically insert safety mechanisms, such as DCLS; automatically connect error and warning signals to the on-chip safety manager through the FuSa subsystem
- RTL analysis: Fast, early power, congestion, timing, area, and safety estimates
- Verification: Virtually instrument safety mechanisms into RTL and verify design for safety with simulation and graphical debug; formal equivalence checking based on safety intent
- Physical implementation and signoff: Automated synthesis and place-and-route of safety mechanisms; automated safety error reports to ensure that implementation is true to safety intent
SSF is generated by 草榴社区 TestMAX? FuSa, selected DesignWare? IP, and VC Functional Safety Manager, or can be generated by the user.
Physical implementation is accomplished using 草榴社区 Fusion Compiler, an RTL-to-GDSII digital implementation solution with a unified architecture that delivers 20% better quality of results and 2x faster time-to-results for advanced designs.
Enabling the end-to-end Safety-Aware Solution with SSF delivers an array of benefits through automation:
- Improves traceability by automating time-consuming and error-prone steps such as RTL generation, analysis, verification, implementation, and creating work products and supporting evidence
- Reduces or eliminates labor-intensive custom tool scripting, which can degrade time-to-results and quality-of-results
- Provides scalability for 草榴社区 or third-party IP design re-use
- Extends to non-automotive applications, such as client-server and industrial IoT
Summary
With the increasing prevalence of electronic components inside today’s cars, ensuring that those components will perform as you expect them to is a key requirement toward getting vehicles on the road. Complying with automotive functional safety standards is typically a time-consuming, manual process. Automation, however, streamlines the process, helping to get safer automotive systems out the door in less time and effort.