HWNEWS
A gap in how safety analysis data moves between chip designers, tool vendors, and car companies has become a structural bottleneck as safety critical chips proliferate.
Chip design has been automated end-to-end for years. The safety data that proves a chip is safe to put in a car, a hospital, or a plane still moves in spreadsheets, PDFs, and tool-specific formats. The industry is starting to call that the next structural chip-supply problem.
That gap matters because the chips in question are the ones whose silent failure can kill or injure. They run anti-lock braking, advanced driver-assistance systems, infusion pumps, factory robots, and flight-control computers. Engineering teams label them "safety-critical." The standards that govern them, including ISO 26262 for cars and IEC 61508 for industrial systems, define what has to be true for a chip to be considered safe. They do not define how the underlying analysis data should be represented and exchanged between the chip designer, the EDA tools that verify the design, the silicon vendor, and the system integrator who drops the chip into a car or a device.
In practice, the safety analysis follows the chip across that chain in a fragmented way. A Failure Modes, Effects, and Diagnostic Analysis (FMEDA) might be authored in one company's proprietary tool, exported as a spreadsheet, re-keyed into a customer template, and translated again when the chip moves to a different EDA flow downstream. The same work, done multiple times, by different teams, in different formats. Engineers call the discipline "functional safety," and the analyses that support it go by acronyms such as FMEDA, FMEA (Failure Modes and Effects Analysis), FTA (Fault Tree Analysis), and DFA (Diagnostic Failure Analysis). Each is a structured reasoning exercise about how a chip can fail, how likely that failure is, and whether the design's built-in diagnostics catch it.
The standards say all of that has to happen. They do not say it has to happen in a machine-readable way. A Semiconductor Engineering analysis drawn from the experience of working engineers and tool vendors points to a recurring result: duplicated effort, lost traceability, custom interfaces between proprietary tools, and an elevated risk of inconsistencies that only surface when a customer audits a supplier's safety file.
Engineers spend valuable time translating and interpreting safety data rather than performing high-value safety analysis. Tool vendors must build custom interfaces for each proprietary format. Suppliers and customers end up aligning by email and PDF review, which complicates automated validation. None of that is a bug in any one product. It is what happens when a safety discipline has converged on a shared definition of correctness but not on a shared format for the evidence that demonstrates it.
That is where Accellera Systems Initiative, the industry consortium that has long produced EDA interoperability standards, comes in. Its Functional Safety Working Group is positioned as the natural venue to define a common, implementation-level language for safety data: a format that any EDA tool could read and write, that any chip designer could hand to any customer, and that any auditor could trace end-to-end without a manual translation step in between. The working group's scope language, hosted on Accellera's site, uses the same terms as the trade-press analysis. The definition of safety is settled. The format for the evidence is not.
Every new generation of safety-critical silicon, from ADAS domain controllers to surgical robots to electrified aircraft control surfaces, adds another layer of analysis that has to cross another organizational boundary. If the underlying data exchange stays document-centric, the cost of that crossing scales linearly with the number of chips, the number of tools, and the number of customers. The working group exists because the industry has decided that scaling is no longer free.
The next concrete signal is a working draft of a common data-exchange format from the Accellera Functional Safety Working Group that chip designers, EDA vendors, and OEM customers can pilot on a real program.