Fast development, low cost, and reconfigurability are becoming critical factors for aerospace applications, making SRAM FPGAs attractive. However, SRAM FPGAs are prone to errors in the user and on the configuration bits. For their correct functioning, they must be capable of withstanding failures without sacrificing much performance. When adjusting a soft core for these applications, it is essential to know where redundancies are necessary, to avoid unnecessary overhead. We characterize the reliability of an unprotected RISC-V microcontroller using an accelerated neutron beam. Our investigation shows that, for our chosen benchmark and processor, the user data in the memory banks is the leading cause of the total number of errors in the application. By reversing the benchmark operations, we could root cause the origin of the observed errors and found that most of the data corruption detected during the runs stem from previously corrupt input data or from output data that were corrupted while transmitting.
An unprotected RISC-V Soft-core processor on an SRAM FPGA: Is it as bad as it sounds? / Forlin, B. E.; Van Huffelen, W.; Cazzaniga, C.; Rech, P.; Alachiotis, N.; Ottavi, M.. - 2023-:(2023), pp. 1-6. (Intervento presentato al convegno 28th IEEE European Test Symposium, ETS 2023 tenutosi a ita nel 2023) [10.1109/ETS56758.2023.10174076].
An unprotected RISC-V Soft-core processor on an SRAM FPGA: Is it as bad as it sounds?
Rech P.;
2023-01-01
Abstract
Fast development, low cost, and reconfigurability are becoming critical factors for aerospace applications, making SRAM FPGAs attractive. However, SRAM FPGAs are prone to errors in the user and on the configuration bits. For their correct functioning, they must be capable of withstanding failures without sacrificing much performance. When adjusting a soft core for these applications, it is essential to know where redundancies are necessary, to avoid unnecessary overhead. We characterize the reliability of an unprotected RISC-V microcontroller using an accelerated neutron beam. Our investigation shows that, for our chosen benchmark and processor, the user data in the memory banks is the leading cause of the total number of errors in the application. By reversing the benchmark operations, we could root cause the origin of the observed errors and found that most of the data corruption detected during the runs stem from previously corrupt input data or from output data that were corrupted while transmitting.I documenti in IRIS sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione