Sunteți pe pagina 1din 18

White Paper

2015

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

Contents

Executive Summary

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 Effectively
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 Verification and


Validation for Reduced Costs
and Enhanced SafetyA
Success Story

13

Conclusion

14

Author

14

References

14

About Cyient

16

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

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

01

lessons learnt and industry best practices


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

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

Key lactors leading


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

programmable logic components that can


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

digital signal processors along with application


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

Evolving FPGA design has led to complex


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

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

Usage of FPGA Devices in Safety


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

02

FPGAs are seen as an option that provides


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

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

designing a complex safety system is relatively


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

Compliance Requirements: DO254 Standard for FPGA Design in


Aerospace and Defense Projects

FPGAs ensure high safety and security, and


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

The standard DO-254 comprises five levels


of severity, levels A to E that are based on the
impact of the failure of system hardware on
an aircrafts operation. Therefore, compliance
with Level A requirements need significant
effort in verifying and validating these
components than it does for Level E.

Outsourcing processes such as design,


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

03

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

DO-254 provides a broad-level process


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

System process
Planning

Conceptual design

Detailed design

Derived Requirements

Requirement capture

Hardware Design Process

The key aspect


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

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

Implementation

Production transition

Manufacturing process

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

Planning process This specifies detailed


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

requirements. This is particularly useful for


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

Mapping the DO-254 Life Cycle to a


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

Planning

Requirements capture

FPGA requirements specification

Conceptual design

FPGA architecture design

SOI-1

RTL design

Detailed design

Synthesis
Place and route

SOI-2

Static timing analysis

Implementation

Gate level simulations


Bit-stream file generation (programming device)

Production transition

Validation testing

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

05

SOI-4

Traceability

Planning

Verification and validation

Supporting Process

FPGA Design Flow

Process assurance

DO-254 Life Cycle

Process assurance This process helps in


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

Configuration management

after the designer completes the design


work and is ready to produce the devices
repeatedly.
Validation and verification This is a part
of the supporting processes in DO-254
that occur throughout the hardware design
phase:
- Validation activities establish that the
requirements are correct,complete and
verifiable, define traceability, and ensure
that all the functions are implemented and
working as expected.
- Verification activities provide assurance
that the performance of the device
adheres to specified requirements. It also
verifies traceability of requirements to
design, design to implementation and
implementation to test cases and results,
and ensures 100% code coverage.
Configuration management This process
helps ensure that the device is developed
in 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
modifications in a controlled fashion, if
necessary.

SOI-4

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

FPGA requirements specification

FPGA architecture/FPGA design


specifications

Test plan

Logical Module Design


Design

Test plan

Bit-stream file generation


(Programming device)

Testing

Coding

Design

Test plan

Validation testing

Gate level simulations


Testing

Coding

Synthesis

Static timing analysis

Place and route

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

Best Practices for DO-254


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

06

more advanced verification approaches need


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

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

Today, most of the OEMs and subcontracted


tier-1 or tier-2 organizations serving the
A&D market use system level requirements
management tools, like dynamic object
oriented requirements system (DOORS)
database product from IBM, or ReqTracer
from Mentor graphics. These tools provide
a database mechanism to store and manage
requirements effectively as they evolve
throughout a project while supporting large
and complex systems.
To ensure verifications and validations are
performed in compliance with the standard,
we have highlighted some of the important
mechanisms and best practices for conducting
functional verifications, code coverage analysis
and timing verifications.
Functional verifications
Functional verification is a formal method to
check the logic based on the specification,
design and verification 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 these
generated test vectors in a virtual environment
using DO-254 compliant tools (like ModelSim,
Active HDL etc.). The simulated results and the
generated test reports written as assertions
are checked against the test/verification
plans which provide feedback on design and
requirements for further analysis and closure.
This method of verification is listed as an
acceptable method of advanced verification
for level A/B devices in DO-254 appendix-B.
Similarly a functional model checking is a
formal technique that analyzes a design

07

against its requirements and is written as


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

Fault tree analysis


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

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

08

All possibilities including false paths are


verified 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 bestcase timing (no hold timing issues).
Clock-domain crossing analysis
The convergence of multiple functions
into a complex SoC is pushing designers to
increasingly use advanced multi-clocking
architectures to meet the high-performance
and low-power requirements. This type of
design usually involves multiple clocking and
asynchronous clocks. Clock signals that cross
domain boundaries can lead to a condition
called meta-stability, which is a primary cause
of device failure. The challenges associated
with signals that cross clock domains are
extremely difficult to verify and expensive

to debug and fix, as typically they cannot be


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

results. However, this verification cannot


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

Methodologies to Effectively Meet


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

Processor
driven verification
Open verification
methodology (OVM)

Assertion based
verification and
test bench
automation
Standards
system verilog PSL

Unified coverage
database
Universal verification
methodology (UVM)

Date:

2001

2004

Fig. 4 | Well-recognized verification methodologies

09

2007

2010

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

Assertion-Based Verification

Processor-Driven Verification

Assertion-based verification is a commonly


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

Present-day verification approaches that


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

A designer using ABV methodology defines


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

Assertion
library

The methodology of processor-driven


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

Simulations

User defined
(SVA, PSL)

C- based
tests
Compiler

RTL

Formal
verifications

Coverage
database

Emulations

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

FPGA Platform/
based target
system

Emulation

Simulation

Gated logic/
netlist

RTL

Integrated Hw/
SW debug

Integrated HW/
SW debug

Processor models

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

10

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

and other vendors allow the verifier to easily


develop robust integrated verification
environments by taking advantage of each
language style to maximize verification
productivity.

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

Development
Phase

Detailed
Design

