Wondering about PPROT[2]

To be honest I don't think any APB design WILL use PPROT[2] (although I'm sure someone will find a use for it).

Originally the APB protocol was supposed to be very simple. A 2 cycle transfer with just a few control signals. So low gate count and complexity.

But with each version of the protocol we see additional functionality added in response to frequent designer requests. APB3 added support for wait states and error responses. And APB4 added write strobes and protection information. APB5 adds yet more complexity.

For the PPROT protection bits, bit 0 indicates whether the processor is in a privileged state of operation or else a less privileged "user" state where you might want to restrict access to some peripherals in the memory map. Similarly bit 1 indicates whether a transfer is from a processor operating in a secure state, so again with implications on access restrictions for non-secure operation.

Bit 2 is less obvious as you would normally only care about whether a processor is performing instruction or data accesses when looking at memory on the main AXI or AHB system bus (you don't tend to have memory on the lower performance APB part of the system). Hence my comment that PPROT[2] is unlikely to be used.

But the PPROT bus is a direct copy of the AXI AxPROT bus, so all 3 of the AxPROT bits have been taken over to the APB protocol just in case someone has an obscure reason for also wanting to see this protection bit (it doesn't add much to add an extra bit when you are already porting over AxPROT[1:0]).

Peripherals that don't have a use for PPROT[2] (or any other PPROT bits) don't need to implement them on their bus interfaces. The protocol describes PPROT as an optional signal, so don't implement it (or all of the bits) if you don't need it.

To be honest I don't think any APB design WILL use PPROT[2] (although I'm sure someone will find a use for it).

Originally the APB protocol was supposed to be very simple. A 2 cycle transfer with just a few control signals. So low gate count and complexity.

But with each version of the protocol we see additional functionality added in response to frequent designer requests. APB3 added support for wait states and error responses. And APB4 added write strobes and protection information. APB5 adds yet more complexity.

For the PPROT protection bits, bit 0 indicates whether the processor is in a privileged state of operation or else a less privileged "user" state where you might want to restrict access to some peripherals in the memory map. Similarly bit 1 indicates whether a transfer is from a processor operating in a secure state, so again with implications on access restrictions for non-secure operation.

Bit 2 is less obvious as you would normally only care about whether a processor is performing instruction or data accesses when looking at memory on the main AXI or AHB system bus (you don't tend to have memory on the lower performance APB part of the system). Hence my comment that PPROT[2] is unlikely to be used.

But the PPROT bus is a direct copy of the AXI AxPROT bus, so all 3 of the AxPROT bits have been taken over to the APB protocol just in case someone has an obscure reason for also wanting to see this protection bit (it doesn't add much to add an extra bit when you are already porting over AxPROT[1:0]).

Peripherals that don't have a use for PPROT[2] (or any other PPROT bits) don't need to implement them on their bus interfaces. The protocol describes PPROT as an optional signal, so don't implement it (or all of the bits) if you don't need it.