150403 Wp Semicon Fpga En

7/24/2019 150403 Wp Semicon Fpga En

1/18

WhitePa

per

2015

Streamlining FPGA design, verication and validationthrough a global collaboration model

Verication and

Validation of Field

Programmable GateArrays in the Aerospace

and Defense industry


2/182

Contents

Executive Summary 01

Introduction 01

Usage of FPGA Devices in

Safety Systems

02

Compliance Requirements:

DO-254 Standard for FPGA

Design in Aerospace and

Defense Projects

03

Mapping the DO-254

Lifecycle to a Typical FPGA

Design Flow

05

Best Practices for DO-254

Compliance

06

Methodologies to Eectively

Meet DO-254 Objectives

09

Documentation and

Organization in Compliance

with DO-254

11

Ensuring Safety Compliance

in the Execution of FPGA

Projects

12

FPGA Verication and

Validation for Reduced Costs

and Enhanced SafetyA

Success Story

13

Conclusion 14

Author 14

References 14

About Cyient 16


3/1801

Executive Summary

Field Programmable Gate Arrays (FPGAs)

are nding an increasing number of

applications in the Aerospace and Defense

Industry. The eld-programmable gate

array (FPGA) is a semiconductor device that

can be programmed on the eldafter

manufacturingfor product features and

functions, new standards, and specic

applications. They provide rapid prototyping,

easy debugging at an optimized cost, andhelp lower the risk of product obsolescence.

Successful implementation of FGPAs require

in-depth knowledge, a security-based

development cycle, process adherence and

expertise.

Verication 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 everincreasing 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

verication and validation, DO-254 hardware

development life cycle requires V&V at each

stage of the design cycle. This results in an

elaborate verication process to ensure full

coverage of requirements at simulation,

followed by on-target verication of FPGAdesigns. However, there are several signicant

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 dierent sets of requirements, coverage

requirements, tool ow 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 practicesthat can be adopted to overcome the existing

challenges, and substantiates it with a case

study demonstrating a successful global

partnership model for FPGA verication 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 congured after it is

manufactured. An FPGA is not restricted to

any predetermined digital function, and is a

exible product whose features and usability

can be programmed, adapted and recongured

as per standards and specic 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 aected due to addition of new

processing logic. While an application-specic

integrated circuit (ASIC) can perform similar

digital logical function as FPGA, the ability

to re-congure and update post installationprovides additional advantages for several

applications.

Most of the logic blocks in FPGAs include

memory elements either in the form of

simple ip-ops or complete blocks of

memory in varying sizes. In addition, FPGAs

comprise variety of high-speed transceivers,

congurable embedded SRAM, routing

resources, high-speed I/Os and logic blocks

unlike the older generation programmablelogic devices (PLDs) that only use I/Os with

programmable logic and interconnects.

The logic elements (LEs) in an FPGA are

The FPGAsprovide several

advantages over

the conventional

ASICs or ASSPs

shorter time to

market, enhanced

application

performance and

longer product life

cycle


4/1802

programmable logic components that canbe physically connected using hierarchy of

recongurable switch interconnects. LEs can

act as simple logic gates like AND, OR and

XOR or be congured to perform complex

functions.

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 intosystems 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.

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

dierentiate as well as enhance performance,

accelerate time-to-market and lowercost. 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 hardwareinvolve analog, discrete digital design, usage of

multiple microprocessors or microcontrollers,

digital signal processors along with applicationsoftware. 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.

In order to reduce risk, cost, and time-to-

market, industry players are increasingly

using FPGAs devices in safety critical systems

for successful implementation. Key factors

leading to rapid adoption of FPGAs in thesafety 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 dicult to

infect. In addition, the EDA tools for FPGA

design provide extensive functionality tosupport 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/verication tools help with verication

at every step of the design ow.

FPGAs are seen as an option that provides

exibility, 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 signicant 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 verication 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

Key lactors leadingto rapid adoption

of FPGAs in the

safety systems

