Verification and Validation of Field Programmable Gate Arrays in the Aerospace and Defense industry by percy.mitchell11

Verification and Validation of Field Programmable Gate Arrays in the Aerospace and Defense industry Streamlining FPGA design, verification and validation through a global collaboration model

Contents

Executive Summary

Introduction

Usage of FPGA Devices in Safety Systems

Compliance Requirements: DO-254 Standard for FPGA Design in Aerospace and Defense Projects

Mapping the DO-254 Lifecycle to a Typical FPGA Design Flow

Best Practices for DO-254 Compliance

Methodologies to Effectively Meet DO-254 Objectives

Documentation and Organization in Compliance with DO-254

Ensuring Safety Compliance in the Execution of FPGA Projects

FPGA Verification and Validation for Reduced Costs and Enhanced Safetyâ&#x20AC;&#x201C;A Success Story

Conclusion

Author

References

About Cyient

The FPGAs provide several advantages over the conventional ASICs or ASSPs —shorter time to market, enhanced application performance and longer product life cycle

Executive Summary Field Programmable Gate Arrays (FPGAs) are finding an increasing number of applications in the Aerospace and Defense Industry. The field-programmable gate array (FPGA) is a semiconductor device that can be programmed on the field—after manufacturing—for product features and functions, new standards, and specific applications. They provide rapid prototyping, easy debugging at an optimized cost, and help lower the risk of product obsolescence. Successful implementation of FGPAs require in-depth knowledge, a security-based development cycle, process adherence and expertise. Verification and validation (V&V) in the aviation industry requires strict adherence to stringent design assurance guidelines laid out by DO 254 for programmable electronic hardware like FPGAs. In addition, the ever increasing complexity of designs and high level of integration of programmable logic necessitates a specialized V&V approach for Complex Electronic Hardware (CEHs) in avionics. Unlike the classical method of verification and validation, DO-254 hardware development life cycle requires V&V at each stage of the design cycle. This results in an elaborate verification process to ensure full coverage of requirements at simulation, followed by on-target verification of FPGA designs. However, there are several significant challenges involved in verifying FPGA designs as per DO-254. Some of these include establishing requirements traceability at all levels, creating test vectors that address simulation and hardware test match, and testing in multiple environments to cover and verify different sets of requirements, coverage requirements, tool flow support, and hardware test platforms. This paper discusses the key technical challenges involved in V&V of FGPA in the Aerospace and Defence Industry. It highlights

lessons learnt and industry best practices that can be adopted to overcome the existing challenges, and substantiates it with a case study demonstrating a successful global partnership model for FPGA verification and validation. It further sheds light on how a global partnership can help optimize FPGA development by driving innovation, optimizing cost, and providing access to resources in emerging markets like India.

Introduction The Field-Programmable Gate Array (FPGA) is a set of logical gates fabricated in silicon chip that can be configured after it is manufactured. An FPGA is not restricted to any predetermined digital function, and is a flexible product whose features and usability can be programmed, adapted and reconfigured as per standards and specific application requirements. FPGAs allow multiple processing operational tasks to run simultaneously where each task is assigned to a dedicated block of chip and can perform autonomously without any interference from other blocks. Therefore, the performance of a segment of an application is never affected due to addition of new processing logic. While an application-specific integrated circuit (ASIC) can perform similar digital logical function as FPGA, the ability to re-configure and update post installation provides additional advantages for several applications. Most of the logic blocks in FPGAs include memory elements either in the form of simple flip-flops or complete blocks of memory in varying sizes. In addition, FPGAs comprise variety of high-speed transceivers, configurable embedded SRAM, routing resources, high-speed I/Os and logic blocks unlike the older generation programmable logic devices (PLDs) that only use I/Os with programmable logic and interconnects. The logic elements (LEs) in an FPGA are

Key lactors leading to rapid adoption of FPGAs in the safety systems are parallel computing, high performance and hardware miniaturization.

programmable logic components that can be physically connected using hierarchy of reconfigurable switch interconnects. LEs can act as simple logic gates like AND, OR and XOR or be configured to perform complex functions.

digital signal processors along with application software. These conventional practices entail huge development and operational costs when it comes to ensuring reliability and maintainability. They also stand the risk of rapid obsolescence.

Evolving FPGA design has led to complex devices consisting of several integrated functional components and resources. The newer FPGAs designed with hard embedded processors are transforming devices into systems on a chip (SoC) making it safer and more reliable. Additionally, in-built FPGA intellectual property (IP) blocks such as PLL, FPLL, DPLL, memories, hard multipliers and others help free-up logic resources and provide rich functions at optimized power and cost. The FPGA designs and architecture provide several advantages over the conventional ASICs or ASSPs including shorter time to market, enhanced application performance and longer product life cycle, thus mitigating risk of obsolescence.

In order to reduce risk, cost, and time-tomarket, industry players are increasingly using FPGAs devices in safety critical systems for successful implementation. Key factors leading to rapid adoption of FPGAs in the safety systems are parallel computing, high performance and hardware miniaturization. FPGAs can provide fast response times with dedicated design for each task and reduce the risk of tasks interfering with each other. Cyber security issues are also negligible with FPGAs as compared to software, as memory and functions stored in an FPGA are almost impossible to alter making it very difficult to infect. In addition, the EDA tools for FPGA design provide extensive functionality to support the design process. High abstraction level languages and block libraries and various IP cores provide a good foundation to build individual applications quickly. Additionally, the testing/verification tools help with verification at every step of the design flow.

Usage of FPGA Devices in Safety Systems Current global economic conditions and emerging competitive pressures are forcing companies to either adopt new design or redesign their existing products in order to differentiate as well as enhance performance, accelerate time-to-market and lower cost. This is particularly applicable for the companies developing safety critical systems for nuclear power plants, aerospace, defense and railways. Airborne safety applications are responsible for protecting human lives and therefore companies are under immense pressure to address growing demands for high safety and reliability. The traditional methods of developing these safety applications with embedded hardware involve analog, discrete digital design, usage of multiple microprocessors or microcontrollers,

FPGAs are seen as an option that provides flexibility, scalability and capability similar to software but with the modular system architectural design, lower complexity and improved performance characteristic of hardware. Despite the advantages of FPGAs, there are significant risks involved in designing and implementing the safety function in Register Transfer Logic (RTL). In order to mitigate these risks, FPGAs need to undergo rigorous verification and validation processes. The development of an FPGA design process is similar to that of software development process. Both use high level programming languages such as abstractive or descriptive, and their design processes are heavily dependent on software/EDA tools. While

The DO-254 is a standard that provides broadlevel process specification for designing and ensuring safety in airborne electronic systems and requires all the A&D electronic safety systems to comply with this standard.

designing a complex safety system is relatively easy in FPGAs, verification of the intended function of those safety systems is quite complicated. One significant difference is that an FPGA application does not need an operating system, hardware drivers, or other similar platforms. However, such a computing environment can be configured onto a device with sufficient size of logical gates. In addition, FPGAs use parallel computation with dedicated hardware blocks for each function instead of executing a program in sequence,one instruction at a time.

Compliance Requirements: DO254 Standard for FPGA Design in Aerospace and Defense Projects

FPGAs ensure high safety and security, and are extensively used in safety-critical systems. The aerospace and defense original equipment manufacturers (OEMs) are required to design, verify and validate airborne electronic hardware in compliance with international standards like RTCA/DO-254. This additional safety compliance requirement entails verifying applications to ensure functional safety within design, and validating the same using various verification tools. It also requires OEMs to use standard methodologies and conduct review/audits in adherence with processes and defined guidelines. These rigorous processes pose significant challenges and need huge investment in terms of time, cost and effort.

The standard DO-254 comprises five levels of severity, levels A to E that are based on the impact of the failure of system hardware on an aircraftâ&#x20AC;&#x2122;s operation. Therefore, compliance with Level A requirements need significant effort in verifying and validating these components than it does for Level E.

Outsourcing processes such as design, independent V&V, safety documentation and others can not only help successfully meet the regulatory requirements but also significantly reduce cost and expedite the development cycle. Collaborating with an outsourcing partner with requisite domain knowledge has been shown to provide significant cost savings and mitigate risks in design security. However, a strategic partner providing support for design, verification and validation in compliance with the DO-254 standard should be equipped with certain capabilities. These include access to the latest methodologies, 100% code coverage and global infrastructures for safety implementations.

An Overview The DO-254 is a standard that provides guidance for designing and ensuring safety in airborne electronic systems using ASICs, FPGAs and PLDs. All the A&D electronic safety systems are required to comply with this standard that specifies design assurance requirements and certification.

DO-254 provides a broad-level process specification for design to meet the standard requirements and ensure highest quality in all safety critical applications designed for airborne systems. However, it is important to note that DO-254 does not define the implementation process. Understanding the DO-254 Life Cycle The main aspect of DO-254 is the hardware lifecycle that describes the phases a project moves through, from initial planning to final certification. It also includes feedback loops to allow adaptation of requirements as necessary. Figure 1 summarizes the DO-254 hardware life cycle and its compliance requirements. A brief summary of the few processes depicted in the figure is as follows: â&#x20AC;˘ System process- This process provides the design assurance level for the device and device requirements assigned from the system. The device requirements are further detailed into derived requirements during design implementations and the results are feed back to the safety analysis process done at the system level.

