Enabling conceptual design exploration and verification for airborne electronic hardware.
By Eric Cigan, MathWorks, and Jacob Wiltgen, Siemens EDA
The purpose of DO-254 (formally known as RTCA/ DO-254 or ED80) is to provide guidance for the development of airborne electronic hardware. The Federal Aviation Administration (FAA), European Aviation Safety Agency (EASA), and other worldwide aviation safety authorities require this standard to ensure that complex electronic hardware used in aircraft systems works as specified under all foreseeable conditions, avoiding faulty operation and potential air disasters.
DO-254 compliance is now common on commercial and military aviation projects. Unfortunately, recent industry data has highlighted some important trends forcing companies to evaluate their development processes. Growing complexity has impacted first-time success resulting in project delays and additional overhead.
Fig. 1: Growing complexity means more bugs and missed schedules.
Fortunately, Siemens and MathWorks have seen this trend coming and have partnered to deliver automation and methodologies to accelerate DO-254 lifecycles while keeping costs low. Engineers can now use Model-Based Design for requirements analysis, algorithm design, automatic HDL code generation, and verification to produce airborne electronic hardware that adheres to the DO-254 standard. The Model-Based Design approach for DO-254 combines automation tools for design and verification from both MathWorks and Siemens EDA to support the development process from concept through implementation—streamlining development and reducing costs.
Fig. 2: DO-254 compliance lifecycle and associated processes.
Figure 2 shows the DO-254 life cycle and lists the processes that must be performed and documented as a design moves from phase to phase. This article will focus on the following processes:
In this workflow, engineers use Siemens EDA Polarion to collect and manage requirements, which are exported to Requirements Toolbox from MathWorks. An executable Simulink model is then created from these requirements to enable conceptual design exploration. This conceptual model links to requirements at different levels in Polarion and Requirements Toolbox.
Using verification and validation tools from MathWorks, engineers perform functional testing and formal analysis at the conceptual model level. In Simulink, engineers elaborate the model by adding implementation attributes such as data-streaming and fixed-point effects. This elaborated model allows engineers to verify the design meets requirements, determine the level of coverage, and check conformance to model standards, becoming the model for HDL implementation. A detailed design in HDL is also generated from the verified Simulink model using HDL Coder. SystemVerilog testbench components are generated using HDL Verifier.
Once generated, verification of the detailed HDL design is performed in combination with Siemens EDA verification tools. Using HDL cosimulation with HDL Verifier, a Simulink testbench is used with a design-under-test (DUT) simulated in the Questa simulator to verify the DUT correctly implements the model. Test vectors created at the conceptual model level with Simulink Test are applied to the Simulink testbench during cosimulation. HDL code coverage is measured in Questa to determine the effectiveness of the test vectors and compared to the coverage metrics collected at model level. The entire Simulink testbench is then exported to the Siemens verification environment by generating SystemVerilog DPI-C components representing the stimulus, reference model and checker. HDL Verifier also generates either individual SystemVerilog verification components or complete UVM verification environments.
Siemens EDA products automate supplementary HDL development activities to satisfy elemental analysis and design margin analysis requirements found in DO-254. This includes code checking, coverage closure, code visualization, metastability checks, and reviews. Questa Formal performs static design and automated coverage analysis, while Siemens OneSpin EC-FPFGA performs logical equivalency for model checking. Questa CDC and RDC perform clock and reset domain crossing checks for metastability and glitch scenarios, and Questa Lint compliments domain crossing analysis with a DO-254 ruleset. FPGA synthesis and integration with FPGA vendor place and route tools is accomplished using Precision RTL. Figure 3 details the flow and integration points between the tools listed above.
Fig. 3: DO-254 workflow with Model-Based Design.
Widening use of DO-254 is compelling companies to evaluate how they can be more efficient in their development processes while achieving DO-254 compliance. The use of products from MathWorks and Siemens EDA in design, test, implementation, and verification can address these needs for companies developing complex airborne electronics. A DO-254 workflow using Model-Based Design promotes a consistent requirements-oriented project view and increases reuse of design and verification efforts throughout all phases of the DO-254 life cycle.
A comprehensive white paper has been created providing detail to each of the capabilities within the flow described above. The white paper can be accessed at:
Eric Cigan is the principal product marketing manager at MathWorks for ASIC and FPGA verification. Cigan earned an SB degree in mechanical engineering from the Massachusetts Institute of Technology, and later earned an SM degree in mechanical engineering from MIT as a Draper Fellow. Cigan worked on space-based guidance systems at Lockheed Missiles & Space and Integrated Systems, Inc, then held technical marketing roles in simulation and high-level synthesis at Mentor Graphics, Analogy, and AccelChip before joining MathWorks in 2007.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply