1 Introduction

The checkerboard pattern (where each neighboring cell has a different value in the physical hardware) is not achieved with the used algorithm. This is because the logical layout does not match the physical implementation, as the SRAM is implemented with an interleaved architecture where each bit in a word/byte is physically separated instead of adjacent. While a new algorithm can be constructed to ensure that a checkerboard pattern is manifested in the physical SRAM, each device or device family deviates from each other in terms of the width of the SRAM (number of bits in one row) and where odd vs. even addresses are located physically. To account for this, each supported device would require a custom checkerboard algorithm. The amount of time required to develop and maintain such an implementation is considered disproportionate compared to the relatively low coverage of even a correctly implemented checkerboard algorithm, especially since the data sheet does not detail the physical SRAM implementation. For this reason, the current implementation is kept as is, where only SAFs are covered and full coverage of neighboring Coupling Faults (CFs) is not ensured, effectively making the diagnostic similar to a Zero-One test, also known as a Scan test, where each bit is written to zero, read back, written to one and read back again. Thus, it is not recommended to use this diagnostic for periodic fault detection of the SRAM, but it is kept as an option for applications that only need to cover SAFs. Instead, it is recommended to use the periodic March test API, which is implemented to be independent of the physical layout of the SRAM and covers significantly more Fault models.