Why the dummy cycles needed for every APB transfer

I see what you are focussing on, but your original question implied that step 3 was mandatory which resulted in the 3 cycles for a transfer. This is incorrect, which was why I focussed on that in my reply, stating that an APB transfer can complete every 2 PCLK cycles. Step 3 is not necessary in back to back transfers.

The reason for the 2 cycle minimum is that APB was aimed at supporting very simple interfaces, with SRAM type timing where you have a 2 step access with the address and control information in the first step, and then the data transfer in the second. So the APB "setup" phase is when the transfer request parameters would be sampled, and then the APB "access" phase is when the requested data transfer is performed.

You could have a bus protocol where everything happens all in one clock cycle, but this implies lots of combinatorial logic paths to decode the PADDR address, determine if it is a read or write transfer, and then allow the write or read data to be written in or read from the combinatorially accessed target (not as easy to constrain and synthesise).

We want to avoid combinatorial paths, so the APB 2 cycle timing allows you to sample the "setup" request, and then complete the data transfer on the "access" phase.

Note that you can still use combinatorial logic for the APB interface, where PSEL=1 and PENABLE=0 tells the peripheral what will be requested, and then PSEL=1 and PENABLE=1 is the latch enable control for writes or the output enable for reads.

But simplicity of interface implementation is the main driver for APB, and the 2 cycle timing gives you the simplest minimal logic requirement.

I see what you are focussing on, but your original question implied that step 3 was mandatory which resulted in the 3 cycles for a transfer. This is incorrect, which was why I focussed on that in my reply, stating that an APB transfer can complete every 2 PCLK cycles. Step 3 is not necessary in back to back transfers.

The reason for the 2 cycle minimum is that APB was aimed at supporting very simple interfaces, with SRAM type timing where you have a 2 step access with the address and control information in the first step, and then the data transfer in the second. So the APB "setup" phase is when the transfer request parameters would be sampled, and then the APB "access" phase is when the requested data transfer is performed.

You could have a bus protocol where everything happens all in one clock cycle, but this implies lots of combinatorial logic paths to decode the PADDR address, determine if it is a read or write transfer, and then allow the write or read data to be written in or read from the combinatorially accessed target (not as easy to constrain and synthesise).

We want to avoid combinatorial paths, so the APB 2 cycle timing allows you to sample the "setup" request, and then complete the data transfer on the "access" phase.

Note that you can still use combinatorial logic for the APB interface, where PSEL=1 and PENABLE=0 tells the peripheral what will be requested, and then PSEL=1 and PENABLE=1 is the latch enable control for writes or the output enable for reads.

But simplicity of interface implementation is the main driver for APB, and the 2 cycle timing gives you the simplest minimal logic requirement.

Thanks again. That mostly makes sense. Why does the interface require the address to be constant for 2 cycles too? Why cant we capture it during setup (as the spec says) and then do not care about it in access state. This is how the synchronous SRAM would operate, is not it?

You can capture it in the setup phase, that's how I'd expect you to use it so you know what data transfer is required in the access phase.

As for why the address and other controls are held constant during the access phase, as this isn't a pipelined bus (back to the simplicity argument) there isn't any functional reason NOT to keep the address and control signals constant for the duration of the access, and there might be a peripheral design that prefers the signals to still be valid during the data transfer, so why change them ?