Conceptual Requirements
Design
Capture

Planning
Phase

Planning

The current generation of UVM tools is a


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

ENG
V&V
CM
QA
SAFE
PROD
CERT

Stage Inputs
>>>

SSA, SLR
...

Stage Inputs

ENG
V&V
CM
CERT

>>>

ENG
V&V
CM
QA
SAFE

>>>

ENG
V&V
CM
QA

>>>

SSA, PHAC, VVS,


RS, ...

This methodology uses open libraries and


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

Documentation and Organization in


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

FPGA Design Flow

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

Planning

FPGA requirements specification

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

Review

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

Process Outputs
FPGA architecture design
RTL design

Test bench design

HDRD (CCD), RTL code,


Preliminary
Test benches, FFPA, Review design review
records, Process records

Process Outputs

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

Planning
reviews

Functional simulations
Design reviews

HDRD (DDD), RTL code,


Test benches, Bitstream
Review records, Process
records

Critical design
review

Implementation
Implementation

Stage Inputs
ENG
V&V
CM
QA
CERT

>>>

RTL Code, Test


benches, Bitstream,
HVaIP, HVerP, VVS,
HDRD (DDD)...

Timing simulations
(post-routing)

Physical tests

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

Readiness
review

Design reviews

Production a
Phase

Production
Transition

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

Design validation

Process Outputs

Release and approval

HAS, HATC, HDRD (DDD),


Bitstream, Review Records,
Process Records

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

11

Readiness
Review

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

needed based on the system or device


specifications. It also specifies a set of
documents, reports, results, design files and
others that are supposed to be generated
across all the 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 artifacts
needed at each stage as inputs and outputs
for the complete FPGA design process. The
production phase is not included in the image.

Ensuring Safety Compliance in the


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

and validation processes. To address these


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

Level A & B

Level C & D

Project manager

Project manager
Assessor

Design/implementer

Assessor
Design/implementer

Verifier, validator

OR

Verifier, validator

Level E

Project manager

Project manager
Assessor

Design/implementer

Verifier

= Can be the same person

Validator

Assessor
Design/implementer, verifier, validator

= Can be the same Company

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

12

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

DAL

Level E

Level D

Level C

Level B

Level A

Designer/verifier

Designer/validator

Designer/assessor

NA

Verifier/validator

Verifier/assessor

NA

Validator/assessor

NA

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

3 - Cannot be the same project;


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

Table 1 | Independence of execution between the teams

Independence in execution between the


teams ensured compliance with the safety
requirements of DO-254.

Status
data
drivers

ser_sts[19:0]

ser_cmd[19:0]

Noise
generators

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

Test case

sts_data_lvds

Status data
receiver

sts_data_lvds_i

Log messages

control signals

sts_data_lvds

cmd_data_lvds_i

data transfer

Cyient executed an FPGA verification and


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

Log
macros

Stimulus
generators

cmd_data_lvds
sts_data_lvds_i

FPGA Verification and Validation


for Reduced Costs and Enhanced
SafetyA Success Story

CINRZ

Command
data driver

cmd_data_lvds
cmd_data_lvds_i

slot_strb

Slot strobe slot_strb


generator

4th
generation
SPDA
backplane
FPGA
(DUT)
Clock
generator

Log files/status

phase_strb
Phase
strobe
generator

TB TOP
DUT

TB modules

Procedure/monitors/checker

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


13

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

Efficient work distribution and allocation as


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

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

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

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

White paper: Using HDL Designer to Facilitate


DO-254 Compliant and Safety-Critical Design
Processes
http://s3.mentor.com/public_documents/
whitepaper/resources/mentorpaper_54631.
pdf
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.
pdf

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

15

About Cyient
Cyient is a global provider of engineering,
data analytics, networks and operations
solutions. We collaborate with our clients to
achieve more and shape a better tomorrow.
Our services for the aerospace industry
include:
Aero Engines: We help aircraft Engine OEMs
to develop innovative technology solutions
for improving fuel efficiency, reducing engine
emissions and noise. We provide concept to
certification engineering solutions along with
system level ownership.
Aero Structures: We provide innovative
wing and fuselage sub-assembly design
solutions from preliminary design through to
certification. We offer design & analysis, value
engineering, post design release engineering,
& manufacturing engineering services.
Aero Systems: We provide subsystemlevel engineering solutions for developing
their next generation aircraft systems. Our
systems knowledgecombined with our
expertise in design, structure, thermal and
CFD analysisallows us to provide innovative
design solutions optimized for weight and
cost.
Avionics: We offer complete product
engineering solutions from requirement
definition until #SOI3 audit. We provide civil
and military avionics solutions compliant to
D0-178B and D0-254.
Aero Interiors: we help customers to design
tomorrows clean, spacious and efficient
cabin interiors. We provide aesthetic and light
weight interior designs for commercial and
business jets.

NAM Headquarters
Cyient, Inc.
330 Roberts Street, Suite 102
East Hartford, CT 06108
USA
T: +1 860 528 5430
F: +1 860 528 5873
EMEA Headquarters
Cyient GmbH
Mollenbachstr. 37
71229 Leonberg
Germany
T: +49 7152 94520
F: +49 7152 945290
APAC Headquarters
Cyient Limited
Level 1, 350 Collins Street
Melbourne, Victoria, 3000
Australia
T: +61 3 8605 4815
F: +61 3 8601 1180
Global Headquarters
Cyient Limited
Plot No. 11
Software Units Layout
Infocity, Madhapur
Hyderabad - 500081
India
T: +91 40 6764 1000
F: +91 40 2311 0352

www.cyient.com
insights@cyient.com

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.

16

S-ar putea să vă placă și