Date

18 Feb 2025

Disclosures

Participants

Agenda

• Disclosures

• Whitepaper status update

  • current version: https://lf-riscv.atlassian.net/wiki/download/attachments/217448450/fusa-whitepaper.20250204.draft.pdf?api=v2,

  • current version with proposed introduction: https://lf-riscv.atlassian.net/wiki/download/attachments/217448450/fusa-whitepaper.20250204.introduction-draft.pdf?api=v2

  • current version with proposed introduction: https://lf-riscv.atlassian.net/wiki/download/attachments/217448450/fusa-whitepaper.20250217.introduction-draft.pdf?api=v2

  • whitepaper GitHub repository: https://github.com/riscv/sig-functional-safety-whitepaper

  • shared drive with all the input chapters: https://drive.google.com/drive/folders/13cxh4IxDGbEsit0rs7yuihduq85MrvOX?usp=drive_link

• Review previously identified gaps, identification of new gaps provided by the participants, and evaluate an order to address them in the SIG

  • The work on the whitepaper will continue until we have a shareable version, but I would like to start addressing functional safety identified gaps and propose solutions that can be addressed by other existing SIGs/TGs or could create new TGs.

    For that we can use the work already done in the shared drive (https://drive.google.com/drive/folders/13cxh4IxDGbEsit0rs7yuihduq85MrvOX?usp=drive_link ), where there are particularly two files describing the currently identified gaps (the “gaps” file contains a detailed list and the “gaps short list” file contains a summary of the gaps in the previous file).

    But we can also take into consideration new gaps brought by the SIG participants.

    So do not hesitate to come to the next meeting(s) so we can discuss them.

    You can also send your ideas to the mailing list.

Minutes

• Disclosures

• Srini asks if the SIG meeting could be moved to a week different than the Automotive SIG, i.e. one week the Automotive SIG, the week after the Functional Safety SIG. Daniel takes the action to see which are the options.

• Quick announcement on the whitepaper (GitHub link) status:

  • Integrated Redundancy chapter provided by Thomas

  • Updated intro and submitted as pull request (link)

  • Sandro is still working on the Partitioning chapter. He is working on the version on the shared drive (link)

  • Daniel asks everyone in the SIG to review the current version and submit fixes/improvements/issues through GitHub or email (link to pdf of current version)

• Discussion on the gaps identified in the blueprint (link to table of gaps resumed)

  • Discussion on “control to disable the hardware multithread”: current solution is to use OpenSBI to deactivate it. Maybe a problem for certification depending on the domain as then the OpenSBI should go through the certification. Radim informs than in other ISAs this can be controlled through ACPI and that the software can decide if it should use a thread or no (threads are viewed as extra cores). Holger takes the action on further studying the issue.

  • Discussion on the “mechanism to reset the temporal state” gap and its relation with the “clean and invalidate the cache”. Holger takes the action to check what is done in the fencet TG.

  • Discussion on the “specification of standardized watchdogs” gap. Thomas, from discussion with the SoC HC, indicated that given the requirements of the watchdogs usage the software solution (i.e. without impacting the ISA or specs) was not necessary. Decided to remove the gap or to put it in very low priority.

  • Discussion on the “interface/guideline for lockstep/TMR”. The current solutions typically are very implementation dependent and transparent to the software. Thomas: The only question might be on how to control the redundancy (e.g. lockstep) solution, but it’s not of the main points that hinders adoption of RISC-V. Currently, if a core providing lockstep and which can be deactivated is through external signals, but not controlled by the software. Paul wonders if there should be a standard way that the debug should handle the redundancy; Jaume, this seems still a hardware implementation detail, still transparent to the software. Thomas indicates that there are academic/research papers which study on to activate/deactivate lockstep, but their pertinence for adoption is still to be proved.

• Daniel asks participants to the meeting and other SIG members to indicate gaps (existent or new) which should be addressed.

• Meeting recording and transcript link

Presentations

Notes & Action Items