System process Planning

Conceptual design

Detailed design

Derived Requirements

Requirement capture

Hardware Design Process

The key aspect of DO-254 is the hardware life cycle that describes the project phases from initial planning to final certification and includes feedback loops to allow adaptation of requirements as necessary.

Supporting processes • Verification and validation process • Configuration management • Process assurance • Certification liaison

Implementation

Production transition

Manufacturing process

Fig. 1 | Typical flow of DO-254 life cycle

• Planning process – This specifies detailed plan for hardware aspects of certification (PHAC) where information is collected at macro and micro level. This document captures all aspects of DO-254 compliance requirements and also enables traceability. Once approved by the certification authority, this document guides all the activities of the entire DO-254 project. • Requirements capture – This phase involves a detailed mechanism to store and manage requirements. These are carefully monitored and tagged to trace activities across all phases—from requirements gathering to validation and verification—for ensuring DO-254 compliance. • Conceptual design – This stage involves creating the architecture for the design or high-level design (HLD) in module/block level that must implement the captured 04

requirements. This is particularly useful for large complex designs, and this stage may be merged with detailed design if the design is relatively simple. • Detailed design – This phase combines developing detailed design, typically by coding the design using a hardware description language (HDL) at the modular or block level. This is done in a top-down or bottom-up approach by following the defined coding rules and guidelines. In addition, this phase involves modeling the design (or) transformation of the code into a net list during the synthesis process. • Implementation – This stage entails programing silicon chip like FPGA after the designer or verifier finishes modeling or developing the synthesized code for a device. • Production transition – This stage occurs

Mapping the DO-254 Life Cycle to a Typical FPGA Design Flow Figure 2 shows the typical mapping of DO-254 life cycle across FPGA design flow with stage of involvement (SOI) audits to meet DO-254 objectives: An approved V-model according to IEC 61508:2010 is shown in figure 3, which illustrates the parallelism of activities in FPGA work flow.

Planning

Requirements capture

FPGA requirements specification

Conceptual design

FPGA architecture design

SOI-1

RTL design

Detailed design

Synthesis Place and route

SOI-2

Static timing analysis

Implementation

Gate level simulations Bit-stream file generation (programming device)

Production transition

Validation testing

Fig. 2 | Typical mapping of DO-254 life cycle to FPGA design flow

SOI-4

Traceability

Planning

Verification and validation

Supporting Process

FPGA Design Flow

Process assurance

DO-254 Life Cycle

• Process assurance – This process helps in establishing quality assurance in a project specific role focused on ensuring that the processes defined in the PHAC are followed. • Certification liaison - This involves engaging with a certification authority to ensure DO-254 compliance during the entire development process. This typically involves four audits, called stage of involvement (SOI) audits, whereby DO-254 objectives are validated before a certification authority, and all the findings are addressed before compliance is granted.

Configuration management

after the designer completes the design work and is ready to produce the devices repeatedly. • Validation and verification – This is a part of the supporting processes in DO-254 that occur throughout the hardware design phase: - Validation activities establish that the requirements are correct,complete and verifiable, define traceability, and ensure that all the functions are implemented and working as expected. - Verification activities provide assurance that the performance of the device adheres to specified requirements. It also verifies traceability of requirements to design, design to implementation and implementation to test cases and results, and ensures 100% code coverage. • Configuration management – This process helps ensure that the device is developed in a structured, repeatable, and controlled environment. This involves revision/version management, issue reporting,and related processes to ensure that the development process can consistently replicate an item, regenerate pertinent information, and make modifications in a controlled fashion, if necessary.

SOI-4

System-level requirements management tools, like Dynamic Object Oriented Requirements System (DOORS) provide a database mechanism to store and manage requirements effectively as they evolve throughout a project while supporting large and complex systems.

FPGA requirements specification

FPGA architecture/FPGA design specifications

Test plan

Logical Module Design Design

Test plan

Bit-stream file generation (Programming device)

Testing

Coding

Design

Test plan

Validation testing

Gate level simulations Testing

Coding

Synthesis

Static timing analysis

Place and route

Fig. 3 | Approved V-model as per IEC 61508:2010, FPGA workflow

