Of course, it is also necessary, independently to this scenario, to test periodically
the hardware in full as; otherwise, faulty spare components are considered as fully
operational and might be used again in a subsequent reconfiguration process.
A full hardware test also allows the system software to monitor the current state
of the hardware as a whole and take appropriate actions if necessary. If no spare
components are available in the system, all programs depending on this component
must be obviously terminated. If no essential program is affected by this component, the system can continue operating in a degraded mode.
For diagnostic and monitoring purposes, the results of the tests should be
available for the software or even external systems. We propose therefore to
organize the test results of hardware-based test in the so-called test syndromes (see
Sect. 7.3).
For every hardware component, for example, the register file, ALU, internal bus
or device controllers, the checking procedures present their result in the form of a
syndrome to the software, indicating in binary form the state of the device. By
grouping all syndromes together in one register, the software has a very effective
way to check the integrity of the system. In case of a nonzero syndrome, further
analysis of the hardware conditions is required, especially when the malfunction
duration is long.
Dependent on the used hardware-checking scheme, it is not only possible to
signal a fault to the runtime, but also provide more information to the runtime
system to ease recovery. If, for example, the testing schemes discover stuck bits in
memory, it is sufficient to recover programs that access the affected location and not
all programs that are using this memory module.
Device drivers could, for example, provide their own testing schemes for their
respective device. Especially for devices, one could think of having a combination
of hardware and software-based testing. I/O devices such as UARTs could effectively be tested by cross connecting the input and output wires by very simple
additional hardware logic and sending various bit patterns over this loopback
connection.
Timely task completions in real-time systems is a key requirement; therefore, the
testing overheads should be reduced as much as possible when and where possible.
Figure 7.5 shows an example of three tasks with corresponding tests.
The assumption in this case is a time slice-based scheduler, which distributes
time slices to the running processes. In this example, the processes run to
Fig. 7.5 Tasks and tests combined
74
7 Testing, Checking, and Hardware Syndrome
the hardware in full as; otherwise, faulty spare components are considered as fully
operational and might be used again in a subsequent reconfiguration process.
A full hardware test also allows the system software to monitor the current state
of the hardware as a whole and take appropriate actions if necessary. If no spare
components are available in the system, all programs depending on this component
must be obviously terminated. If no essential program is affected by this component, the system can continue operating in a degraded mode.
For diagnostic and monitoring purposes, the results of the tests should be
available for the software or even external systems. We propose therefore to
organize the test results of hardware-based test in the so-called test syndromes (see
Sect. 7.3).
For every hardware component, for example, the register file, ALU, internal bus
or device controllers, the checking procedures present their result in the form of a
syndrome to the software, indicating in binary form the state of the device. By
grouping all syndromes together in one register, the software has a very effective
way to check the integrity of the system. In case of a nonzero syndrome, further
analysis of the hardware conditions is required, especially when the malfunction
duration is long.
Dependent on the used hardware-checking scheme, it is not only possible to
signal a fault to the runtime, but also provide more information to the runtime
system to ease recovery. If, for example, the testing schemes discover stuck bits in
memory, it is sufficient to recover programs that access the affected location and not
all programs that are using this memory module.
Device drivers could, for example, provide their own testing schemes for their
respective device. Especially for devices, one could think of having a combination
of hardware and software-based testing. I/O devices such as UARTs could effectively be tested by cross connecting the input and output wires by very simple
additional hardware logic and sending various bit patterns over this loopback
connection.
Timely task completions in real-time systems is a key requirement; therefore, the
testing overheads should be reduced as much as possible when and where possible.
Figure 7.5 shows an example of three tasks with corresponding tests.
The assumption in this case is a time slice-based scheduler, which distributes
time slices to the running processes. In this example, the processes run to
Fig. 7.5 Tasks and tests combined
74
7 Testing, Checking, and Hardware Syndrome