Why implement the SAU in the PE if you have an IDAU and multiple masters with the same IDAU as the PE?
If the PE has an SAU, the PE will have a different security view of the system then the other masters.
Is this not an issue?
The IDAU can also be used to operate as a "default" security configuration before the SAU is fully configured.
Then why don't use only SAU, since SAU is more flexible? Is this because the SAU has a limited region number? Or because use SAU with IDAU is fast than just usinig SAU?
Which implemention do you prefer, only IDAU, only SAU or IDAU&SAU?
One important reason is that the IDAU can be used to define the recommended S/NS aliasing, where address bit 28 determines the S/NS attribution (either polarity works, which to use depends on your use cases and customers) and the S/NS halves are aliased to the same physical memory. Then the SAU is used exclusively to declare NSC regions. It's critical that the IDAU be extremely simple because it contributes to the AHB address phase timing; a complex IDAU will severely limit maximum frequency.
For other bus masters, you need to have what's referred to as a mini-IDAU to define the A aliasing attribution as described above.
Note that you can play games with what the main IDAU returns in order to reduce the number of SAU regions required to configure a usable system. (Remember, SAU + IDAU results in the highest security level attribution.) For instance, return NSC instead of S (though this has potential security implications if not handled correctly). Or return slightly different results than simply A. These can be options in the IDAU IP.
View all questions in TrustZone for Armv8-M forum