Best Practices for DO-254 Compliance An analysis shows that outsourcing and offshoring of substantial amount of work related to FPGAs in the aerospace and defense systems occurs in the areas of verification and validation (V&V), design enhancements, design reporting, and designs for safety. In this section, we detail the approaches and practices best suited for compliance processes used in V&V as well as safety design and implementation of FPGAs that help meet DO-254 qualification objectives. Verification and Validation Verification and validation is an ongoing process, where the intensity of V&V process that is applied is based on the design assurance levels (DAL) as specified in the DO-254.It is clear that for DAL A/B devices, the V&V must be an independent activity, which means that the designer cannot test his own code. Also, for DAL A/B devices, one or

more advanced verification approaches need to be followed, the most common technique of which is the code coverage analysis. In the ongoing process of V&V, system requirements assigned to the hardware items should be validated before commencing the design process. As per the defined process a feedback mechanism ensures that the derived requirements are assigned back to the system and safety engineers for validation. The established mechanisms for identifying various requirements attributes help in tracking the appropriate activities associated with various categories of requirements. Typically it verifies adherence to functional requirements of the safety critical systems. The requirements that are captured are realized into design artifacts, implemented, and are finally verified and validated. All these artifacts linked to the latter stages are also traced back to the specifications. The mechanism of traceability requires artifacts to meet DO-254 traceability objectives.

Functional model based checking is a robust verification technique for safety-critical design that can comprehensively prove that a design performs its intended function.

Today, most of the OEMs and subcontracted tier-1 or tier-2 organizations serving the A&D market use system level requirements management tools, like dynamic object oriented requirements system (DOORS) database product from IBM, or ReqTracer from Mentor graphics. These tools provide a database mechanism to store and manage requirements effectively as they evolve throughout a project while supporting large and complex systems. To ensure verifications and validations are performed in compliance with the standard, we have highlighted some of the important mechanisms and best practices for conducting functional verifications, code coverage analysis and timing verifications. Functional verifications Functional verification is a formal method to check the logic based on the specification, design and verification of a computer system. In this verification method, a step-by-step process is followed to meet the requirements of the DO-254. Detailed test cases, both positive and negative cases, are developed with trace back to requirements and design, so that all the test cases are realized in test bench code. This is where it generates the test vectors at ideal conditions (i.e., Î&#x201D;t = 0) for Design under Test (DUT). The DUT is subjected to these generated test vectors in a virtual environment using DO-254 compliant tools (like ModelSim, Active HDL etc.). The simulated results and the generated test reports written as assertions are checked against the test/verification plans which provide feedback on design and requirements for further analysis and closure. This method of verification is listed as an acceptable method of advanced verification for level A/B devices in DO-254 appendix-B. Similarly a functional model checking is a formal technique that analyzes a design

against its requirements and is written as assertions. Functional model based checking is a robust verification technique for safetycritical design that can comprehensively prove that a design performs its intended function. It is commonly used for DO-254 programs today. Code coverage analysis Code coverage analysis is one of the advanced verification approaches used to comply with the elemental analysis stated in the DO-254 that requires all the elements in a design to be verified. In a typical FPGA development program, the design is developed in a hardware description language (HDL) like VHDL and the elements in the design become the elements in the HDL code that need to be verified for completeness. The identified elements for coverage in the HDL code are branches, instructions, statements, conditions and toggle. The code coverage tool is a program that analyzes the database, which is generated by the simulation tool while running the testbench codes. These test-bench codes are developed based on the test cases aligned with the requirements. The coverage tool analysis identifies the gaps in elemental coverage which can reveal insufficient testing and unused code. The generated reports must show the results of all the elements in the HDL code with 100% coverage. In case something is not covered, it needs to be appropriately justified. Usually, the verification tools must be assessed in compliance with the DO-254 process based on the design assurance level (DAL). Two different verification toolsâ&#x20AC;&#x201D; Modelsim from mentor graphics and Active HDL from AldecInc must be used to check the simulation results and coverage analysis reports for maintaining consistency and compliance with the standard.

Fault tree analysis and other such CDC analysis tools are based on formal methods that can help reduce the likelihood of meta-stability.

Timing verifications Timing verifications is an important aspect of the FPGA verification flow. The timing simulation needs to be performed by rerunning the HDL tests along with the gatelevel delay timing information on the resulting netlist. This is done when the netlist is generated after the design is transformed to logical gate level with help of synthesis, and place and route. A netlist with timing information contains far more details than the mere functional description of the HDL code, thus making it time-consuming at times. However, the general DO-254 expectation is that all test codes should be run even if the design is very large and complex, and the execution of all test code is expected to take days or weeks to simulate. In such cases we recommend that other methods such as logical equivalency checking, scale down or scale up checking may be considered, without compromising the logic and timing. Timing verifications are generally divided into two categories: Static timing analysis Static timing analysis (STA) is a technique that is used to compute the expected timing of path delays in a digital logic circuit without any simulations. During the process of design synthesis and place and route, the STA is performed to analyze the path delays to ensure they meet timing constraints. The reports generated during synthesis process provide only estimated timing, while reports from the place and route provide visibility into real-time delays as the design is being implemented into the silicon fabric. This method of analysis is performed by verifying every path, to identify all set-up and hold time violations, glitches, slow paths and clock skews. The reports are reviewed by two independent tools (based on the selected DAL) to ensure accuracy. The advantages of performing STA include the following:

â&#x20AC;˘ All possibilities including false paths are verified without test vectors â&#x20AC;˘ All analysis reports are generated within a matter of hours as opposed to few days as in the case of simulations However, STA does not replace functional timing analysis and cross domain clock (CDC) analysis. Dynamic timing analysis Dynamic timing analysis verifies the implemented design timings by applying the generated test vectors to the design under test (DUT) with the input of standard delay format (.SDF) file. It is performed on DUT using the minimum and maximum propagation delay timing information in the. SDF file. This method of simulation ensures that design is verified by meeting all the timing requirements. The reports are generated along with the timing information and it is independently reviewed in compliance with the DO-254 standard. However, to verify complex designs, the functional simulations are performed using the typical timing information from the .SDF file. In general, verifiers use the maximum propagation delay information to verify the DUT under worst-case timing (no setup timing issues), and minimum propagation delays information to verify bestcase timing (no hold timing issues). Clock-domain crossing analysis The convergence of multiple functions into a complex SoC is pushing designers to increasingly use advanced multi-clocking architectures to meet the high-performance and low-power requirements. This type of design usually involves multiple clocking and asynchronous clocks. Clock signals that cross domain boundaries can lead to a condition called meta-stability, which is a primary cause of device failure. The challenges associated with signals that cross clock domains are extremely difficult to verify and expensive

to debug and fix, as typically they cannot be detected until a failure occurs in the lab or field. There are few methods like stuck-high and stuck-low analysis, fault tree analysis and few of the CDC analysis tools from Mentor Graphics which are based on formal methods that can help reduce the likelihood of metastability. Hardware testing Verifying the FPGA device functionality in its target system is the final test that verifies whether the device is performing as intended. In this verification process, the programmed FPGA device can be tested or verified in two ways, a) testing the programmed FPGA in isolation or b) in its target system. Now-adays, numerous verification platforms are available to verify the targeted FPGA device functionality. The method of co-simulation hardware-software tools and platforms like LabVIEW based simulators, Matlab/Simulink based simulators are used to generate test vectors for the targeted FPGA device, and the test reports are compared to simulation

