FPGA Development Tools Qualification for ISO26262 - An Overview and guideline

Sharanbasappa, Prasanna Venkatesh B (HCL Technologies)

Introduction:

In ISO 26262 ASIL compliant development process, Tool Confidence Level (TCL) or Tool Qualification is one of the vital activities and a requirement which cannot be compromised. The ISO 26262 standard Part 8: “Supporting Processes” (Clause 11) clearly emphasizes on TCL.

Also in recent past, trend in automotive OEMs, Tier-1 and Tier-2 suppliers has been to combine various features in their product, which basically involves ‘different tools and methodology’ in the product development (Concept to Product).

Generally, the standard development tools and NEW development tools (Ex: Modeling, Analysis, Deigns, Verification, Validation etc.), tend to evolve in parallel to accommodate the product development cycle by targeting reduced development time, user-friendly, low cost etc. On the other hand, maturity, ERROR FREE and robustness of these tools cannot be compromised in development of a safe product.

Tool Confidence Level (TCL) – Overview:

The TCL is a decision process for a tool, determined with TI (Tool Impact) and TD (Tool error Detection).

At a high level, malfunction of a software tool could lead to the following,

• A bug introduces in the product
• Failed to detect the bug in the product (false negative)

In general Tool Impact and Tool Detection (also called as Tool error Detection) can be descried as,

• TI (Tool Impact) is a measure of possibility, where the product/design failure can happen due to a tool problem.
• TD (Tool Detection) which is a measure of possibility, where the product/design bug or malfunction was failed to get detected due to tool problem

The ISO 26262 standard does not provide any specific method for Tool Qualification. So the TCL determination for LOW, MEDIUM and HIGH is likely subjective. Also performing the Tool Qualification for all the tools used in the development cycle will be complex, time consuming and costly. Below figure1 shows the TCL classification process.

^{Click to enlarge}

Figure1: Tool Qualification Process

Tool Qualification for FPGA development:

The growing complexity in FPGA Silicon, Interfaces, reduction in technology node, etc. has a coupled impact and pressure on the FPGA EDA development tools for “Functional Safety Compliance”. Typically, FPGA development uses different tool set in each stage (example: Simulation, Synthesis, Place and Route, Equivalence Check, on-Chip Debug etc.).

Also, FPGA device companies like Xilinx, Altera, Lattice, MicroSemi etc. has their own integrated EDA software tool flow which can do; Compile, Synthesis, Place and Route, Timing Analysis, Simulation etc. At the same time there are independent tools for Simulation, Synthesis and Debug from many leading EDA companies.

So to arrive at suitable TCL strategy, for the identified development tools and generating an evidence for “Tool Evaluation and Qualification Report” is essential. This TCL report document will be part of the product “Safety Case” repository and will be reviewed and accepted by customer’s Functional Safety Manager/Safety Audit Team.

Today most of the FPGA tool vendors understand the pain of functional safety certification process and the importance of the Tool Qualification. So many of the FPGA EDA tools are TÜV SÜD certified or TÜV Rheinland certified and many in process of certification. The figure2 explains the overview of the TCL process overview and below table provides guidelines for Tool Qualification Process.

Figure2: Software Tool Classification Analysis flow

TCL	Criteria/ Guideline
Tool Qualification Planning	Understand clearly the ASIL level requirement for the FPGA design Select the Industry standard EDA tool vendor (prefer vendor who has long track history) Enlist what SW product features are required for the project Enlist the tool performance factors (ex. compile time, simulation time, no. of cpu cores etc.) Enlist the file format, inter tool dependent file format Enlist the tool related automation requirements Enlist the third party tool interface requirements Ensure the tool is TÜV certified (as added TCL advantage) Identify the stable version and revision of the tool to be used in the development. Ensure all the SW features are available Plan the operational environment (Windows or Linux etc.) Plan the Tool use case Leverage from vendor data for TCL analysis (to detect malfunctions or erroneous output of the tool) Qualify minimum 2 tools so that there is a backup option
Tool Qualification check guideline (Overview)	For Simulation tool: Verify for Fault identification during elaboration Verify for multiple fault types, single event upset (SEU), single event transient (SET) and stuck0/1 Verify Fault injection test in reflected in Fault dictionary ( possibly the hierarchy wise) Verify for boundary values, Statement coverage, Branch coverage, MC/DC (Modified Condition/Decision Coverage Performance and Consistency test etc. For Synthesis and PNR tool: Optimization test, Partition test, logic inference test, consistence test Performance test (compile time etc.), Inter tool file exchange format capability Internal Functional safety block/feature inference test, Logic/resource duplication test etc. GUI support, Netlist VS GUI view compatibility Log reporting format (area, timing report, etc.)
Tool Classification	Qualify the selected tool features or options (using evaluation version) with legacy In-house design and vendor supplied design for, Expected output (Determine tool impact for every use case/Identify potential tool errors for every use case Error Detection capability, Consistency No tool failure during the compile/execution Inter tool file exchange format capability Tool performance User flexibility to control optimization using tool configuration setting. Language and syntax support/Error reporting format and log
Tool Qualification	Evidence that the tool qualification has been carried out as planned Usage constraints and malfunctions identified during the qualification (if any)
Tool Documentation	Software Tool Qualification Report Capture Tool overview, tool configuration settings (compile switches, compile strategy etc.) Tool Operational environment, features installed with version and revision Known issues or Limitation identified and confirmed by the vendor Tool Classification (for the tools used in development)

Summary:

Since different tools have different functions, a proper tool evaluation with vendor support and vendor supplied Functional Safety documentation (Safety Manual, Tool Classification Analysis and Technical Report from Functional Safety Auditor) is essential. Also tool evaluation based on adapting to one version of the tool for development will avoid tool related bugs. Moreover TÜV certified tool will enable in easy certification process and design with confidence.