The switch from Phase 1 to Phase 2 involves some software intervention to
prepare the module before it can be included in the working set. We discuss all
cases where additional software intervention is needed (red arrows in Fig. 7.17) in
Sect. 7.4.1.
7.3.4.2 Degradation Phases of a Duplicated System
The proposed degradation phases of a duplicated memory system as shown in
Fig. 7.18 pose some interesting aspects regarding software intervention which we
discuss in Sect. 7.4.
The discussed scenario uses bank 1 and bank 2, each having two modules in
duplicated mode.
Phase 1 States with full checking and duplication of every single bit. The single
state in this phase is the initial state and has maximum redundancy for 32 bit.
Phase 2 States in which at least 50% of the bits are replicated. The transition to one
of the four different states available in this phase is due to a failure in one of the
memory modules of Phase 1. Software-based checking is required to detect faults in
the nonredundant section.
Phase 3 No redundancy but full memory space available. This is the last mode in
which the software has the same memory space available as in Phase 1.
Phase 4 Degraded State. The software must adapt to the new situation of having
less memory space available either by running alternative, simpler program versions
that need less resources or by disabling some of the tasks completely.
Phase 5 Failure. The system has to fail stop.
The question arises whether Phase 3 of Fig. 7.18 is reasonable or whether Phase
3 of Fig. 7.17 plus one spare element should replace it.
This is actually up to the system designer, dependent on the memory needs and
the type of the applications. During degradation, it is assumed that the more
important software parts such as the runtime system and important user tasks are
located if possible in bank 1.
In Phase 2 as shown in Fig. 7.18, the system therefore keeps bank one duplicated although this involves in some cases (all degradations indicated by red
arrows) software intervention.
7.3.5 Reconfiguration of Other Hardware Devices
We focused in this section on the memory reconfiguration aspect, but it is also
possible to reconfigure other devices. For duplicated ROM, as used in the simulator,
100
7 Testing, Checking, and Hardware Syndrome
prepare the module before it can be included in the working set. We discuss all
cases where additional software intervention is needed (red arrows in Fig. 7.17) in
Sect. 7.4.1.
7.3.4.2 Degradation Phases of a Duplicated System
The proposed degradation phases of a duplicated memory system as shown in
Fig. 7.18 pose some interesting aspects regarding software intervention which we
discuss in Sect. 7.4.
The discussed scenario uses bank 1 and bank 2, each having two modules in
duplicated mode.
Phase 1 States with full checking and duplication of every single bit. The single
state in this phase is the initial state and has maximum redundancy for 32 bit.
Phase 2 States in which at least 50% of the bits are replicated. The transition to one
of the four different states available in this phase is due to a failure in one of the
memory modules of Phase 1. Software-based checking is required to detect faults in
the nonredundant section.
Phase 3 No redundancy but full memory space available. This is the last mode in
which the software has the same memory space available as in Phase 1.
Phase 4 Degraded State. The software must adapt to the new situation of having
less memory space available either by running alternative, simpler program versions
that need less resources or by disabling some of the tasks completely.
Phase 5 Failure. The system has to fail stop.
The question arises whether Phase 3 of Fig. 7.18 is reasonable or whether Phase
3 of Fig. 7.17 plus one spare element should replace it.
This is actually up to the system designer, dependent on the memory needs and
the type of the applications. During degradation, it is assumed that the more
important software parts such as the runtime system and important user tasks are
located if possible in bank 1.
In Phase 2 as shown in Fig. 7.18, the system therefore keeps bank one duplicated although this involves in some cases (all degradations indicated by red
arrows) software intervention.
7.3.5 Reconfiguration of Other Hardware Devices
We focused in this section on the memory reconfiguration aspect, but it is also
possible to reconfigure other devices. For duplicated ROM, as used in the simulator,
100
7 Testing, Checking, and Hardware Syndrome