are parallelcomputing, high

performance

and hardware

miniaturization.


5/1803

The DO-254 isa standard that

provides broad-

level process

specication

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 relativelyeasy in FPGAs, verication of the intended

function of those safety systems is quite

complicated. One signicant dierence is

that an FPGA application does not need an

operating system, hardware drivers, or other

similar platforms. However, such a computing

environment can be congured onto a

device with sucient size of logical gates.

In addition, FPGAs use parallel computation

with dedicated hardware blocks for each

function instead of executing a program insequence,one instruction at a time.

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 functionalsafety within design, and validating the same

using various verication tools. It also requires

OEMs to use standard methodologies and

conduct review/audits in adherence with

processes and dened guidelines. These

rigorous processes pose signicant challenges

and need huge investment in terms of time,

cost and eort.

Outsourcing processes such as design,

independent V&V, safety documentation and

others can not only help successfully meet the

regulatory requirements but also signicantly

reduce cost and expedite the development

cycle. Collaborating with an outsourcing

partner with requisite domain knowledge

has been shown to provide signicant cost

savings and mitigate risks in design security.

However, a strategic partner providing support

for design, verication 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.

Compliance Requirements: DO-254 Standard for FPGA Design in

Aerospace and Defense Projects

An Overview

The DO-254 is a standard that providesguidance for designing and ensuring safetyin airborne electronic systems using ASICs,FPGAs and PLDs. All the A&D electronicsafety systems are required to comply with

this standard that species design assurancerequirements and certication.

The standard DO-254 comprises ve levelsof severity, levels A to E that are based on theimpact of the failure of system hardware onan aircrafts operation. Therefore, compliancewith Level A requirements need signicanteort in verifying and validating thesecomponents than it does for Level E.

DO-254 provides a broad-level process

specication for design to meet the standardrequirements and ensure highest quality inall safety critical applications designed forairborne systems. However, it is importantto note that DO-254 does not dene theimplementation process.

Understanding the DO-254 Life Cycle

The main aspect of DO-254 is the hardwarelifecycle that describes the phases a projectmoves through, from initial planning to nalcertication. It also includes feedback loops to

allow adaptation of requirements as necessary.Figure 1 summarizes the DO-254 hardware lifecycle and its compliance requirements.

A brief summary of the few processes

depicted in the figure is as follows:

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 arefeed back to the safety analysis process done

at the system level.


6/1804

Planning process This species detailed

plan for hardware aspects of certication

(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 certication 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

phasesfrom requirements gathering to

validation and vericationfor 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

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 combinesdeveloping 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

dened 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 thedesigner or verier nishes modeling or

developing the synthesized code for a device.

Production transition This stage occurs

The key aspectof DO-254 is the

hardware life cycle

that describes

the project

phases from initial

planning to nal

certication and

includes feedback

loops to allow

adaptation of

requirements as

necessary.

Requirement capture

Conceptual design

Detailed design

Implementation

Production transition

System process

Planning

Supporting processes

Verification and validation process

Configuration management

Process assurance

Certification liaison

Manufacturing process

HardwareDesig

nProcess

DerivedRequirements

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


7/1805

after the designer completes the designwork and is ready to produce the devices

repeatedly.

Validation and verication 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

veriable, dene traceability, and ensure

that all the functions are implemented and

working as expected.

- Verication activities provide assurance

that the performance of the device

adheres to specied requirements. It also

veries traceability of requirements to

design, design to implementation and

implementation to test cases and results,

and ensures 100% code coverage.

Conguration management This process

helps ensure that the device is developed

in as 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

modications in a controlled fashion, if

necessary.

Process assurance This process helps inestablishing quality assurance in a project

specic role focused on ensuring that the

processes dened in the PHAC are followed.

Certication liaison - This involves engaging

with a certication 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 certication authority,

and all the ndings are addressed beforecompliance is granted.

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 ow with stage

of involvement (SOI) audits to meet DO-254

objectives:

An approved V-model according to IEC

61508:2010 is shown in gure 3, which

illustrates the parallelism of activities in FPGA

work ow.

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

Planning

FPGA requirements specication

FPGA architecture design

RTL design

Synthesis

Place and route

Static timing analysis

Gate level simulations

Bit-stream le generation (programming device)

Validation testing

Planning

Requirements capture

Conceptual design

Detailed design

Implementation

Production transition

DO-254 Life Cycle Supporting Process

Traceability

Ver

icationandvalidation

Processassurance

Co

ngurationmanagement

FPGA Design FlowSOI-1

SOI-2

SOI-4 SOI-4


8/1806

Best Practices for DO-254Compliance

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 designand 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 needto 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 identifyingvarious 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 tomeet DO-254 traceability objectives.

System-levelrequirements

managementtools, like Dynamic

Object Oriented

Requirements

System (DOORS)

provide a

database

mechanism to

store and manage

requirements

eectively as they

evolve throughout

a project while

supporting largeand complex

systems.


Design Test plan TestingCoding

Testing

Coding

Synthesis

Place and route


Test plan Validation testing

Bit-stream le generation

(Programming device)

Gate level simulations

FPGA architecture/FPGA design

specications

Logical Module Design

Design Test plan

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


9/1807

Today, most of the OEMs and subcontractedtier-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 ofa 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., t = 0) for Design under

Test (DUT). The DUT is subjected to thesegenerated 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 aformal technique that analyzes a design

against its requirements and is written asassertions. Functional model based checking

is a robust verification technique for safety-

critical 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-254that 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 test-

bench 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 appropriatelyjustified.

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

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.

Functional modelbased checking

is a robust

verication

technique for

safety-critical

design that can

comprehensively

prove that a

design performs

its intendedfunction.


10/1808

Timing verifications

Timing verifications is an important aspect

of the FPGA verification flow. The timing

simulation needs to be performed by re-

running the HDL tests along with the gate-

level 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 thanthe 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 (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 ensurethey 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. Theadvantages of performing STA include the

following:

All possibilities including false paths areverified without test vectors

All analysis reports are generated within a

matter of hours as opposed to few daysas 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 best-

case 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 associatedwith signals that cross clock domains are

extremely difficult to verify and expensive

Fault tree analysisand other such

CDC analysis

tools are based

on formal

methods that

can help reduce

the likelihood of

meta-stability.


11/1809

to debug and fix, as typically they cannot bedetected 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 meta-

stability.

Hardware testing

Verifying the FPGA device functionality in itstarget 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-a-

days, 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 cannotreplace 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 Eectively 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 well-

recognized verification methodologies. Someof these functional verification methodologies

are further discussed to address the current

challenges in FPGA verification.

Fig. 4 |Well-recognized verication methodologies

Assertion based

verication and

test benchautomation

Standardssystem verilog PSL

Open verication

methodology (OVM)

Universal verication

methodology (UVM)

Processor

driven verication

Unied coverage

database

Date: 2001 2004 20102007


12/1810

Assertion-Based 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.

A designer using ABV methodology defines

assertions that capture the design functions

like overflow and underflow that occur in firstin 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 qualityand 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.

Processor-Driven Verification

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 real-

time verification and offers greater reuse of

test bench software throughout the project.

The methodology of processor-driven

verification (PDV) shown in figure 6, isprimarily used to verify complex designs using

embedded soft core processors or System-

on-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.

Assertion-basedVerication

methodology

combined with

DO-254 compliant

tools and test and

code coverage

reports review

ensure more

than 95% testcase coverage

and 100% code

coverage

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

Fig. 6 |Approach of processor-driven verication (PDV)

Simulations

Formal

verications

Emulations

RTL

User dened

(SVA, PSL)

Assertion

library

Coverage

database

Coveragedatabase

SimulationEmulation

Gated logic/

netlist

Integrated Hw/

SW debug

RTL

Integrated HW/

SW debug

Processor models

Compiler

C- basedtests

FPGA Platform/based target

system


13/1811

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.

The current generation of UVM tools is acollection 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

and other vendors allow the verifier to easilydevelop robust integrated verification

environments by taking advantage of each

language style to maximize verification

productivity.

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

Universalverication

methodology

uses open libraries

and pre-dened

IP functions to

provide maximum

coverage in a

relatively shorter

duration of time

for verifying large

and complex

designs.

Planning


Review

FPGA architecture design

RTL design

Implementation

Design database

Release and approval

SSA, SLR

...

PHAC, HDP, HVaLP,

HVerP, HCPM, HPAP

Rs, HDS, HArs, VVs

Review records, Process

records.

HR, Test benches, Review

records, Process records

HDRD (CCD), RTL code,

Test benches, FFPA, Review

records, Process records

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

Process Records

HDRD (DDD), RTL code,

Test benches, Bitstream

Review records, Process

records

HDRD (DDD), VVD

RTL code, Test benches,

Bitstream, Review records,

Process records

SSA, PHAC, VVS,

RS, ...

HR, Test benches,

VVS, HDS, ...

HDRD (CCD), RTL

Code, Test benches,

VVS, HDS, ...

Bit stream, PHAC,HCS, VVS, HDRD

(DDD), ...

RTL Code, Test

benches, Bitstream,

HVaIP, HVerP, VVS,

HDRD (DDD)...

Stage InputsProcess Outputs

Process Outputs

Process Outputs

Process Outputs

Process Outputs

Process Outputs

Stage Inputs

Stage Inputs

Stage Inputs

Stage Inputs

Stage Inputs

ENGV & VCMQASAFEPRODCERT

ENGV & VCMCERT

ENGV & VCMQASAFE

ENGV & VCMQA

ENGV & V, CM,QA, SAFE,PRODCERT

ENGV & VCMQACERT

Planning

Requirements

Capture

Conceptual

Design

Detailed

Design

Production

Transit

ion

Implementation

>>>

>>>

>>>

>>>

>>>

>>>

PlanningPhase

DevelopmentPhase

Production a

Phase

FPGA Design Flow

Functional simulations

Test bench design

Timing simulations(post-routing)

Physical tests

Design reviews

Design validation

Design reviews

Requirements

reviews

Preliminary

design review

Readiness

Review

Critical design

review

Readiness

review

Planningreviews

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


14/1812

needed based on the system or devicespecifications. It also specifies a set of

documents, reports, results, design files and

others that are supposed to be generated

across all the phasesfrom 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 artifactsneeded 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 theExecution 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 thesechallenges 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 activitiesshould 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:

Adopting a globalcollaborative

model and

outsourcing

the V&V and

redundancy

design processes

to an experienced

global partner

can help derive

signicant

time and cost

savings, and also

ensure safety

compliance.

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

Project manager

Design/implementer Verier, validator

Level A & B

Assessor

Project manager

Level C & D

Assessor

Project manager

Design/implementer Verier

OR

Assessor

Validator

Project manager

Design/implementer, verier, validator

Level E

Assessor

= Can be the same person = Can be the same Company

Design/implementer Verier, validator


15/1813

FPGA Verication and Validation

for Reduced Costs and Enhanced

SafetyA Success Story

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 tozero (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:

Independence in execution between the

teams ensured compliance with the safetyrequirements of DO-254.

Use of latesttechnologies,

innovative

techniques and

low cost skilled

resources ensured

safety, compliance

as per standards,and provided cost

optimization.

Fig. 9 |4thGeneration backplane FPGA V&V DO254 DAL-A

DAL Level E Level D Level C Level B Level A

Designer/verier 1 1 1 2 2

Designer/validator 1 2 2 3 3

Designer/assessor NA 3 3 4 4

Verier/validator 0 0 0 3 3

Verier/assessor NA 3 3 4 4

Validator/assessor NA 1 1 1 1

Table 1 |Independence of execution between the teams

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

Test case

Status data

receiver

Command

data driver

Slot strobe

generator

Phasestrobe

generator

4th

generation

SPDA

backplane

FPGA(DUT)

Clock

generator

Log les/status

CINRZ

slot_strb

slot_strb

phase_strb

cmd_data_lvds_i

cmd_data_lvds

sts_data_lvds_i

sts_data_lvds

cmd_

data_

lvds_

i

cmd_

data_

lvds

sts_

data_

lvds_

i

sts_

data_

lvds

datatransfer

decoderopen

tp_reset_state_

i

reset_i

tr_

bank_sel[2:0]

tp_ser_sts_

tr[2:0]

controlsignals

Logmessages

ser_cmd[19:0]

ser_sts[19:0]

Stimulusgenerators

Logmacros

Noisegenerators

Status

datadrivers

TB TOP

DUT TB modules Procedure/monitors/checker


16/1814

Author

L.V.R Prasada Rajuis 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 in2002, and is currently working towards Ph.D.

degree. His current research interests include

bio-medical systems and sensors, FPGA-

based 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/system-

design/articles/2013/functional-safety-

certification-subsystem.html

Standard: Functional Safety and IEC 61508www.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


whitepaper/resources/mentorpaper_60834.pdf

Ecient work distribution and allocation asper the time zone helped optimize resource

utilization and reduce cycle time of V&V

processes.

Proper utilization of DO-254 certied 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, innovativetechniques 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

prot, and forecasted the same for the year

2014. Similarly, signicant growth has been

noticed in the semiconductor business where

processes including FPGA verication and

validations and designing are being outsourced

to take advantage of huge cost savings and

signicant time reduction in project execution.

Verication 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 increasinglyleveraging 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 signicant 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 partnershipmodel,we implement best practices and

continuous improvement processes to deliver

increased productivity, shorter timelines, and

optimized costs.

Manufacturersare increasingly

leveraging global

collaborative

business models

to take advantage

of the technical

expertise of

strategic partners

to comply

with complex

and evolving

regulatory

standards.
http://www.rtca.org/onlinecart/product.cfm?id=194http://www.rtca.org/onlinecart/product.cfm?id=194http://www.altera.com/technology/system-design/articles/2013/functional-safety-certification-subsystem.htmlhttp://www.altera.com/technology/system-design/articles/2013/functional-safety-certification-subsystem.htmlhttp://www.altera.com/technology/system-design/articles/2013/functional-safety-certification-subsystem.htmlhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_45380.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_45380.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_45380.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_60834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_60834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_60834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_60834.pdfhttp://www.altera.com/technology/system-design/articles/2013/functional-safety-certification-subsystem.htmlhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_45380.pdfhttp://www.rtca.org/onlinecart/product.cfm?id=194


17/1815

Additional Informations:FPGA Fundamentals: http://www.ni.com/

white-paper/6983/en/; Publish Date: May 03,

2012

ReqTracer:www.mentor.com/reqtracer

Methodologies: http://www.mentor.com/

products/fv/methodologies/

Formal verification: http://www.mentor.com/

products/fv/abv/0-in_fv/;includes - collection

of videos and papers.

Market Research Reports: http://www.pwc.

com/en_US/us/industrial-products/assets/

pwc-aerospace-defense-2013-year-in-

review-and-2014-forecast.pdf

Tools: Mentor, Synopsys, Xilinx, Altera, Aldec.Study resources - DO-254:

Demystifying DO-254; http://s3.mentor.com/

public_documents/whitepaper/resources/

mentorpaper_38461.pdf;

The Use of Advanced Verification Methods to

Address DO-254 Design Assurance; Mentor

whitepaper

Mentor Formal Verification for DO-254(and

other Safety-Critical)Designs; Mentor

whitepaper

DO-254 Support for FPGA Design Flows;

Altera whitepaper

DO-254 for the FPGA Designer; Xilinx

whitepaper

White paper: Using HDL Designer to FacilitateDO-254 Compliant and Safety-Critical Design

Processes



pdf

White paper: Using ReqTracer to Facilitate

a Requirements-Driven DO-254 Compliant

Design


whitepaper/resources/mentorpaper_52834.pdf

White paper: Using ReqTracer to Facilitate

a Requirements-Driven DO-254 Compliant

Design



pdf
http://www.ni.com/white-paper/6983/en/http://www.ni.com/white-paper/6983/en/http://www.ni.com/white-paper/6983/en/http://www.mentor.com/products/fv/methodologies/http://www.mentor.com/products/fv/methodologies/http://www.mentor.com/products/fv/methodologies/http://www.mentor.com/products/fv/abv/0-in_fv/http://www.mentor.com/products/fv/abv/0-in_fv/http://www.mentor.com/products/fv/abv/0-in_fv/http://www.pwc.com/en_US/us/industrial-products/assets/pwc-aerospace-defense-2013-year-in-review-and-2014-forecast.pdfhttp://www.pwc.com/en_US/us/industrial-products/assets/pwc-aerospace-defense-2013-year-in-review-and-2014-forecast.pdfhttp://www.pwc.com/en_US/us/industrial-products/assets/pwc-aerospace-defense-2013-year-in-review-and-2014-forecast.pdfhttp://www.pwc.com/en_US/us/industrial-products/assets/pwc-aerospace-defense-2013-year-in-review-and-2014-forecast.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_38461.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_38461.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_38461.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_54631.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_54631.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_54631.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_38461.pdfhttp://www.pwc.com/en_US/us/industrial-products/assets/pwc-aerospace-defense-2013-year-in-review-and-2014-forecast.pdfhttp://www.mentor.com/products/fv/abv/0-in_fv/http://www.mentor.com/products/fv/methodologies/http://www.ni.com/white-paper/6983/en/http://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_52834.pdfhttp://s3.mentor.com/public_documents/whitepaper/resources/mentorpaper_54631.pdf


18/18

2015 Cyient Limited. 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.

www.cyient.com

[email protected]

NAM Headquarters

Cyient, Inc.

330 Roberts Street, Suite 102

East Hartford, CT 06108

USAT: +1 860 528 5430

F: +1 860 528 5873

EMEA Headquarters

Cyient GmbHMollenbachstr. 37

71229 LeonbergGermany

T: +49 7152 94520

F: +49 7152 945290

APAC Headquarters

Cyient Limited

Level 1, 350 Collins Street

Melbourne, Victoria, 3000

AustraliaT: +61 3 8605 4815

F: +61 3 8601 1180

Global Headquarters

Cyient Limited

Plot No. 11

Software Units Layout

Infocity, Madhapur

Hyderabad - 500081

IndiaT: +91 40 6764 1000

F: +91 40 2311 0352

About Cyient

Cyient is a global provider of engineering,data analytics, networks and operationssolutions. We collaborate with our clients toachieve more and shape a better tomorrow.

Our services for the aerospace industryinclude:Aero Engines: We help aircraft Engine OEMsto develop innovative technology solutionsfor improving fuel eciency, reducing engineemissions and noise. We provide concept tocertication engineering solutions along withsystem level ownership.

Aero Structures: We provide innovativewing and fuselage sub-assembly designsolutions from preliminary design through tocertication. We oer design & analysis, valueengineering, post design release engineering,& manufacturing engineering services.

Aero Systems: We provide subsystem-

level engineering solutions for developingtheir next generation aircraft systems. Oursystems knowledgecombined with ourexpertise in design, structure, thermal andCFD analysisallows us to provide innovativedesign solutions optimized for weight andcost.

Avionics: We oer complete productengineering solutions from requirementdenition until #SOI3 audit. We provide civiland military avionics solutions compliant to

D0-178B and D0-254.

Aero Interiors: we help customers to designtomorrows clean, spacious and ecientcabin interiors. We provide aesthetic and lightweight interior designs for commercial andbusiness jets.

Documents

150403 Wp Semicon Fpga En