Intentional change of the operating mode to a less redundant mode is of course
also possible and needs no special software measures. As soon as the module is
reconfigured to a free bank, the runtime system can start using it.
7.4.2 Hardware Condition Monitor
A hardware monitor, which is part of the runtime system, is responsible for keeping
track of the hardware state. The syndrome also can manage every hardware component represented in syndrome configuration, the hardware monitor tracks the state
in more detail than the syndrome alone can provide.
It is also responsible for the execution of all software checking schemes and
performs the actual hardware reconfiguration.
Thus the hardware monitor must be accessible by the syndrome interrupt handler
as well as the runtime system.
This monitor should however not directly be accessible by applications; only
drivers, which are part of the runtime system can register checking procedures for
their respective hardware component.
When the system is turned on, the Built-In Self-Test procedures (BIST)
embedded in the system are executed.
These self-test runs are required for all devices, using the principle of growing
core, ensuring the integrity of all devices. If a failure is detected, the syndrome sets
the appropriate fault bits. The BIST is also responsible to initiate the system to a
predefined working state, i.e., the most reliable mode with all working available
resources.
When the BIST finishes and passes control to the runtime system, the runtime
passes control to the hardware monitor for the first mirroring the current state in
software and then reconfigures the system according to the need of the program.
As the syndrome might trigger an interrupt right after boot up, the syndrome
interrupt handler has to ensure that the stack pointer is valid and if not initialize it.
Every hardware component, which is managed by the syndrome, is in exactly
one state of Fig. 7.19. This state diagram shows also all possible transitions
between states, allowing the hardware monitor to reconfigure the system in a
consistent way.
In fact, all of the above presented cases in the degradation scenarios where
software intervention is required, are clearly identifiable in Fig. 7.19. Intervention is
only required if the state transition goes from Standby to one of the active cases
(marked in blue).
After boot up, all devices are either in state OFF or in one of the blue operation
modes. As the BIST automatically configures the most reliable possible memory
configuration, the initial states of all devices must be acquired by reading the
syndrome. Here is a short list of all possible states and a short description.
7.4 Software Support for Hardware Reconfiguration
103
also possible and needs no special software measures. As soon as the module is
reconfigured to a free bank, the runtime system can start using it.
7.4.2 Hardware Condition Monitor
A hardware monitor, which is part of the runtime system, is responsible for keeping
track of the hardware state. The syndrome also can manage every hardware component represented in syndrome configuration, the hardware monitor tracks the state
in more detail than the syndrome alone can provide.
It is also responsible for the execution of all software checking schemes and
performs the actual hardware reconfiguration.
Thus the hardware monitor must be accessible by the syndrome interrupt handler
as well as the runtime system.
This monitor should however not directly be accessible by applications; only
drivers, which are part of the runtime system can register checking procedures for
their respective hardware component.
When the system is turned on, the Built-In Self-Test procedures (BIST)
embedded in the system are executed.
These self-test runs are required for all devices, using the principle of growing
core, ensuring the integrity of all devices. If a failure is detected, the syndrome sets
the appropriate fault bits. The BIST is also responsible to initiate the system to a
predefined working state, i.e., the most reliable mode with all working available
resources.
When the BIST finishes and passes control to the runtime system, the runtime
passes control to the hardware monitor for the first mirroring the current state in
software and then reconfigures the system according to the need of the program.
As the syndrome might trigger an interrupt right after boot up, the syndrome
interrupt handler has to ensure that the stack pointer is valid and if not initialize it.
Every hardware component, which is managed by the syndrome, is in exactly
one state of Fig. 7.19. This state diagram shows also all possible transitions
between states, allowing the hardware monitor to reconfigure the system in a
consistent way.
In fact, all of the above presented cases in the degradation scenarios where
software intervention is required, are clearly identifiable in Fig. 7.19. Intervention is
only required if the state transition goes from Standby to one of the active cases
(marked in blue).
After boot up, all devices are either in state OFF or in one of the blue operation
modes. As the BIST automatically configures the most reliable possible memory
configuration, the initial states of all devices must be acquired by reading the
syndrome. Here is a short list of all possible states and a short description.
7.4 Software Support for Hardware Reconfiguration
103