DO-254 CTS – Frequently Asked Questions

What is Aldec’s DO-254 CTS?

The Aldec’s DO-254 Compliance Tool Set (CTS) is used for testing of FPGA designs to the DO-254 standard. Aldec DO-254 CTS provides:

• Bit accurate, in-hardware testing based on target device running at target speed

• Reuse of the same test vectors as used during HDL simulation (the same coverage)

• Results capturing in a waveform format (easy to store, document, analyze and compare)

• Automated waveform comparison between the HDL simulation and in-hardware testing data.

Which DO-254/ED80 process is supported by Aldec’s DO-254 CTS?

The DO254-CTS (Compliance Tool Set) provides support for the “Design Assurance Guidance for Airborne Electronic Hardware” (DO-254/ED80) chapter 6.2 "Verification Process" and chapter 11.4 “Tool Assessment and Qualification Process”.

What Hardware Design Assurance Levels are supported by Aldec’s DO-254 CTS?

Aldec provides a fast and reliable verification process for assurance levels A, B, C and D with a focus on increased testability in hardware, and traceability of the design requirements. Verification for Levels A and B is supported by CTS in-hardware simulation that is based on testing the design in target device, at target speeds, with results being dumped to a waveform file. Verification for Levels C and D is supported primarily by Aldec HDL simulator with Code Coverage tool. The in-hardware simulation can be also used to increase the level of confidence in the design validation process.

What is the verification methodology applied by Aldec’s DO-254 CTS?

With Aldec’s solution, the HDL testbench achieving 100% functional coverage can be reused for in-hardware testing of the target device at-speed. The golden set of waveform vectors, validated in the HDL simulation are compared with a set of waveform vectors generated in the target device. If any mismatches are found, they can be easily investigated using the graphical waveform viewer. The in-hardware testing provides assurance that the design works in the target device just as it did during HDL simulation, with traceability of the hardware outputs back to the design requirements. In addition, the in-hardware testing independently assesses the outputs of the synthesis, place-and-route, and simulation tools, fulfilling the DO-254 requirements for tool assessment. The Aldec’s DO-254 CTS enables customers to manage their verification and tool assessment challenges, with a powerful easy-to-use solution.

What are the major components of Aldec DO-254 CTS?

Aldec’s DO-254 CTS is comprised of software and hardware elements. Hardware:

• Mother Board (MB) – the FPGA based board with host computer interface (PCI or PCIe). This board serves as a DO-254 controller for the in-hardware simulation process.

• Daughter Board (DB) – custom-made daughter board with a target device. DB is connected to Mother Board that drives and controls the process of testing.

Software:

• Compliance Verification Toolset (CVT) – complete software package for in-hardware simulation. Contains test vectors dumping module (TVD), verification tool (VT) that controls the process of in-hardware simulation, and all required interfaces and drivers.

• HDL simulator – Aldec (Active-HDL / Riviera-Classic / Riviera-PRO) simulator with a waveform viewer.

• Interface to most commonly used third party simulators – added as an option to CVT in case

How much money do I have to spend to start implementing assertions in my design flow?

Of course there are expensive formal verification tools that you could add to your design flow, but there is an affordable solution: add assertions to your existing simulator. Just adding features to your license should be enough, if your simulator cannot handle it, it is time to change your simulator…

I already have an HDL simulator provided by a different vendor, can I use it with Aldec’s DO-254 CTS?

Yes, CTS supports simulators coming from third party vendors. In such a case proper interfaces are included in CVT package. And in addition, Aldec Waveform Viewer will still be added to the CTS package.

How can I verify the test vectors generated for in-hardware simulations are accurate?

TVD module (part of CTS) generates tests vectors for in-hardware simulation during regular RTL simulation. Test vectors are recorded in the waveform format, so it is easy to open the waveform file in a waveform viewer and analyze it in comparison to test vectors used during RTL simulation. It is strongly recommended to perform such analysis before using the vectors for in-hardware simulations.

How can I check if accurate test vectors are applied to input pins of the target device on the Daughter Board?

All I/O pins of the target FPGA are connected to special gold-pin connectors for additional analysis and monitoring by e.g. logic analyzers. This way, it is easy to validate that proper test vectors are sent to the device. The same rule applies to test results coming from output pins of the device.

