Actually this chip does have ECC on many of the SRAMs - hence the bit widths of 36 bits instead of 32 in many cases. If it's a concern that the ECC is being used as storage, I'd suggest a laser glitch on the SRAMs to confirm the disturbance is caught by the ECC logic. This would at least confirm that the ECC bits are being used as some form of ECC. We've done testing to confirm the ECC function, but you don't have to take my word for it, it's a thing you can verify, too.

This check would not rule out the possibility that maybe there is some further back door that perhaps at runtime turns off the ECC function and then starts using the bits as storage, but one would need to hide the trigger for this somewhere, and there would need to be a non-trivial amount of logic to perform multiple accesses to the RAM to stripe e.g. executable code across the ECC bits. Specifically, you'd have to do 8 reads to put together a single 32-bit word in the case of a 36-bit wide RAM, which creates a fairly sizeable timing and power side channel.

If the ECC is confirmed (via glitch or sidechannel) during the trusted-boot measurement phase, and all the code and data space is accounted for, then the alternate mode trigger would then have to be in hardware. In either case there would be a non-trivial logic disturbance in the surrounding gates compared to the reference design (this is assuming you're trying to differentiate between a "good" design and a "modified" design).

To be clear, the article states that optical inspection alone can not yield a perfect security bound. However, it reduces the attack surface from an essentially unbounded problem, to a set of more difficult attacks such as the ones outlined above, which once enumerated can be detectable via other means.

This is a much stronger bounds than chips that are impossible to visibly inspect, and thus can trivially hold several kilobytes of fast code storage that can be easily swapped out and run at full speed, leaving little to no side channel to detect, and an intractably large space to search via software-only brute force for discovery.

Re: repair rows - these are a valid place to hide data, but in this design there are no repair rows, and you can confirm they don't exist from the imaging data.