Nios® V Processor: Lockstep Implementation User Guide

Download PDF
ID 833274
Date 4/17/2025
Public
Document Table of Contents
Document Table of Contents x
1. About the Nios® V Processor Lockstep 2. Overview 3. Controlling the Nios® V Processor Lockstep 4. Programming Model 5. Signals, Interfaces, and Build Parameters 6. Using Nios® V Processor Lock Step A. Document Revision History for the Nios® V Processor: Lockstep Implementation User Guide B. Appendix
1. About the Nios® V Processor Lockstep x
1.1. Nios® V Processor Lockstep Features
2. Overview x
2.1. Introduction 2.2. Main Principles 2.3. Operating Modes 2.4. Resets 2.5. LOGS Information
2.2. Main Principles x
2.2.1. System Phases 2.2.2. System States 2.2.3. Safety Mechanisms
2.2.2. System States x
2.2.2.1. Transitioning between System States
2.2.3. Safety Mechanisms x
2.2.3.1. Self-Checking Comparator 2.2.3.2. Timeout Timer 2.2.3.3. Reset and Enable Counters 2.2.3.4. Specialized Safety Mechanism
2.3. Operating Modes x
2.3.1. NORMAL and SILENT Modes
2.4. Resets x
2.4.1. Resetting CORE 2.4.2. Resetting OPTIONS 2.4.3. Resetting LOGS 2.4.4. Resetting Time Diversity Register and Comparator Blind Window
2.5. LOGS Information x
2.5.1. ALARMS 2.5.2. CONTEXT 2.5.3. STATISTICS 2.5.4. Reset LOGS
2.5.1. ALARMS x
2.5.1.1. Configuring Alarm Severity
3. Controlling the Nios® V Processor Lockstep x
3.1. Configuration Interface 3.2. Controlling the Elective Features
3.2. Controlling the Elective Features x
3.2.1. Applying Timeout and Comparator Blind Window 3.2.2. Injecting Fault 3.2.3. Downloading the CPU Software 3.2.4. Debugging the CPU Software using SILENT Mode 3.2.5. Resetting the CPU upon Fault Detection
3.2.1. Applying Timeout and Comparator Blind Window x
3.2.1.1. Timeout 3.2.1.2. Comparator Blind Window 3.2.1.3. Calculating the Blind Window and Timeout Period
3.2.2. Injecting Fault x
3.2.2.1. Root Fault Injection 3.2.2.2. Alarm Fault Injection
3.2.4. Debugging the CPU Software using SILENT Mode x
3.2.4.1. Entering SILENT Mode 3.2.4.2. SILENT Mode Limitation 3.2.4.3. Exiting SILENT Mode
3.2.5. Resetting the CPU upon Fault Detection x
3.2.5.1. Basic Reset Control 3.2.5.2. Extended Reset Control
3.2.5.2. Extended Reset Control x
3.2.5.2.1. Automatic CPUs Reset Request 3.2.5.2.2. Manual CPUs Reset Request
4. Programming Model x
4.1. Memory Map 4.2. Configuring fRSmartComp during Run-time 4.3. Unlocking and Locking Registers 4.4. Detailed Register Description
4.1. Memory Map x
4.1.1. Memory Map—Part 1 4.1.2. Memory Map—Part 2 4.1.3. Memory Map—Part 3
4.4. Detailed Register Description x
4.4.1. CPUs’ Reset Control Register - DCLSM_CPURC 4.4.2. DCLSM Basic Control Register - DCLSM_CTRL 4.4.3. DCLSM Blind Window Control Register - DCLSM_BWCR 4.4.4. All Alarms’ Prior Alarms’ Fault Injection Register - ERRCTRL_ALL_ALARMS_PRIOR_AFI 4.4.5. INTREQ Configuration Register - ERRCTRL_INTREQ_CONF 4.4.6. Timeout Deadline and Status Register - ERRCTRL_TIMEOUT 4.4.7. Timeout Acknowledgment Register - ERRCTRL_TIMEOUT_ACK 4.4.8. Enable Key fRSmartComp Control Register - ERRCTRL_ENABLE_KEY 4.4.9. Root Fault Injection Control register - ERRCTRL_ROOT_INJ 4.4.10. Alarm Fault Injection Control register - ERRCTRL_ALARM_INJ 4.4.11. Event Mask Configuration register - ERRCTRL_MASKA and ERRCTRL_MASKB 4.4.12. Alarm Routing Configuration register - ERRCTRL_ROUTA and ERRCTRL_ROUTB 4.4.13. Error Controller PGO LOG Reset Control register - ERRCTRL_PGOLOGRST 4.4.14. PGO0 and PGO4 Configuration registers - ERRCTRL_PGO0 and ERRCTRL_PGO4 4.4.15. FN_MODEIN Control Register - ERRCTRL_FNMODEIN 4.4.16. FN_MODEOUT register - ERRCTRL_FNMODEOUT 4.4.17. All Alarms After Fault Injection - ERRCTRL_FNGIALARMS 4.4.18. Error Controller Context Register - ERRCTRL_FNGICTXT4 4.4.19. CMP Mismatch CONTEXT Registers - ERRCTRL_FNGICMPCTXT0 … ERRCTRL_FNGICMPCTXT3 4.4.20. STATISTICS registers: ERRCTRL_FNGISTAT0 and ERRCTRL_FNGISTAT4 4.4.21. State register - ERRCTRL_FNPERIPHGI4
5. Signals, Interfaces, and Build Parameters x
5.1. Configuration Interface 5.2. System Interface 5.3. Extended Reset Interface 5.4. IP Parameters
6. Using Nios® V Processor Lock Step x
6.1. Instantiating Lockstep-Enabled Processor 6.2. Connecting Signals and Interfaces 6.3. Compiling Design 6.4. Implementing Startup Procedure 6.5. Applying Optional Injection for Validation 6.6. Detecting Faults 6.7. Handling Faults (Safety Use Case)
6.2. Connecting Signals and Interfaces x
6.2.1. Connecting Clock and Reset 6.2.2. Connecting Configuration Interface 6.2.3. Connecting System Interface
6.2.1. Connecting Clock and Reset x
6.2.1.1. Clock 6.2.1.2. Reset
6.2.1.2. Reset x
6.2.1.2.1. Basic Reset Control 6.2.1.2.2. Extended Reset Control
6.2.3. Connecting System Interface x
6.2.3.1. Silent Mode Interface 6.2.3.2. Interrupt Request (INTREQ) 6.2.3.3. ALARMS Interfaces
6.7. Handling Faults (Safety Use Case) x
6.7.1. UC_01: Standard Fail Safe or No Availability 6.7.2. UC_02: False Positive Avoidance 6.7.3. UC_03: Timeout on System Reset or After Fault Detection 6.7.4. UC_04: Fail Safe after Fault Discrimination 6.7.5. UC_05: Fail Safe after Fault Discrimination and Functional Downgrade
1. About the Nios® V Processor Lockstep
2. Overview
3. Controlling the Nios® V Processor Lockstep
4. Programming Model
5. Signals, Interfaces, and Build Parameters
6. Using Nios® V Processor Lock Step
A. Document Revision History for the Nios® V Processor: Lockstep Implementation User Guide
B. Appendix

