This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What are the real benefits of implementing IDAU from the viewpoint of chip designers?

We know that chip designers can use an Implementation Defined Attribution Unit (IDAU) to define a fixed memory map. A region can be defined as Secure, 
Non-secure, or Exempt. 

If SAU_CTRL ENABLE bit is set as 0, and the ALLNS bit is set as 1, then all memory regions comply with their IDAU settings. 

However, if SAU_CTRL ENABLE bit is set as 1, from user's viewpoint all memory regions becomes Secure. Of course, the IDAU Non-secure regions also become Secure. Application developers can employ SAU to set some IDAU non-secure regions back to non-secure. All IDAU Secure regions cannot be set to Non-secure by SAU.   

For embedded application developers, if the fixed IDAU memory map satisfies, the only thing need to do is setting SAU_CTRL ENABLE bit to 0, and the ALLNS bit to 1, to enable the IDAU memory security attributes.

Since the IDAU secure regions cannot be changed to non-secure, if the IDAU memory map does not satisfy, it implies more memory regions have to be set as Secure. The developer can set SAU_CTRL ENABLE = 1, so all memory regions become Secure, then use SAU to set some IDAU Non-secure regions back to Non-secure. As an example, assume we have 4 regions, their IDAU setting, SAU control register setting, SAU setting and final security attributes are listed below.  

A B C D E
SAU_CTRL ENABLE=0 SAU_CTRL ENABLE=1
Region # IDAU ALLNS=1 ALLNS=0 ALLNS no impact SAU setting IDAU+SAU
1 Secure Secure Secure Secure Non-secure Secure
2 Non-secure Non-secure Secure Secure Non-secure Non-secure
3 Secure Secure Secure Secure Non-secure Secure
4 Non-secure Non-secure Secure Secure Non-secure Non-secure

My argument is that IDAU adds a lot of limitations to memory map but does not bring many benefits. For example, IDAU secure regions are always secure (cannot be change by SAU as non-secure). IDAU non-secure regions are changed to Secure as soon as SAU_CTRL ENABLE = 1. The few scenario that IDAU makes sense is the default IDAU memory map setting is good enough to application developers, in which case, developer only need set SAU_CTRL ENABLE bit to 0 and the ALLNS bit to 1 to activate IDAU without setting regions one by one. 

Considering the many limitations and few benefits, what are the real benefits of implementing IDAU? I admit I have limited understanding to IDAU design. Thanks.

  • >IDAU non-secure regions are changed to Secure as soon as SAU_CTRL ENABLE = 1.

    I guess you have a typo. IDAU Non-secure regions are changed to Secure if SAU_CTRL.ENABLE=0 (default setting after reset).

    Several reasons for having IDAU:

    1 )SAU is limited to 8 regions in current Cortex-M23/M33/M35P implementations. If more regions are needed, IDAU can help. Please note you can define a large Non-secure region using the SAU, and then inside this memory space, use IDAU to make some of the sub-regions Secure and some of the sub-regions Non-secure. (You can also use Memory Protection Controller for parititoning of a memory block.)

    2) SAU is programmable. But for a SoC with fixed memory map, IDAU hardware can provide a lower gate count solution (lower power)..

    3) It is possible to have implement a programmable IDAU configuration register bank which help manage memory partition in multiple bus masters. SAU on the other hand, is for local processor only.

    regards,

    Joseph