Event Details

View All Recorded Events
Date Event Type Location Action
Oct 05, 2018 DO-254 Seminar

Course Synopsis:

The Federal Aviation Administration (FAA) has recognized DO-254 as a means of compliance for the development of FPGAs such that they will safely function as intended under normal and abnormal operating conditions. Developers of airborne hardware containing FPGAs are now faced with new challenges because DO-254 is a stringent requirements-based development process that introduces new concepts and processes, enforces engineering best practices and standards, and requires applicants to produce a significant amount of life cycle data and documents. In this seminar, you will learn the basic concepts of DO-254 and how it applies to FPGA development. You will learn best-practices, commonly-used tools and verification methodologies to help you comply with DO-254.


12:30PM-13:00PM Registration
13:00PM-17:30PM DO-254 Seminar
17:30PM-19:00PM Cocktail Party

Shin-Yokohama Kokusai Hotel, Yokohama, Japan

1. Introduction to DO-254
2. Best Practices: Requirements Traceability
3. Managing Validation and Verification Activities for DO-254
4. HDL Coding Standards and How to Mitigate CDC Effects
5. Physical Testing for DO-254



01: Introduction to DO-254


For almost two decades, avionics system manufacturers have only had to adhere to DO-178 for the development of airborne software. RTCA/DO-178A was recognized by the FAA in 1985 for the development of airborne software, but RTCA/DO-254 was only recognized by the FAA in 2005 for the development of airborne electronic hardware (AEH).


Organizations new to DO-254 may perceive it difficult and cumbersome, but experienced DO-254 practitioners perceive it as an efficient development process rooted in pure engineering best-practices for high-reliability designs.


Learning new industry standards and guidance is not a trivial pursuit; hence, in this presentation we intend to provide an introduction to DO-254 by describing its purpose, scope and underlying hardware design process for FPGAs.

02: Best Practices for Requirements Traceability


Complex custom micro-coded devices such as PLDs, FPGAs and ASICs used in commercial airborne hardware are subject to the stringent development process outlined in the DO-254 guidance. This means that the design and verification activities for these types of devices must follow the requirements-based development process described in DO-254. The primary purpose of DO-254 is to provide assurance that the device under test meets its intended functions under all foreseeable operating conditions. Requirements express the functions of the device under test; therefore must drive the design and verification activities.


This presentation will describe requirements traceability according to DO-254 guidance in the context of FPGAs, and provides explanations as to what it means for the applicants. This presentation will also enumerate the underlying purpose of requirements traceability and the benefits that can be achieved when done correctly.


03: Managing Validation and Verification Activities for DO-254



Requirements define the intended functions of the device so they are undoubtedly critical in the development cycle. However, a great limitation lies within the requirements themselves. What if the requirements are poorly written? FPGA designers may develop the wrong design. What if the requirements are not verifiable? Verification engineers would have a very difficult time in finding what needs to be verified? How would we know when we are done? Project managers would have a difficult time in assessing the status of the project. To address these major limitations, RTCA/DO-254 includes a supporting process that occurs throughout the hardware design process called the Validation and Verification (V & V) Process.


This presentation will provide an overview of V & V for FPGAs, its associated activities and the required data that must be provided by the applicants for DO-254 compliance. With the growing size and complexity of today’s FPGAs, the requirements that must be managed, reviewed, validated, traced, implemented and verified have also undeniably multiplied. Requirements frequently change impacting other project elements which leads to more rework, redesign and retest. The traceability from requirements to test data must be created and preserved so testing activities can get chaotic without a systematic approach to manage them.


04: HDL Coding Standards and How to Mitigate CDC Effects



In order to prevent potentially unsafe attributes of HDL code from leading to unsafe design issues, the use of HDL coding standards is recommended by the FAA as described in the FAA Order 8110-105A 6-2.a. The HDL coding standards must be defined, reviewed and documented which entails a tedious and lengthy manual review of the HDL source code. In this presentation we will show you DO-254 best-practice HDL coding standards that include essential areas in HDL coding such as coding style, readability, simulation, clock/reset management, design reuse, coding for safe synthesis and implementation, clock domain crossings (CDC) and design for test (DFT).


With state-of-the-art FPGAs adding more clock domains and more logic capability, clock domain crossings (CDCs) are almost a certainty in new projects. Complex designs contain the potential for large numbers of CDCs, leaving the door wide open for anomalous behavior in safety-critical environments. Even if teams have the knowledge to manually review designs for CDC issues, the costs of time and documentation loom large. For teams seeking DO-254 compliance, the stakes are even higher.

Inevitably, CDCs appear in large FPGA designs. When logic spans a boundary between two separately clocked asynchronous domains, the result can be unpredictable. If clocks happen to align properly, all is well. When they misalign for even a brief moment, two probabilistic effects become major concerns: metastability and data incoherence. In this presentation we will provide overview of CDC effects and best-practices on how to mitigate them.


05: Physical Testing for DO-254



The main purpose of the RTCA/DO-254 Section 6.0 Verification Process is to ensure that the device built meets the requirements and safely performs all intended functions under normal and abnormal operating conditions.


Verification coverage by test during final board testing is difficult and in most cases not feasible. Frequently as a result, applicants are left with the only option to verify them only by simulation. But simulation is insufficient and in many cases unable to expose errors that may impact safety and reliability of the device under test.


This presentation will explain the reasons behind these verification challenges, and provides recommendations how to overcome them. The recommendations center on Aldec’s unique device testing methodology that can significantly increase verification coverage by physical test needed for DO-254 compliance.

Training Yokohama, Japan Register
Ask Us a Question
Ask Us a Question
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.