results. However, this verification cannot replace the final system testing that DO-254 compliance requires, although it will ensure that the post silicon verification of the programmed device is aligned with the DO-254 requirements.

Methodologies to Effectively Meet DO-254 Objectives V&V engineers identify the appropriate verification methodology based on the requirements that are defined in the verification plan. This verification plan is validated before moving to the next steps in the process. FPGA verification and validation engineers choose the appropriate functional verification methodology along with the DO-254 compliant tools to ensure efficient and robust verification. Figure 4 shows the evolution of wellrecognized verification methodologies. Some of these functional verification methodologies are further discussed to address the current challenges in FPGA verification.

Processor driven verification Open verification methodology (OVM)

Assertion based verification and test bench automation Standards system verilog PSL

Unified coverage database Universal verification methodology (UVM)

Year

2001

2004

Fig. 4 | Well-recognized verification methodologies

2007

2010

Assertion-based Verification methodology combined with DO-254 compliant tools and test and code coverage reports review ensure more than 95% test case coverage and 100% code coverage

Assertion-Based Verification

Processor-Driven Verification

Assertion-based verification is a commonly used methodology where designers or verifiers use assertions to verify the functionality of the design as per requirements, either by deploying simulation or formal verification processes.

Present-day verification approaches that generate test vectors from an HDL test-bench code only begin to mimic the processor bus functional model. The new methodology of processor-driven test benches enables realtime verification and offers greater reuse of test bench software throughout the project.

A designer using ABV methodology defines assertions that capture the design functions like overflow and underflow that occur in first in first out (FIFO) order. To verify that the FIFO is correctly implemented,designer uses simulations, formal verification, or emulation verification processes. Basic block diagram of assertion-based verification methodology shown in figure 5 is widely used by designers and verification engineers. Various available tools provide comprehensive support to assertion libraries and languages, thus improving design quality and verification productivity. Additionally, designers and verifiers have found assertions to be invaluable in the debugging process. Using this methodology with DO-254 compliant tools in conjunction with test and code coverage reports review ensures more than 95% test case coverage and 100% code coverage to meet the DO-254 objectives.

