Optimizing Verification Flow for Scientific Projects at Polish Academy of Sciences
Explore the challenges and success stories of implementing an ECSS-Q-ST-60-02C compliant verification flow for scientific space projects at the Space Research Centre of the Polish Academy of Sciences. Discover the intricacies of FPGA development, requirements tracing, and overcoming obstacles in high-reliability environments.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
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 N o t e C o m m Trace to higher level req. ID Valid Verify. method Req. ID Req. Description Planned Tests Planned Analyses Planned Reviews Planned Inspections 5.1 General IDPU-FPGA R-001 C IDPU R-004 R, A The FPGA shall provide register which store FPGA core version. That register shall be available to SW. T h e c o IDPU-FPGA-BLK R-2403 IDPU-FPGA-BLK R-1705 IDPU-FPGA-BLK R-1708 STIXIDPUFM_TB* HWSWICD* Y IDPU-FPGA R-002 IDPU R-009, IDPU R-010, IDPU R-011, IDPU R-026, IDPU R-151 R The FPGA configuration shall be compatible with target part: RTAX2000SL-CGS624E and radiation endurrance up to 60krad. DATASHEET* PROGRAMMINGLOG* Y IDPU-FPGA R-003 R, A The FPGA configuration shall be designed in such way that it can be used in both Main and Redundant IDPU without any modifications. T h e I IDPU-FPGA-BLK R-2403 IDPU-FPGA-BLK R-1705 STIXIDPUFM_TB* ADR* Y
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!
