the one and only degeneration scenario is going from duplication to nonredundant
mode.
However, as ROM is much less susceptible to ionized particles and longer
lasting than memory, this approach seems reasonable.
The reconfiguration of peripheral devices is currently limited on disabling and
isolating the device. In case of duplicated I/O controllers (two controllers attached
to the same external wires), reconfiguration could be done analog to the above
presented approach.
7.4 Software Support for Hardware Reconfiguration
Until now, we did not clearly define what software intervention comprises, but
showed how such a reconfiguration with degradation is applied to a system. In this
section, we discuss the needed software support for degradation and hardware
reconfiguration and show how the software itself can steer the reconfiguration
process.
7.4.1 Software Support for Degradation
In case of a detected hardware fault, the syndrome raises an interrupt and software
takes control of the reconfiguration process. The whole process is basically identical
if software-based schemes detect the fault, with the difference that no interrupt is
raised and the fault is not signaled via syndrome.
If the current memory configuration does not use a redundant mode,
software-based checking is the only possible approach. The following sequence
shows the general procedure of software support during hardware reconfiguration:
1. The hardware-checking scheme triggers the syndrome interrupt.
2. The syndrome interrupt handler then either initiates a hardware Built-In
Self-Test (BIST). The procedure of self-test for the device is software-based and
serves to distinguish the fault type. For a software-based test, writing different
memory patterns to the faulty memory address can be used to derive the fault
type.
3. The syndrome bit indicating the fault has to be cleared before doing that. If the
syndrome does, after the test, still show the fault, a memory module is faulty.
The affected memory address is still present in one of the processor registers and
based on the IRQ return address, the correct register number can be derived by
decoding the memory instruction that triggered the fault.
4. In general, all software-based testing procedures that test memory must not use
the stack (no procedure calls, no data pushed on the stack) until the proper
functioning of the used stack locations is ensured.
7.3 System Monitoring of Checking Process: A Syndrome
101
mode.
However, as ROM is much less susceptible to ionized particles and longer
lasting than memory, this approach seems reasonable.
The reconfiguration of peripheral devices is currently limited on disabling and
isolating the device. In case of duplicated I/O controllers (two controllers attached
to the same external wires), reconfiguration could be done analog to the above
presented approach.
7.4 Software Support for Hardware Reconfiguration
Until now, we did not clearly define what software intervention comprises, but
showed how such a reconfiguration with degradation is applied to a system. In this
section, we discuss the needed software support for degradation and hardware
reconfiguration and show how the software itself can steer the reconfiguration
process.
7.4.1 Software Support for Degradation
In case of a detected hardware fault, the syndrome raises an interrupt and software
takes control of the reconfiguration process. The whole process is basically identical
if software-based schemes detect the fault, with the difference that no interrupt is
raised and the fault is not signaled via syndrome.
If the current memory configuration does not use a redundant mode,
software-based checking is the only possible approach. The following sequence
shows the general procedure of software support during hardware reconfiguration:
1. The hardware-checking scheme triggers the syndrome interrupt.
2. The syndrome interrupt handler then either initiates a hardware Built-In
Self-Test (BIST). The procedure of self-test for the device is software-based and
serves to distinguish the fault type. For a software-based test, writing different
memory patterns to the faulty memory address can be used to derive the fault
type.
3. The syndrome bit indicating the fault has to be cleared before doing that. If the
syndrome does, after the test, still show the fault, a memory module is faulty.
The affected memory address is still present in one of the processor registers and
based on the IRQ return address, the correct register number can be derived by
decoding the memory instruction that triggered the fault.
4. In general, all software-based testing procedures that test memory must not use
the stack (no procedure calls, no data pushed on the stack) until the proper
functioning of the used stack locations is ensured.
7.3 System Monitoring of Checking Process: A Syndrome
101