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
7/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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.
7/24/2019 150403 Wp Semicon Fpga En
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.
7/24/2019 150403 Wp Semicon Fpga En
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/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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.
FPGA requirements specication
Design Test plan TestingCoding
Testing
Coding
Synthesis
Place and route
Static timing analysis
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
7/24/2019 150403 Wp Semicon Fpga En
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.
7/24/2019 150403 Wp Semicon Fpga En
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
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.
7/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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
FPGA requirements specication
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
7/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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
7/24/2019 150403 Wp Semicon Fpga En
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.
White paper: Understanding DO-254 And
Solutions to Facilitate Compliance
http://s3.mentor.com/public_documents/
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=1947/24/2019 150403 Wp Semicon Fpga En
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
http://s3.mentor.com/public_documents/
whitepaper/resources/mentorpaper_54631.
White paper: Using ReqTracer to Facilitate
a Requirements-Driven DO-254 Compliant
Design
http://s3.mentor.com/public_documents/
whitepaper/resources/mentorpaper_52834.pdf
White paper: Using ReqTracer to Facilitate
a Requirements-Driven DO-254 Compliant
Design
http://s3.mentor.com/public_documents/
whitepaper/resources/mentorpaper_52834.
7/24/2019 150403 Wp Semicon Fpga En
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
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.