I have a testbench with an established code coverage; can I reuse this testbench for hardware testing?

Yes, CTS is working on the same testbench as used during RTL simulation. The same vectors (with the same coverage) are used for in-hardware testing.

Do I need to make any changes with my design to generate test vectors for in-hardware simulation?

No changes are needed in the design. TVD plugin is added to the simulator to generate test vectors.

What is the input for Aldec’s DO-254 CTS?

Customer design and a testbench are the inputs. There are no changes required in the design and testbenchs to work with CTS.

What is the input for Verification Tool (VT) that drives in-hardware simulation?

Input vectors (generated during RTL simulation), special XML mapping file that contains all required configuration information and a bitstream file created during Place & Route process.

What is the output of Aldec’s DO-254 CTS?

Output of Aldec DO-254 CTS is an in-hardware simulation waveform file that contains results of at-speed validation in the target device.

Do I need to make any changes to my design to use it with Aldec’s DO-254 CTS?

No changes are required. Original bit file is used to program the target device on the Daughter Board. There are no special wrappers added to the design and no changes in the pinout are made either.

Can my design be verified at target clock speed?

Yes, design is running at target clock speeds during in-hardware testing with DO-254 CTS.

How can I control/verify setup/hold times on data inputs/outputs of my design in CTS?

You can apply setup/hold times using VT application. The VT application allows shifting clock's phase with a step that is 1/256 of clock’s frequency, whereas timing of data lines remains constant. For example, if clock is running at 128MHz, you can change clock edge position against data with about 30 ps step. This allows determining minimum setup/hold times at which the design operates correctly.

Can I use in-hardware testing instead of timing simulation?

The in-hardware testing of FPGA design is based on bit files created during Place & Route process, and it verifies the actual design in the target device at proper speed. So in a way, it can replace timing simulation, but removing the timing simulation from the verification flow depends on many aspects and should be always consulted with the DER and certification authorities.

How can I take an advantage of Aldec’s DO-254 CTS for IP Cores validation?

First of all, the testbench from the HDL simulation of the IP Core can be reused for running the IP Core in hardware. Next, IP Core will be tested in the target device and running at the target speed, so it is easy to validate the core in the target hardware environment before e.g. connecting to the rest of the system. This way, IP Core is validated after implementation process, which is important in situations where IP Core is delivered or generated in a netlist format. In such cases, it is common that a behavioral (simulation) model of the IP Core might not be accurate enough, leading to simulation mismatch and sometimes even design failure in hardware.

My design contains bi-directional tri-state bus. Can I verify it with the Aldec’s DO-254 CTS?

Yes, bidirectional ports are supported by DO-254 CTS. It is required to deliver direction signal or formula for bidirectional signals to automate the in-hardware simulation process.

Can I compare results of in-hardware testing with RTL simulation output?

Yes, since results of in-hardware testing are stored in the waveform format it can be open in a waveform viewer for analysis and comparison. The comparison can be done in GUI or using command line scripts. It allows tracing test results back to RTL simulation data.

How the traceability to original requirements is achieved with Aldec’s DO-254 CTS?

To answer these questions, we should go back to the beginning of the design and verification process. Those two processes origin from a common point, which is a set of requirements & specifications defined at the Requirements Capture Process. Based on the defined requirements, design engineers implement design functions and verification engineers develop testbenches to verify functionally those functions in HDL simulation. A common requirement is to assure a 100% level of functional and code coverage. Significant work and resources are spent to satisfy all requirements at this stage. Also, it is a common practice to trace each unit test to its source requirement and this tracing has to be well documented.

Traditionally, when moving from design stage to in-hardware testing, the work performed during HDL simulation could not be transferred to this new environment and a test plan had to be created from scratch, as there was no link between simulation and hardware testing.

The CTS removes this unproductive step by reusing test vectors that come from HDL simulation. This way, HDL simulation and in-hardware testing is bridged and the entire process is automated by Aldec tools. What is the most important, by reusing HDL simulation test vectors, you introduce correlation between output of in-hardware testing and golden output generated by RTL simulation. Thus, traceability of hardware outputs to original requirements can be easily achieved.