If the fault is still present in the system, the respective bit in the syndrome will
reappear, indicating that the recovery has failed which means that the software
either misinterpreted the fault and performed the wrong recovery actions or that the
fault is a permanent fault. Software access to the syndrome must be controlled in a
way that ensures that no misbehaving program can render the system unusable.
We suggest, therefore, use of an access pattern to unlock the syndrome for write
access:
1. Write the unlock constant (a fixed predefined bit pattern) and in the next
instruction the inverse of the unlock constant to a helper syndrome register to
enable write access.
2. Update the syndrome registers by writing the value and its inverse in two
consecutive instructions.
This access protection ensures that the syndrome is not accidentally modified by
software. The syndrome unlock command must be rewritten every time software
wants to write to the syndrome. If the software does not update the syndrome right
after the unlock command, the syndrome locks again, assuming the software failed.
7.3.2 Memory Configuration
The proposed memory scheme may be regarded as a collection of four memory
modules, 32-bit wide, with identical size of 4 Mb each. Using 32-bit memory
modules instead of often-used 16-bit memory modules increases reliability and
flexibility due to additional supported memory modes. The proposed scheme allows
12 different memory configurations as shown in Table 7.1.
The configurations in the table are sorted in decreasing order according to their
reliability with triplication + spare on top and four linear memory modules with no
fault tolerance at all on the bottom.
The flexibility of the memory controller allows the platform to adapt to different
application requirements. A flight control system, for example, requires highest
reliability, which is achieved by using duplication for ROM and triplication + spare
for RAM.
On the downside, the available resources for the program are much smaller, i.e.,
only one-fourth of the total amount of available memory. This also implies that only
the most critical programs should run on this system, all non-safety-critical programs should be moved to another system. The chosen configuration even allows
tolerating permanent faults by reconfiguring the memory configuration by
excluding the faulty unit and if possible including a spare one.
An example: If the current selected memory configuration is 1 according to
Table 7.1, then the system can reconfigure the system to exclude the faulty unit and
include the spare unit in the working configuration.
94
7 Testing, Checking, and Hardware Syndrome
reappear, indicating that the recovery has failed which means that the software
either misinterpreted the fault and performed the wrong recovery actions or that the
fault is a permanent fault. Software access to the syndrome must be controlled in a
way that ensures that no misbehaving program can render the system unusable.
We suggest, therefore, use of an access pattern to unlock the syndrome for write
access:
1. Write the unlock constant (a fixed predefined bit pattern) and in the next
instruction the inverse of the unlock constant to a helper syndrome register to
enable write access.
2. Update the syndrome registers by writing the value and its inverse in two
consecutive instructions.
This access protection ensures that the syndrome is not accidentally modified by
software. The syndrome unlock command must be rewritten every time software
wants to write to the syndrome. If the software does not update the syndrome right
after the unlock command, the syndrome locks again, assuming the software failed.
7.3.2 Memory Configuration
The proposed memory scheme may be regarded as a collection of four memory
modules, 32-bit wide, with identical size of 4 Mb each. Using 32-bit memory
modules instead of often-used 16-bit memory modules increases reliability and
flexibility due to additional supported memory modes. The proposed scheme allows
12 different memory configurations as shown in Table 7.1.
The configurations in the table are sorted in decreasing order according to their
reliability with triplication + spare on top and four linear memory modules with no
fault tolerance at all on the bottom.
The flexibility of the memory controller allows the platform to adapt to different
application requirements. A flight control system, for example, requires highest
reliability, which is achieved by using duplication for ROM and triplication + spare
for RAM.
On the downside, the available resources for the program are much smaller, i.e.,
only one-fourth of the total amount of available memory. This also implies that only
the most critical programs should run on this system, all non-safety-critical programs should be moved to another system. The chosen configuration even allows
tolerating permanent faults by reconfiguring the memory configuration by
excluding the faulty unit and if possible including a spare one.
An example: If the current selected memory configuration is 1 according to
Table 7.1, then the system can reconfigure the system to exclude the faulty unit and
include the spare unit in the working configuration.
94
7 Testing, Checking, and Hardware Syndrome