Accellera’s new Functional Safety Language 1.0 draft is now open for public review through August 14, 2026, proposing a vendor-neutral way to exchange the safety data behind semiconductor designs used in cars, industrial equipment, medical devices, and aerospace systems.
The draft targets a stubborn engineering problem: safety evidence still moves through spreadsheets, custom scripts, proprietary databases, and incompatible EDA tool formats. Semiconductor Engineering outlined the issue in a July 27 opinion by Alessandra Nardi, chair of Accellera’s Functional Safety Working Group: analyses are frequently recreated or manually translated as chips, IP blocks, and verification results move between suppliers, chip vendors, toolchains, and system integrators.
For engineering teams using Windows workstations to run EDA, requirements-management, simulation, and document-control tools, this is not an operating-system feature announcement. It is potentially more consequential: a common data model could reduce the hand-built import/export glue that sits between safety specialists and the design-and-verification flow.
Accellera says Functional Safety Language, or FSL, defines syntax and semantics for representing and exchanging functional safety intent, initially concentrating on Failure Modes, Effects, and Diagnostic Analysis data. FMEDA is the analysis used to identify component failures, their consequences, diagnostic coverage, and related reliability assumptions.
The longer-term plan encompasses related safety analysis methods, including Fault Tree Analysis and Diagnostic Failure Analysis. That scope matters because a chip safety case is rarely a single document; it is a chain of evidence connecting IP-level assumptions to the finished system.
FSL is not positioned as a replacement for ISO 26262 or IEC 61508. Those standards establish the safety-development expectations. Accellera’s proposal instead addresses the practical interchange layer they leave open: how safety data is represented consistently enough to travel between organizations and tools without being reinterpreted every time.
Today, that linkage is often weakened when information is copied from one workbook, report, or vendor-specific environment to another. A standard format does not make the underlying analysis correct, but it can make omissions, mismatched assumptions, and stale data easier to identify and validate.
For EDA vendors, the attraction is equally direct. Rather than creating and maintaining separate proprietary interfaces for every major customer and supplier, they could support a shared interchange model. Whether that promise is realized will depend on adoption by tool vendors, IP providers, semiconductor companies, and the system integrators that ultimately need the safety evidence.
That timeline makes the current review more than a procedural step. FSL will only reduce translation work if its data model can represent real-world FMEDA inputs and outputs without forcing users back into side spreadsheets and undocumented conventions. The deadline is therefore the industry’s chance to test whether the proposed language is precise enough for production safety flows—not merely clean enough for a specification.
The draft targets a stubborn engineering problem: safety evidence still moves through spreadsheets, custom scripts, proprietary databases, and incompatible EDA tool formats. Semiconductor Engineering outlined the issue in a July 27 opinion by Alessandra Nardi, chair of Accellera’s Functional Safety Working Group: analyses are frequently recreated or manually translated as chips, IP blocks, and verification results move between suppliers, chip vendors, toolchains, and system integrators.
For engineering teams using Windows workstations to run EDA, requirements-management, simulation, and document-control tools, this is not an operating-system feature announcement. It is potentially more consequential: a common data model could reduce the hand-built import/export glue that sits between safety specialists and the design-and-verification flow.
The first target is FMEDA data
Accellera says Functional Safety Language, or FSL, defines syntax and semantics for representing and exchanging functional safety intent, initially concentrating on Failure Modes, Effects, and Diagnostic Analysis data. FMEDA is the analysis used to identify component failures, their consequences, diagnostic coverage, and related reliability assumptions.The longer-term plan encompasses related safety analysis methods, including Fault Tree Analysis and Diagnostic Failure Analysis. That scope matters because a chip safety case is rarely a single document; it is a chain of evidence connecting IP-level assumptions to the finished system.
FSL is not positioned as a replacement for ISO 26262 or IEC 61508. Those standards establish the safety-development expectations. Accellera’s proposal instead addresses the practical interchange layer they leave open: how safety data is represented consistently enough to travel between organizations and tools without being reinterpreted every time.
The real prize is traceability, not another file type
The immediate benefit is less glamorous than AI-assisted design, but arguably more useful. A common representation could preserve the link between a safety requirement, a design element, an assumed failure mode, a verification activity, and the resulting analysis as the design changes.Today, that linkage is often weakened when information is copied from one workbook, report, or vendor-specific environment to another. A standard format does not make the underlying analysis correct, but it can make omissions, mismatched assumptions, and stale data easier to identify and validate.
For EDA vendors, the attraction is equally direct. Rather than creating and maintaining separate proprietary interfaces for every major customer and supplier, they could support a shared interchange model. Whether that promise is realized will depend on adoption by tool vendors, IP providers, semiconductor companies, and the system integrators that ultimately need the safety evidence.
Public review will decide whether it becomes common language
Accellera’s draft is available for public comment until August 14, 2026. The organization says its Functional Safety Working Group expects to resume work in September on supplemental material, a formal exchange format, and broader safety topics.That timeline makes the current review more than a procedural step. FSL will only reduce translation work if its data model can represent real-world FMEDA inputs and outputs without forcing users back into side spreadsheets and undocumented conventions. The deadline is therefore the industry’s chance to test whether the proposed language is precise enough for production safety flows—not merely clean enough for a specification.