6.7.5. UC_05: Fail Safe after Fault Discrimination and Functional Downgrade

This use case is an advanced scenario for improved availability. This use case is based on a similar scheme as UC_04. The difference is the system may successfully extend the availability capacity, by using the fRSmartComp comparator CONTEXT information.
This use case outlines the following steps:
  1. The comparator flags a mismatch due to a fault into one of the two CPUs.
  2. The fault is categorized as WARNING by fRSmartComp.
  3. The System Supervisor uses the WARNING information to put the system in a temporary safe state.
  4. fRSmartComp generates the first CPU reset request to Reset Controller.
  5. Reset Controller triggers a warm reset to the two CPUs (restarting them).
  6. If it is a transient fault, the following steps occur:
    1. The fault disappears.
    2. The processor application restarts typical execution.
  7. If it is a permanent fault in the typical application only, the following steps occur:
    1. The fault is detected again, causing a second reset.
    2. System Supervisor read fRSmartComp CONTEXT information on the affected comparator slice.
    3. If applicable, System Supervisor can restart the HOST CPU in safe mode, (limited functionality), which avoids using the faulty resource.
    4. Reset Controller triggers a warm reset to the two CPUs (initiate the safe mode application).
    5. The fault disappears.
    6. The processor application restarts under safe mode.
  8. If it is a permanent fault in both typical and safe mode application, the following steps occur:
    1. The fault is detected again, causing third reset.
    2. The programmable Reset counter threshold (configured as 2) is met.
    3. The fault is categorized as ERROR by fRSmartComp.
    4. fRSmartComp sets the primary OKNOK output to NOT_OK.
    5. System Supervisor uses the NOT_OK status to put the system in safe state.
    6. The system is permanently kept in safe state mode.

To simplify the flow diagram, the fRSmartComp configurations are labeled as CONF_3:

  • Configure ALARM severity.
    1. Set ALARM1 to WARNING
    2. Set ALARM16 to ERROR
    3. Set ALARM18 to ERROR
  • Set RST_COUNT as 2 to generate alarms after three resets.
    1. Transient fault results in one reset.
    2. Permanent fault in typical application results in two resets.
    3. Permanent fault in safe mode application results in three resets.
  • Set RRACM as 2’b10 to enable CPUs reset request after mismatch.
  • If INTREQ signal is used, set INTREQ configuration as 6’b011001 to generate interrupt upon WARNING.

You can decide the development of the safe mode since it is closely related to the system design and to the application. Note that, the safe mode is purely on the processor software application (not referring to FPGA reconfiguration).

For example, if the fault was detected in Data TCM1, the safe mode may decide to avoid it and run the software application in other memories. Thus, the routine allows the system to continue operating in a functional reduced mode, assuring a certain amount of availability.

Figure 28. Fail Safe after Functional Downgrade Flowchart Diagram
Level Two Title