Explanation of TX2 On-Die Cache Population Methods

I represent a university-based cube satellite laboratory. My team is currently planning to use the Jetson TX2 platform for one of our LEO-type missions and as such will be placing it in a moderately irradiated environment. It is my understanding that the TX2 platform has ECC implemented in the on-die cache, but does not support ECC DRAM. Under our current design, core system stability should not be a major concern as we will be using a radiation hardened secondary control system that would allow for reboots of the TX2 should an unrecoverable error occur. However, the performance of TX2 when doing compute tasks (in our case image processing) would be significantly degraded if frequent system reboots are require. To mitigate this performance penalty, we want to increase the radiation tolerance of the DRAM of the TX2 either by the addition of radiation shielding or by implementing a software based error correction.

Can you provide an explanation of how the on-die cache “decides” what data to pull from system memory (what is prioritized?, how is cache refreshed with new content?, etc.)? Additionally does the TX2 support directed caching of data (i.e. forcing certain data to perpetually stay cached)?

Can you provide an explanation of how the on-die cache “decides” what data to pull from system memory (what is prioritized?, how is cache refreshed with new content?, etc.)?

L1 instruction cache replacement policy is Least Recently Used(LRU).
L1 data cache replacement policy is LRU.
L2 data cache replacement policy is Random Cache-Replacement Policy.

Additionally does the TX2 support directed caching of data (i.e. forcing certain data to perpetually stay cached)?

Cache lock down in not supported.