An ECSS-Q-ST-60-02C compliant Space Research Centre of the Polish Academy of Sciences An ECSS-Q-ST-60-02C compliant verification flow for scientific projects Marcin Darmetko Kamil Ber

Challenges of scientific space projects verification High reliability requirements Extensive documentation Deadlines Requirements changes mid-project Lack of understanding from scientific board for significance of verification Lack of access to high-end software: verification, configuration management, requirements tracking

ECSS-Q-ST-60-02C FPGA = ASIC ? Netlist and layout as a separate steps divided by a review Hardware tests – required after CDR

Success story - STIX Spectrometer Telescope for Imaging X-rays for Solar Orbiter IDPU FPGA development Target device: RTAX2000SL-CGA624 LEON3 FT CPU FM delivered

Verification of OTP FPGA Requirements traced through all steps Important: - CDC - Reset - Interfaces definition Axcelerator prototype with adapter

Requirements definition FPGA requirements derived from higher level passed to block requirements of separate FPGA IP cores Tied to verification plan

Requirements tracing Link requirements with simulation routine, assertions, manual reviews Parsed in Tcl/Tk Additional Tcl commands e.g., simplifying instantiation checks

Simulation tools Mentor ModelSim (or QuestaSim) VHDL testbench – partially generated Bitvis UVVM framework testbench structuring, message logging, alert handlers VHDL verification components (stimulus for buses e.g., AMBA APB/AHB, SpaceWire) VHDL models of peripherals from Free Model Foundry or created in-house

Simulation scripts Simulation run from command line Parsing transcript file from simulator in search for tests pass / fail (test coverage) Parsing the assertions report Code coverage report (if available) Manual review file (timestamped reviews)

Results aggregation TCL script runs all block simulations in the test folder and aggregates results

Hardware testing Testing environment controlled by MATLAB (power, EGSE, measurements, communication with DUT). Use test scenarios Keeping track of test setups used Analyses and tests tied to each other as much as possible same IP cores in simulation and EGSE test routines following simulation scenarios

Result aggregation Partially done at simulation level (code reviews and simulation outputs) Spreadsheets of verification results generated by script Good tool to monitor progress

Verification Reports Linked to other documentation Datasheet review with automatic testing of pin settings Simulation results Power report Test results In readable, unified form

Future plans Ongoing move to Python Formal verification Fault propagation analysis ITTI’s Atena project – use of OTX standard for test sequencing in space projects

Lessons Learned Mentor tools can’t recognize FSM embedded in VHDL records AX prototyping – socket interposer in the adapter gets worn out very quickly. New gel based interposers should fix this problem. Identification of FPGAs – add labels right after programming. Keep track of core version in FPGA.

Lessons Learned Plan for OTP FPGA failure Few qualified assembly houses Long RMA times (via CPPA) - skipped RTAX PROTO GPSET / GCLR in Axcelerator devices are not reliable on power-up and design (especially reset scheme) shouldn’t be dependent on them

Conclusions Automation can be successfully implemented even late in project life (just before FM!) and still save time Ability to repeat simulations and tests in a controlled and automated manner is invaluable ECSS-Q-ST-60-02C could use a generic tailoring for future FPGA projects

Thank you for your attention!