1. 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

2. 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

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

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

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

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

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

8. 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

9. 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)

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

11. 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

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

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

14. 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

15. 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.

16. 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

17. 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

18. Thank you for your attention!