Assertion library

The methodology of processor-driven verification (PDV) shown in figure 6, is primarily used to verify complex designs using embedded soft core processors or Systemon-chip (SoC). This verification approach for SoCs requires the execution of instructions in software to ensure maximum coverage of an SoC and its interfaces. To achieve the goals of maximum coverage, the test vectors are driven into the design via a processor bus. These test vectors can originate from several types of full functional models, or test benches in C or assembly code. However, in this approach the DUT is processor driven, the test design is superior to traditional bus-functional models, and the results of the tests are read and monitored by other instructions/commands in the test. Processor-driven test software offers maximum reuse potential during all phases of the project.

Simulations

User defined (SVA, PSL)

C- based tests Compiler

RTL

Formal verifications

Coverage database

Emulations

Fig. 5 | Basic block diagram of assertion-based verification

FPGA Platform/ based target system

Emulation

Simulation

Gated logic/ netlist

RTL

Integrated Hw/ SW debug

Integrated HW/ SW debug

Processor models

Coverage database Fig. 6 | Approach of processor-driven verification (PDV)

Universal verification methodology uses open libraries and pre-defined IP functions to provide maximum coverage in a relatively shorter duration of time for verifying large and complex designs.

and other vendors allow the verifier to easily develop robust integrated verification environments by taking advantage of each language style to maximize verification productivity.

UVM/OVM The Universal Verification Methodology (UVM) is a standard verification methodology developed by the open community. UVM represents the latest enhancements in verification technology and is designed to enable the creation of robust mechanisms, reusable modules, interoperable verification IPs, and test bench modules.

Development Phase

Detailed Design

Conceptual Requirements Design Capture

Planning Phase

Planning

The current generation of UVM tools is a collection of techniques and mechanisms along with coding styles. These standard approaches increase the productivity of functional verification. The techniques include raising the abstraction level of tests, writing tests using bus function models (BFM) and task calls, adding functional coverage and constrained-random stimulus generation. The latest UVM supported tools from Mentor

ENG V&V CM QA SAFE PROD CERT

Stage Inputs >>>

SSA, SLR ...

Stage Inputs

ENG V&V CM CERT

>>>

ENG V&V CM QA SAFE

>>>

ENG V&V CM QA

>>>

SSA, PHAC, VVS, RS, ...

This methodology uses open libraries and pre-defined IP functions to provide maximum coverage in a relatively shorter duration of time for verifying large,complex designs, and generates reports for review in compliance with the standard.

Documentation and Organization in Compliance with DO-254 Documentation plays a key role in compliance and certification of any A&D safety system. The DO-254 standard provides general guidelines for the type of documentation

FPGA Design Flow

Process Outputs PHAC, HDP, HVaLP, HVerP, HCPM, HPAP Rs, HDS, HArs, VVs Review records, Process records.

Planning

FPGA requirements specification

Process Outputs HR, Test benches, Review Requirements reviews records, Process records

Review

Stage Inputs HR, Test benches, VVS, HDS, ...

Process Outputs FPGA architecture design RTL design

Test bench design

HDRD (CCD), RTL code, Preliminary Test benches, FFPA, Review design review records, Process records

Process Outputs

Stage Inputs HDRD (CCD), RTL Code, Test benches, VVS, HDS, ...

Planning reviews

Functional simulations Design reviews

HDRD (DDD), RTL code, Test benches, Bitstream Review records, Process records

Critical design review

Implementation Implementation

Stage Inputs ENG V&V CM QA CERT

>>>

RTL Code, Test benches, Bitstream, HVaIP, HVerP, VVS, HDRD (DDD)...

Timing simulations (post-routing)

Physical tests

Process Outputs HDRD (DDD), VVD RTL code, Test benches, Bitstream, Review records, Process records

Readiness review

Design reviews

Production a Phase

Production Transition

Design database ENG Stage Inputs V & V, CM, QA, SAFE, >>> Bit stream, PHAC, HCS, VVS, HDRD PROD (DDD), ... CERT

Design validation

Process Outputs

Release and approval

HAS, HATC, HDRD (DDD), Bitstream, Review Records, Process Records

Fig. 7 | Documentation requirement of DO-254 design process at each step of FPGAs design flow

Readiness Review

Adopting a global collaborative model and outsourcing the V&V and redundancy design processes to an experienced global partner can help derive significant time and cost savings, and also ensure safety compliance.

needed based on the system or device specifications. It also specifies a set of documents, reports, results, design files and others that are supposed to be generated across all the phasesâ&#x20AC;&#x201D;from planning, development to production. The process of configuration management helps maintain the integrity of the artifacts that are controlled and organized in a proper documentation tree structure. Figure 7 highlights the type of artifacts needed at each stage as inputs and outputs for the complete FPGA design process. The production phase is not included in the image.

