Accellera’s Functional Safety Language (FSL) 1.0 draft, released for public review in late July 2026, proposes to end the spreadsheet roulette that engineers play when exchanging safety-critical semiconductor data. The standard, which focuses initially on Failure Modes, Effects, and Diagnostic Analysis (FMEDA), defines a vendor-neutral format for representing functional safety information. With many electronic design automation (EDA) tools running on Windows, the draft could reshape daily workflows for thousands of engineers who now spend hours manually converting data between proprietary tool formats. The review period runs until August 14, 2026.

What the FSL Draft Actually Proposes

FSL is not another safety standard. It doesn’t replace ISO 26262 for automotive or IEC 61508 for industrial systems. Instead, it attacks the missing middle: how safety data is represented consistently enough to travel between organizations and tools without being reinterpreted every time. The draft defines syntax and semantics for FMEDA—the analysis used to identify component failures, their consequences, and diagnostic coverage—with a long-term plan to incorporate Fault Tree Analysis (FTA) and Diagnostic Failure Analysis (DFA).

Accellera’s Functional Safety Working Group, chaired by Alessandra Nardi, published the draft after years of industry feedback. The core idea is straightforward: treat safety information with the same rigor as design and verification data. Today, a safety requirement might live in a Word document, its traceability to a specific transistor stored in a custom database, and the failure mode analysis in an Excel sheet tweaked by three different teams. FSL aims to create a single machine-readable record that stays linked as the design evolves.

Why Windows Workstation Users Should Care

Walk through any semiconductor design house and you’ll see Windows workstations running Cadence, Synsopsys, Siemens EDA, or a dozen smaller tools. These tools generate and consume vast amounts of functional safety evidence. Without a common interchange format, integration often means writing Python scripts to scrape reports, VBA macros to align Excel columns, or manually re-entering data from one tool’s proprietary export into another’s import wizard.

That’s where FSL’s promise lands hardest. If tool vendors adopt FSL, the import/export glue that sits between safety specialists and design flows could shrink to a single parser. For the IT teams supporting these environments, it could mean fewer late-night calls about a broken macro that’s holding up a safety audit. For the engineers, less time wrestling spreadsheets and more time analyzing actual safety margins.

The benefit scales further up the supply chain. An IP core vendor could ship an FSL file alongside the Verilog, giving the chip integrator a head start on FMEDA. A Tier-1 automotive supplier could pass a validated safety case to the OEM without re-explaining what each column in a 47-tab workbook means. The common language doesn’t make the analysis correct, but it makes errors and omissions harder to hide.

How Safety Data Exchange Got So Broken

Functional safety standards exploded over the past two decades as semiconductors crept into braking systems, insulin pumps, and flight controls. ISO 26262 and IEC 61508 set the bar for evidence, but they leave the “how” of data management to each company. That freedom bred a Tower of Babel.

A survey of five different semiconductor firms might reveal five different FMEDA templates—each with columns named slightly differently, each assuming slightly different failure rate bases. Mergers and acquisitions compounded the mess. When Company A buys Company B, their safety databases rarely speak the same language. Engineers burn weeks mapping fields, and the traceability chain often snaps.

Accellera’s white paper from 2023, authored by the Functional Safety Working Group, mapped this fragmentation in detail. It described analyses “frequently recreated or manually translated as they move between organizations, engineering teams, and EDA tools.” Those words weren’t exaggeration; they reflected a consensus among the group’s members, which include major semiconductor companies, IP providers, and tool vendors. The white paper kicked off the effort that produced the current draft.

What to Do Before August 14, 2026

Accellera is accepting public comments on the draft until August 14. Participation doesn’t require membership—anyone can review and submit feedback through the Functional Safety Community Forum on Accellera’s website. Here’s how to engage meaningfully:

  • Download the draft from Accellera’s site and walk through your own FMEDA workflow. Can the FSL schema hold your data without losing nuance? Does it handle diagnostic coverage calculations, failure rate sources, and residual vs. single-point fault distinctions as you define them?
  • Test edge cases. If your team uses custom failure mode categories or unique fault propagation models, try mapping them into FSL. Missing mappings are exactly the kind of feedback the working group needs.
  • Involve your EDA tool provider. Let them know you’re evaluating FSL. Tool vendors weigh customer demand heavily when prioritizing standards support.
  • If impact is high, consider joining the working group. Companies that join Accellera can directly influence the final standard and the upcoming formal exchange format.

What Comes Next

After the review window closes on August 14, the working group will go quiet for a few weeks, then reconvene in September. The agenda includes processing public comments, developing supplemental materials (likely a formal exchange schema based on XML or JSON), and extending FSL to cover FTA and DFA.

Adoption won’t be instant. Standards live or die on tool support. But the incentives are aligned with other interoperability pushes in the industry—IP-XACT for IP integration, SystemRDL for register descriptions. FSL fills the safety-shaped hole in that lineup. If adopted, it could unlock more automated safety flows, where a change in the RTL automatically flags which FMEDA lines need review, and where an auditor can click through a digital thread from requirement to silicon without ever opening a spreadsheet. That future is a few years out, but the review starting now is the first real test of whether the language can capture production safety data, not just toy examples.