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.
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”.
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.
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.
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
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…
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.
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.
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.
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.
No changes are needed in the design. TVD plugin is added to the simulator to generate test vectors.
Customer design and a testbench are the inputs. There are no changes required in the design and testbenchs to work with CTS.
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.
Output of Aldec DO-254 CTS is an in-hardware simulation waveform file that contains results of at-speed validation in the target device.
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.
Yes, design is running at target clock speeds during in-hardware testing with DO-254 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.
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.
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.
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.
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.
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.