Ensuring Safety Compliance in the Execution of FPGA Projects Ensuring safety compliance requires organizations to have an in-depth understanding of the DO-254 standards applicable to FPGA designs. However, the document only provides a broad level guidance for design assurance and certification, making it difficult to interpret and execute verification

and validation processes. To address these challenges OEMs should consider adopting a global collaborative model and outsource the V&V and redundancy design processes to an experienced global partner. This will allow them to leverage skilled resources and the infrastructure setup of the strategic partner, in order to derive significant time and cost savings, and also ensure safety compliance. An experienced strategic global partner supporting safety compliance activities should offer multi-disciplinary teams including design, verification, validation, safety/RAMS and quality teams with distinctively defined job roles. They should also have access to processes and facilities where each of these teams can operate with an appropriate degree of independence aligned with the recognized standards like IEC 61508. Figures 8 and 9 show the segregation of teams for independent execution of projects, in-line with DAL levels A to E:

Level A & B

Level C & D

Project manager

Project manager Assessor

Design/implementer

Assessor Design/implementer

Verifier, validator

Level E

Project manager

Project manager Assessor

Design/implementer

Verifier

= Can be the same person

Validator

Assessor Design/implementer, verifier, validator

= Can be the same Company

Fig. 8 | Case example of independent execution of projects in-line with safety compliance

Use of latest technologies, innovative techniques and low cost skilled resources ensured safety, compliance as per standards, and provided cost optimization.

DAL

Level E

Level D

Level C

Level B

Level A

Designer/verifier

Designer/validator

Designer/assessor

Verifier/validator

Verifier/assessor

Validator/assessor

Where, 0 - Can be the same person; 1 - Cannot be the same person; 2 - Cannot be the same sub-system/ equipment Design Team or Project Assurance Team within a project.

3 - Cannot be the same project; 4 - Cannot be the same company; Not applicable: no assessor required for DAL-E

Table 1 | Independence of execution between the teams

• Independence in execution between the teams ensured compliance with the safety requirements of DO-254.

Status data drivers

ser_sts[19:0]

ser_cmd[19:0]

Noise generators

decoder open tp_reset_state_i reset_i fltr_bank_sel[2:0] tp_ser_sts_fltr[2:0]

Test case

sts_data_lvds

Status data receiver

sts_data_lvds_i

Log messages

control signals

sts_data_lvds

cmd_data_lvds_i

data transfer

Cyient executed an FPGA verification and validation project in a global collaboration model in accordance with the DO-254 processes. An independent V&V team of 6-members were deployed to perform FPGA V&V activities, where the test backplane FPGA was used to convert data from non-return to zero (NRZ) format to channel interleaved non return to zero (CINRZ) format and vice versa. The other design teams were totally isolated and two verification teams across the globe worked in a way where the work modules and activities were well separated to take advantage of two diverse time zones. This global collaboration model of working helped our client derive the following advantages:

Log macros

Stimulus generators

cmd_data_lvds sts_data_lvds_i

FPGA Verification and Validation for Reduced Costs and Enhanced Safety–A Success Story

CINRZ

Command data driver

cmd_data_lvds cmd_data_lvds_i

slot_strb

Slot strobe slot_strb generator

4th generation SPDA backplane FPGA (DUT) Clock generator

Log files/status

phase_strb Phase strobe generator

TB TOP DUT

TB modules

Procedure/monitors/checker

Fig. 9 | 4th Generation backplane FPGA V&V – DO254 DAL-A 13

Manufacturers are increasingly leveraging global collaborative business models to take advantage of the technical expertise of strategic partners to comply with complex and evolving regulatory standards.

• Efficient work distribution and allocation as per the time zone helped optimize resource utilization and reduce cycle time of V&V processes. • Proper utilization of DO-254 certified diverse tools and safety infrastructures provided cost optimization. • Dedicated environments with database and dedicated skilled teams across the globe enhanced productivity. • Use of latest technologies, innovative techniques in V&V of FPGAs and low cost skilled resources ensured safety, compliance as per standards, and provided cost optimization.

Conclusion The A&D industry reported its best year ever in 2013, in terms of revenue and operating profit, and forecasted the same for the year 2014. Similarly, significant growth has been noticed in the semiconductor business where processes including FPGA verification and validations and designing are being outsourced to take advantage of huge cost savings and significant time reduction in project execution. Verification and validation of FPGAs as per DO-254 entails rigorous and complex procedures that require in-depth understanding of tools and methodologies to be used for process execution to ensure safety compliance. Therefore, OEMs are increasingly leveraging global collaborative business models to take advantage of the technical expertise of strategic partners to comply with complex and evolving regulatory standards. Cyient has gained significant experience in the avionics domain and in V&V aspects of FPGA realizations. We understand the A&D market needs in relation to DO-254 and have been working closely with global partners. Leveraging our successful global partnership model,we implement best practices and continuous improvement processes to deliver increased productivity, shorter timelines, and optimized costs. 14

Author L.V.R Prasada Raju is currently associated with Cyient as a project manager with the Semiconductor practice. He has over 14 years of experience in automotive and rail industry. His areas of expertise are RTL design for FPGAs/ASICs, and hardware engineering for safety critical systems. Prasada Raju received his B.Sc. degree in 1999 and M.Sc. (Tech). Instrumentation degree in 2002, and is currently working towards Ph.D. degree. His current research interests include bio-medical systems and sensors, FPGAbased embedded systems, safety electronics, and digital signal processing.

References Standard: DO-254, Design Assurance Guidance for Airborne Electronic Hardware, published by RTCA, Inc http://www.rtca.org/onlinecart/product. cfm?id=194 Article: Functional Safety Certification for Subsystem Developers; By Wolfgang Kattermann, Altera Corporation http://www.altera.com/technology/systemdesign/articles/2013/functional-safetycertification-subsystem.html Standard: Functional Safety and IEC 61508 www.iec.ch/functionalsafety/ White paper: Code Coverage Explained for DO-254 Programs http://s3.mentor.com/public_documents/ whitepaper/resources/mentorpaper_ 45380.pdf White paper: Understanding DO-254 and Solutions to Facilitate Compliance http://s3.mentor.com/public_documents/ whitepaper/resources/mentorpaper_ 60834.pdf

White paper: Using HDL Designer to Facilitate DO-254 Compliant and Safety-Critical Design Processes http://s3.mentor.com/public_documents/ whitepaper/resources/mentorpaper_ 54631.pdf

ReqTracer www.mentor.com/reqtracer

White paper: Using ReqTracer to Facilitate a Requirements-Driven DO-254 Compliant Design http://s3.mentor.com/public_documents/ whitepaper/resources/mentorpaper_ 52834.pdf

Formal Verification (includes collection of videos and papers) http://www.mentor.com/products/fv/abv/ 0-in_fv/

White paper: Using ReqTracer to Facilitate a Requirements-Driven DO-254 Compliant Design http://s3.mentor.com/public_documents/ whitepaper/resources/mentorpaper_ 52834.pdf FPGA Fundamentals http://www.ni.com/white-paper/6983/en/; Publish Date: May 03, 2012

Methodologies http://www.mentor.com/products/fv/ methodologies/

Market Research Reports http://www.pwc.com/en_US/us/industrialproducts/assets/pwc-aerospace-defense2013-year-in-review-and-2014-forecast.pdf Demystifying DO-254 http://s3.mentor.com/public_documents/ whitepaper/resources/mentorpaper_ 38461.pdf

About Cyient Cyient is a global provider of engineering, manufacturing, data analytics, networks and operations solutions. We collaborate with our clients to achieve more and shape a better tomorrow. With decades of experience, Cyient is well positioned to solve problems. Our solutions include product development and life cycle support, process and network engineering, and data transformation and analytics. We provide expertise in the aerospace, consumer, energy, medical, oil and gas, mining, heavy equipment, semiconductor, rail transportation, telecom and utilities industries. Strong capabilities combined with a network of more than 13,100 associates across 38 global locations enable us to deliver measurable and substantial benefits to major organizations worldwide. For more information about Cyient, visit our website.

NAM Headquarters Cyient, Inc. 330 Roberts Street, Suite 400 East Hartford, CT 06108 USA T: +1 860 528 5430 F: +1 860 528 5873 EMEA Headquarters Cyient Europe Ltd. High Holborn House 52-54 High Holborn London WC1V 6RL UK T: +44 20 7404 0640 F: +44 20 7404 0664 APAC Headquarters Cyient Limited Level 1, 350 Collins Street Melbourne, Victoria, 3000 Australia T: +61 3 8605 4815 F: +61 3 8601 1180 Global Headquarters Cyient Limited Plot No. 11 Software Units Layout Infocity, Madhapur Hyderabad - 500081 India T: +91 40 6764 1000 F: +91 40 2311 0352

www.cyient.com connect@cyient.com

ÂŠ 2016 Cyient. Cyient believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. Cyient acknowledges the proprietary rights of the trademarks and product names of other companies mentioned in this document. Updated June 2016